Extensible Messaging and Presence Protocol (XMPP): Address Format
obsoletes
- rfc-6122 — Extensible Messaging and Presence Protocol (XMPP): Address Format
updated by
- rfc-9844 — Entering IPv6 Zone Identifiers in User Interfaces
Extracted elements (25)
Implementers are instructed to parse separator characters '@' and '/' before applying any transformation algorithms, because transformation might decompose certain Unicode code points into those separator characters, resulting in incorrect JID splitting if transformations were applied first.
Servers are not responsible for enforcing address format rules in protocol elements intended for communication among other entities (e.g., within stanza payloads being routed), only when directly handling or routing based on those elements. For peer-to-peer extensions like Jingle, the client entities themselves SHOULD enforce the rules.
This document replaces stringprep (used in RFC 6122) with the PRECIS framework (RFC 7564) for XMPP address preparation, following the movement of internationalized domain names away from stringprep. Strict backward compatibility is not guaranteed because PRECIS handling is based on current Unicode properties rather than a hardcoded character table, so previously valid JIDs might become invalid or vice versa.
Domainparts that are IP addresses might not be accepted by other services for server-to-server communication; domainparts that are unqualified hostnames cannot be used on public networks because they are only resolvable on a local network.
For backward compatibility, many existing XMPP implementations and deployments support IDNA2003 (RFC 3490) for domainparts and the stringprep profiles Nodeprep and Resourceprep (RFC 3920) for localparts and resourceparts, rather than the PRECIS-based approach defined here.
The differences from RFC 6122 include: domainpart preparation changed from IDNA2003 to IDNA2008; localpart preparation changed from Nodeprep (stringprep) to UsernameCaseMapped (PRECIS IdentifierClass); resourcepart changed from Resourceprep (stringprep) to OpaqueString (PRECIS FreeformClass); internationalized labels within domainparts must now be U-labels (not merely 'should be'); and servers must (not merely should) enforce address-formatting rules.
Although XMPP clients SHOULD prepare complete JIDs and JID parts in accordance with this document before including them in protocol slots within XML streams, enforcement is the responsibility of XMPP servers.
An entity performing enforcement in XMPP domainpart slots MUST prepare the string per Section 3.2.1 and MUST also apply the normalization, case-mapping, and width-mapping rules defined in RFC 5892 (IDNA2008).
An entity preparing a string for inclusion in an XMPP domainpart slot MUST ensure it consists only of Unicode code points allowed in NR-LDH labels or U-labels as defined in RFC 5890, and MUST NOT include A-labels (each A-label MUST be converted to a U-label).
Domainpart comparison requires preparing each string per Section 3.2.1, enforcing normalization/case-mapping/width-mapping per Section 3.2.2, and then performing an exact octet-for-octet (bit-string identity) match.
If the domainpart includes a trailing label separator (dot) as defined in RFC 1034, this character MUST be stripped from the domainpart before the JID is used for routing, comparison, or constructing an XMPP URI/IRI, and MUST be stripped before any other canonicalization steps.
The domainpart for every XMPP service MUST be a fully qualified domain name (FQDN), an IPv4 address, an IPv6 address, or an unqualified hostname resolvable on a local network.
The localpart of a JID MUST NOT be zero octets and MUST NOT exceed 1023 octets in length, enforced after normalization, mapping, and UTF-8 encoding. It MUST conform to the UsernameCaseMapped profile of the PRECIS IdentifierClass as specified in RFC 7613.
The resourcepart of a JID MUST NOT be zero octets and MUST NOT exceed 1023 octets in length after normalization and UTF-8 encoding. It MUST conform to the OpaqueString profile of the PRECIS FreeformClass as specified in RFC 7613.
XMPP applications MUST support IDNA2008 for domainparts, the UsernameCaseMapped profile for localparts, and the OpaqueString profile for resourceparts, enabling XMPP addresses to include a wide variety of characters outside the ASCII range.
XMPP entities SHOULD consider resourceparts to be opaque strings and SHOULD NOT impute meaning to any given resourcepart; the '/' separator does not imply hierarchical addressing, and '@' in a resourcepart does not denote a localpart.
XMPP servers MUST enforce address format rules wherever possible and MUST reject stanzas and other XML elements that violate those rules; for stanzas, the server returns a <jid-malformed/> error to the sender as described in RFC 6120 Section 8.3.3.8.
A JID (Jabber Identifier) is a UTF-8 encoded string structured as an ordered sequence of optional localpart, required domainpart, and optional resourcepart, demarcated by '@' and '/' separators. The formal ABNF syntax is: jid = [ localpart "@" ] domainpart [ "/" resourcepart ].
This document defines three slot concepts for enforcement: JID Slot (an XML element or attribute designated for a complete JID), Localpart Slot (designated for the localpart), and Resourcepart Slot (designated for the resourcepart), analogous to IDNA2008's 'domain name slot'.
XMPP localparts explicitly disallow the following characters even though they are permitted by the PRECIS IdentifierClass: U+0022 (QUOTATION MARK), U+0026 (AMPERSAND), U+0027 (APOSTROPHE), U+002F (SOLIDUS), U+003A (COLON), U+003C (LESS-THAN SIGN), U+003E (GREATER-THAN SIGN), and U+0040 (COMMERCIAL AT).
Because this document obsoletes RFC 6122, which registered the Nodeprep and Resourceprep profiles in the IANA 'Stringprep Profiles' registry, IANA has marked those profiles as 'Not Current' and added this document as an additional reference.
Address forging occurs when an entity generates an XML stanza whose 'from' address does not correspond to its authenticated account credentials. While XMPP's server-stamping and server-to-server authentication requirements make this difficult, a poorly implemented or malicious server can still forge addresses, and entities outside that server's security perimeter can only authenticate the domainpart with assurance.
Address mimicking occurs when visually similar Unicode characters are used to create JIDs that appear identical to a human user but are technically distinct (e.g., using Arabic numeral '1' in place of lowercase 'l'). XMPP services and clients are strongly encouraged to implement consistent policies for registration, storage, and presentation of visually similar characters, following recommendations in RFC 7564.
The security considerations from RFC 7564 (PRECIS) apply to IdentifierClass and FreeformClass usage for localparts and resourceparts; those from RFC 5890 apply to IDNA domainparts; and those from Unicode Technical Standard #39 (UTS39) apply to use of Unicode characters in XMPP addresses.
Each JID part (localpart, domainpart, resourcepart) is 1 to 1023 octets in length, yielding a maximum total JID size of 3071 octets including the '@' and '/' separators. Length limits are based on octets (bytes), not characters, since UTF-8 may encode a single character as multiple octets.