Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
obsoletes
- rfc-4622 — Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
Extracted elements (26)
A new "xmpp" URI scheme is defined rather than reusing im: or pres: URIs because those schemes are specific to instant messaging and presence, while XMPP is used for many other applications (network management, gaming, publish-subscribe, etc.) that do not implement IM/presence semantics.
Port numbers are prohibited in XMPP IRIs/URIs because XMPP server ports are intended to be discovered via DNS SRV records as specified in XMPP-CORE, making explicit port specification unnecessary and potentially enabling malicious redirection.
The key-value pair delimiter in the query component is ";" instead of "&" (used by most other URI schemes) to avoid the need to escape "&" in HTML and XML contexts where XMPP IRIs/URIs are most commonly embedded.
XMPP identifiers are registered primarily as URIs rather than IRIs because there is no freestanding registry of IRI schemes; the IANA recognizes only URI schemes. The document defines IRI syntax in addition to URI syntax to enable internationalization.
This document corrects errors in RFC 4622 by specifying that [ \ ] ^ ` { | } must be percent-encoded in node identifiers, and " < > [ \ ] ^ ` { | } must be percent-encoded in resource identifiers, and by correcting the ABNF and examples accordingly.
After decomposing an XMPP IRI, the processing application MUST ensure that the resulting XMPP address conforms to the rules specified in XMPP-CORE, including application of the relevant stringprep profiles.
Applications using query types and keys in XMPP URI/IRI query components SHOULD submit those query types and keys to the XMPP Registrar registry in accordance with the procedures specified in XEP-0147.
Characters that are valid in XMPP node identifiers but not in IRI userinfo ([ \ ] ^ ` { | }) and characters valid in XMPP resource identifiers but not in IRI pchar (" < > [ \ ] ^ ` { | }) MUST be percent-encoded when transforming an XMPP address into an XMPP IRI or URI.
If a processing application does not understand fragment identifier components or the syntax of a particular fragment identifier in an XMPP IRI/URI, it MUST ignore the fragment identifier component.
If a processing application is presented with an XMPP URI rather than an XMPP IRI, it MUST first convert the URI into an IRI by following the procedure specified in Section 3.2 of RFC 3987.
If the processing application does not understand query components or the specified query type, it MUST ignore the query component and treat the IRI/URI as consisting only of the base address. If it does not understand a particular key, it MUST ignore that key and its associated value.
Processing applications MUST clearly differentiate between xmpp://[email protected] (authenticate as [email protected] via authority component) and xmpp:[email protected] (identify the node [email protected] without authentication signal). User agents SHOULD discourage use of the "//" authority form in general usage.
The characters "#" and "?" in node identifiers, and "/", "?", "#", "@", and space in resource identifiers, MUST be percent-encoded when transforming an XMPP address into an XMPP IRI because these characters serve as delimiters in IRI syntax.
To convert an XMPP IRI to an XMPP URI, an application MUST adhere to the mapping procedure specified in Section 3.1 of RFC 3987 [IRI], which percent-encodes non-ASCII Unicode characters to US-ASCII.
When data is routed to an XMPP entity on an XMPP network (e.g., in 'to' or 'from' attributes of XML stanzas), the entity MUST be addressed as <[node@]domain[/resource]> without any prepended URI scheme.
When generating an XMPP IRI, the generating application MUST first ensure the XMPP address conforms to XMPP-CORE rules (UTF-8 encoding and stringprep profiles), then MUST decode the UTF-8 characters to their original Unicode form since IRI syntax specifies characters are the original Unicode characters themselves.
XMPP servers SHOULD NOT natively parse XMPP IRIs/URIs but instead SHOULD accept only the XML wire protocol specified in XMPP-CORE and desired extensions thereto.
The authority component of an XMPP IRI/URI, when present (preceded by "//"), encodes a node@domain and signals the processing application to authenticate as that account rather than using configured default credentials. Its presence distinguishes xmpp://[email protected] (authenticate as guest) from xmpp:[email protected] (identify guest).
The fragment identifier component of an XMPP IRI/URI has unconstrained semantics because XMPP resources have no associated media type and therefore no representation exists; particular XMPP applications MAY use it for their own purposes.
The query component of an XMPP IRI/URI encodes a query type optionally followed by key-value pairs delimited by ";", e.g., xmpp:[email protected]?message;subject=Hello%20World. The ";"-delimiter is used instead of "&" to avoid escaping issues in HTML and XML applications.
The XMPP IRI syntax is defined in ABNF as: xmppiri = "xmpp" ":" ihierxmpp ["?" iquerycomp] ["#" ifragment], where ihierxmpp supports both authority-path (iauthpath) and direct path (ipathxmpp) forms. The path encodes an XMPP address as [inodeid "@"] ihost ["/" iresid].
The XMPP URI syntax (for IANA registration) is defined in ABNF as: xmppuri = "xmpp" ":" hierxmpp ["?" querycomp] ["#" fragment], using percent-encoded US-ASCII characters rather than raw Unicode. The nodeid and resid rules specify which special characters are explicitly allowed beyond unreserved and pct-encoded.
This document registers the "xmpp" URI scheme with IANA as a permanent scheme, obsoleting the registration created by RFC 4622. The scheme identifies entities communicating via XMPP 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. Passwords and other user credentials are explicitly forbidden in the authority component; SASL (including SASL ANONYMOUS) is used for authentication instead.
The full range of Unicode characters allowed in XMPP IRIs makes address spoofing ("phishing") easier, as visually similar Unicode characters can impersonate legitimate addresses. Applications presenting XMPP IRIs to human users must adhere to best practices regarding address mimicking as defined in RFC 3987's Security Considerations.
XMPP addresses of the form node@domain/resource are ephemeral since a resource identifier typically corresponds to a single temporary client session; IRIs/URIs identifying such addresses will not reliably identify the same session over time.