Extensible Messaging and Presence Protocol (XMPP): Address Format
obsoleted by
- rfc-7622 — Extensible Messaging and Presence Protocol (XMPP): Address Format
updates
- rfc-3920 — Extensible Messaging and Presence Protocol (XMPP): Core
Extracted elements (24)
Although IDNA2003 is superseded by IDNA2008, RFC 6122 normatively references IDNA2003 because that was the technology available when RFC 3920 was published in 2004. XMPP implementations are encouraged to begin migrating to IDNA2008 since the successor specification will use it.
The term 'resourcepart' replaces 'resource identifier' from RFC 3920 to avoid confusion with the meanings of 'resource' and 'identifier' in the URI specification (RFC 3986). Similarly, 'localpart' replaces 'node identifier' to avoid confusion with 'node' as used in XEP-0030 and XEP-0060, while the profile name 'Nodeprep' is retained for backward compatibility.
The XMPP Working Group deliberately split the address format into a separate document (RFC 6122) so as not to delay publication of the main XMPP core specification (RFC 6120) while the community works on replacing Nodeprep/Resourceprep with a modern PRECIS-based approach. This document is explicitly expected to be short-lived.
Domainparts that are IP addresses might not be accepted by other services for server-to-server communication, and domainparts that are unqualified hostnames cannot be used on public networks because they are only resolvable on a local network.
RFC 6122 corrects the RFC 3920 ABNF to require IPv6 addresses in domainparts to be enclosed in square brackets (consistent with RFC 3986), which was not the case in RFC 3920. It also fixes zero-length localpart/domainpart/resourcepart prevention and requires the UseSTD3ASCIIRules flag in Nameprep.
A domainpart consisting of a FQDN MUST be an internationalized domain name per IDNA2003; each label MUST survive the ToASCII operation with UseSTD3ASCIIRules set (forbidding ASCII characters other than letters, digits, and hyphens). If an ACE label is received, the application SHOULD convert it to an internationalized label via ToUnicode before sending over an XMPP network.
A localpart MUST be formatted such that the Nodeprep profile of stringprep can be applied without failing. Before comparing two localparts, an application MUST first ensure Nodeprep has been applied to each identifier.
A resourcepart MUST be formatted such that the Resourceprep profile of stringprep can be applied without failing. Before comparing two resourceparts, an application MUST first ensure Resourceprep has been applied to each identifier.
Because Nodeprep-prohibited characters are prohibited after normalization, an implementation MUST NOT enable a human user to input any Unicode code point whose decomposition includes those characters (e.g., U+FE6B SMALL COMMERCIAL AT decomposes to '@', U+FF1A FULLWIDTH COLON decomposes to ':').
For XMPP communication (e.g., in 'to' or 'from' stanza addresses), an entity's address MUST be represented as a JID, not as a URI or IRI. XMPP IRIs (xmpp: scheme) are only for identification outside XMPP contexts such as web page linking.
If the domainpart includes a trailing label separator (dot), this character MUST be stripped before the JID is used for routing, comparison, or URI construction, and specifically before any Nameprep or ToASCII canonicalization is applied.
The domainpart of every XMPP service MUST be a fully qualified domain name (FQDN), IPv4 address, IPv6 address, or unqualified hostname. Domainparts that are IP addresses might not be accepted for server-to-server communication; unqualified hostnames cannot be used on public networks.
When dividing a JID into parts, an implementation MUST match the separator characters '@' and '/' before applying any transformation algorithms, since Unicode decomposition could otherwise decompose certain code points (e.g., U+FE6B SMALL COMMERCIAL AT) into the separator characters.
XMPP entities SHOULD consider resourceparts to be opaque strings and SHOULD NOT impute meaning to any given resourcepart. The '/' separator does not imply hierarchy, and '@' is allowed within the resourcepart (commonly used for chatroom nicks).
XMPP servers MUST, and XMPP clients SHOULD, support IDNA2003 for domainparts (including the Nameprep profile of stringprep), the Nodeprep profile for localparts, and the Resourceprep profile for resourceparts, enabling addresses to include characters outside US-ASCII.
A JID (Jabber Identifier) is the native XMPP address, structured as an ordered sequence of optional localpart, required domainpart, and optional resourcepart, demarcated by '@' and '/' separators respectively. The ABNF is: jid = [ localpart "@" ] domainpart [ "/" resourcepart ].
The Nodeprep stringprep profile applies to XMPP localparts. It uses Unicode 3.2, maps via stringprep Tables B.1 and B.2, normalizes to Unicode NFC-KC, prohibits stringprep Tables C.1.1 through C.9, and additionally prohibits the ASCII characters '"', '&', "'", '/', ':', '<', '>', and '@'.
The Resourceprep stringprep profile applies to XMPP resourceparts. It uses Unicode 3.2, maps via stringprep Table B.1 only (not B.2, unlike Nodeprep), normalizes to Unicode NFC-KC, and prohibits stringprep Tables C.1.2 through C.9 (but not C.1.1, allowing space characters).
This document updates the IANA 'Stringprep Profiles' registry with the Resourceprep profile (previously registered under RFC 3920, now updated to reference RFC 6122 as the defining document).
Address forging occurs when an entity generates stanzas whose 'from' address does not correspond to authenticated credentials. It is difficult but possible if a poorly implemented server ignores 'from' stamping or a malicious server generates stanzas for any registered account. End-to-end signing of XMPP stanzas could mitigate this risk.
Address mimicking (including 'typejacking') occurs when a JID appears visually identical to another, exploiting Unicode confusable characters. Stringprep technologies do not map similar-looking characters together, so XMPP localparts and resourceparts can contain confusables, enabling phishing-like attacks.
The security considerations of the stringprep RFC apply to Nodeprep and Resourceprep, those of stringprep and Nameprep apply to XMPP domainparts, and the Unicode Security Considerations (UTR #36) apply to use of Unicode characters in XMPP addresses.
To mitigate address mimicking, XMPP services SHOULD establish registration policies restricting localpart characters to known scripts, and XMPP clients SHOULD warn users when a JID mixes characters from more than one script or uses characters outside the user's preferred language range.
Each allowable portion of a JID (localpart, domainpart, resourcepart) MUST NOT be zero bytes in length and MUST NOT exceed 1023 bytes in length, yielding a maximum total JID size of 3071 bytes including the '@' and '/' separators. Lengths are enforced after any mapping or normalization.