Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
obsoleted by
- rfc-5122 — Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
Extracted elements (27)
Because there is no freestanding registry of IRI schemes, the document registers an xmpp URI scheme rather than an IRI scheme, even though XMPP addresses are inherently internationalized and close to being IRIs without a scheme.
Passwords and user credentials are forbidden in the authority component of XMPP IRIs/URIs because XMPP authentication occurs via SASL, which supports the ANONYMOUS mechanism and does not require embedding credentials in URIs.
Port numbers are prohibited in XMPP IRIs/URIs because XMPP port discovery uses DNS SRV records as specified in XMPP-CORE, which reduces the attack surface for malicious construction of XMPP IRIs/URIs.
XMPP IRIs and URIs are defined primarily for non-native interfaces (web browsers, databases, calendaring applications) for identification rather than interaction, since native XMPP addresses must not be prepended with a URI scheme on the XMPP network itself.
An XMPP IRI can be converted to URI syntax via RFC 3987 Section 3.1, and an XMPP URI to IRI via Section 3.2, ensuring interoperability with applications that can process URIs but not IRIs.
Processing applications SHOULD ignore the authority component if configured with default credentials, since the authority component is primarily useful in specialized scenarios and its misinterpretation could cause authentication to the wrong account.
XMPP IM applications must also handle im: and pres: URIs as specified by the CPIM and CPP profiles; the xmpp: scheme supplements rather than replaces these for the broader set of XMPP applications beyond instant messaging and presence.
Applications using the query component formats defined in this document SHOULD submit associated query types and keys to the Jabber Registrar registry in accordance with JEP-0147 procedures to help ensure interoperability.
Characters used as IRI delimiters that are allowed in native XMPP addresses ("#", "?" in node IDs; "/", "?", "#", "@", and space in resource IDs) MUST be percent-encoded when transforming an XMPP address into an XMPP IRI.
If a processing application does not understand fragment identifier components or the syntax of a particular fragment identifier, it MUST ignore the fragment identifier component.
If a processing application does not understand the query component or the specified query type, it MUST ignore the query component and treat the IRI/URI as if only the path component were present. Unknown keys within a query component MUST also be ignored.
If an XMPP protocol extension defines methods for information retrieval, it MUST define appropriate access controls. XMPP servers SHOULD NOT natively parse XMPP IRIs/URIs but SHOULD accept only the XML wire protocol from XMPP-CORE.
Percent-encoded octets corresponding to XMPP-address-allowed characters in the inodeid, ihost, and iresid rules MUST be transformed back into their character equivalents when processing an XMPP IRI for interaction with the represented XMPP entity.
Processing applications MUST clearly differentiate between xmpp://[email protected] (authenticate as [email protected]) and xmpp:[email protected] (identify node [email protected] without authentication signaling). User agents SHOULD discourage users from including "//" characters in XMPP IRIs/URIs.
To convert an XMPP IRI to a URI, an application MUST adhere to the mapping procedure specified in Section 3.1 of RFC 3987 (IRI). To convert an XMPP URI to an IRI, the application MUST follow Section 3.2 of RFC 3987.
To generate an XMPP IRI, the generating application MUST first ensure the XMPP address conforms to XMPP-CORE rules including STRINGPREP, then concatenate the scheme, optional authority, node, domain, optional resource, optional query, and optional fragment in order.
When data is routed to an XMPP entity in standard XMPP protocol elements, the entity MUST be addressed as <[node@]domain[/resource]> without a prepended scheme, conforming to XMPP-CORE address rules.
When processing an XMPP IRI, the processing application MUST ensure the resulting XMPP address conforms to XMPP-CORE rules including the relevant STRINGPREP profiles after decomposing the IRI components.
The authority component of an XMPP IRI/URI, preceded by "//", signals the processing application to authenticate as the specified node@domain rather than as a configured default account. Its absence means the application authenticates using configured credentials.
The path component identifies the XMPP address or specifies the recipient of an XML stanza. It supports forms: node@domain, node@domain/resource, or bare domain, making node and resource portions optional.
The query component encapsulates interaction intent via a query type optionally followed by key-value pairs (e.g., xmpp:[email protected]?message;subject=Hello%20World). Use cases include sending messages, roster management, presence subscriptions, joining chat rooms, and publish-subscribe interactions.
The XMPP IRI syntax is defined using ABNF as: xmppiri = "xmpp" ":" ihierxmpp ["?" iquerycomp] ["#" ifragment], where ihierxmpp supports both authority-path and path-only forms. The path encodes the XMPP address as [inodeid "@"] ihost ["/" iresid].
This document registers the 'xmpp' URI scheme with IANA as a permanent URI scheme. The xmpp scheme identifies XMPP entities and is used primarily for identification rather than resource location.
Advertising XMPP IRIs/URIs in publicly accessible locations may enable harvesting of XMPP addresses from authority and path components, facilitating unsolicited bulk communications. Care should be taken in balancing open information exchange against unwanted communications.
The full Unicode character range permitted in XMPP IRIs may facilitate address spoofing (phishing/homograph attacks). Applications presenting XMPP IRIs to users must adhere to best practices regarding address mimicking as described in the IRI security considerations.
XMPP addresses of the form node@domain/resource are ephemeral (tied to temporary client sessions), so the IRI/URI identifying such an address may not reliably identify the same session over time. Addresses of the form domain.tld are the most stable.
XMPP URI ABNF: xmppuri = "xmpp" ":" hierxmpp ["?" querycomp] ["#" fragment]. The nodeid and resid rules permit unreserved characters, pct-encoded octets, and specific additional characters (nodeallow/resallow sets). All characters are US-ASCII only in URI form.