RFC 6122

Extensible Messaging and Presence Protocol (XMPP): Address Format

📅 published March 2011, from ietf

RFC 6122 ✨ Extensible Messaging and Presence Protocol (XMPP): Address Format 💖 (part 1 of 5)

  • RFC: 6122 🎀
  • Title: Extensible Messaging and Presence Protocol (XMPP): Address Format
  • Author: P. Saint-Andre, from Cisco 💅
  • Date: March 2011 🌸
  • Category: Standards Track 👑
  • ISSN: 2070-1721 🦋
  • Updates: RFC 3920 🫶
  • Obsoletes: nothing is listed in the header 🧚

Abstract 💜

Okay so this doc is all about the address format for XMPP, and yes, that includes non-ASCII characters, periodt 🌸. It also updates RFC 3920, so keep that in mind 💅.

Status of This Memo ✨

This is an Internet Standards Track document 👑.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🔥. If you want more info on Internet Standards, check Section 2 of RFC 5741 🦋.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6122 💖.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the date this document was published. Read these carefully, because they spell out your rights and restrictions for this document 👀. Code Components pulled out of this document needs to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions 🔥. Those components also come with no warranty, as described in the Simplified BSD License 🙈.

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
2.  Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  2.1.  Fundamentals . . . . . . . . . . . . . . . . . . . . . . .  4
  2.2.  Domainpart . . . . . . . . . . . . . . . . . . . . . . . .  6
  2.3.  Localpart  . . . . . . . . . . . . . . . . . . . . . . . .  7
  2.4.  Resourcepart . . . . . . . . . . . . . . . . . . . . . . .  8
3.  Internationalization Considerations  . . . . . . . . . . . . .  9
4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
  4.1.  Reuse of Stringprep  . . . . . . . . . . . . . . . . . . .  9
  4.2.  Reuse of Unicode . . . . . . . . . . . . . . . . . . . . .  9
  4.3.  Address Spoofing . . . . . . . . . . . . . . . . . . . . .  9
    4.3.1.  Address Forging  . . . . . . . . . . . . . . . . . . . 10
    4.3.2.  Address Mimicking  . . . . . . . . . . . . . . . . . . 10
5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
  5.1.  Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 13
  5.2.  Resourceprep Profile of Stringprep . . . . . . . . . . . . 14
6.  Conformance Requirements . . . . . . . . . . . . . . . . . . . 14
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
  7.2.  Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A.  Nodeprep  . . . . . . . . . . . . . . . . . . . . . . 19
  A.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 19
  A.2.  Character Repertoire . . . . . . . . . . . . . . . . . . . 19
  A.3.  Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . 19
  A.4.  Normalization  . . . . . . . . . . . . . . . . . . . . . . 19
  A.5.  Prohibited Output  . . . . . . . . . . . . . . . . . . . . 20
  A.6.  Bidirectional Characters . . . . . . . . . . . . . . . . . 20
  A.7.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B.  Resourceprep  . . . . . . . . . . . . . . . . . . . . 21
  B.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 21
  B.2.  Character Repertoire . . . . . . . . . . . . . . . . . . . 22
  B.3.  Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . 22
  B.4.  Normalization  . . . . . . . . . . . . . . . . . . . . . . 22
  B.5.  Prohibited Output  . . . . . . . . . . . . . . . . . . . . 22
  B.6.  Bidirectional Characters . . . . . . . . . . . . . . . . . 22
Appendix C.  Differences from RFC 3920 . . . . . . . . . . . . . . 22
Appendix D.  Acknowledgements  . . . . . . . . . . . . . . . . . . 23

1. Introduction ✨

1.1. Overview 🌸

Okay, so XMPP is an application profile of the Extensible Markup Language [XML]. It's used for streaming XML data in close to real time between any two or more network-aware entities, and it's giving main character energy 👑. The address format for XMPP entities started out in the Jabber open-source community in 1999 🦋. It was first described by [XEP-0029] in 2002, and then defined canonically by [RFC3920] in 2004 🫶.

As specified in RFC 3920, the XMPP address format reuses the "stringprep" technology for preparing non-ASCII characters [STRINGPREP] 💅. That includes the Nameprep profile for internationalized domain names, as specified in [NAMEPREP] and [IDNA2003]. It also has two XMPP-specific profiles, one for the localpart and one for the resourcepart 🎀.

Here's the tea ☕. Since RFC 3920 came out, IDNA2003 got superseded by IDNA2008 (see [IDNA-PROTO] and related documents), and IDNA2008 isn't based on stringprep 😭. Other tech communities that use stringprep have started talking about moving toward more "modern" approaches, and the XMPP community is in on those talks, mostly inside the PRECIS Working Group 🔥. The goal is to find a replacement for the Nodeprep and Resourceprep profiles of stringprep that RFC 3920 defined 🧚. All the other revised XMPP docs were folded into [XMPP] already, so the XMPP Working Group decided to temporarily split the address format into its own document 🌈. That way, the rest of the improved XMPP docs didn't get held up 🙈. It's expected this document will get obsoleted as soon as work on a new approach to preparing and comparing internationalized addresses is finished 🦋.

So this spec gives corrected documentation of the XMPP address format, using the internationalization technologies that were available in 2004 when RFC 3920 was published 💖. Even though this document normatively references [IDNA2003] and [NAMEPREP], XMPP software implementations are encouraged to start migrating to IDNA2008 (see [IDNA-PROTO] and related documents) 🫶. The reason is that the spec that obsoletes this one will use IDNA2008 instead of IDNA2003 🔥.

This document updates RFC 3920 💅.

1.2. Terminology 📚

Lots of the important terms in this doc are defined in [IDNA2003], [STRINGPREP], [UNICODE], and [XMPP] 🎀.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS] 👑.

2. Addresses 🦋

2.1. Fundamentals 💅

An XMPP entity is anything that's network-addressable and can communicate using XMPP 🫶. For historical reasons, the native address of an XMPP entity is called a Jabber Identifier, or JID 🧚. A valid JID is a string of [UNICODE] code points, encoded using [UTF-8] 🌸. It's structured as an ordered sequence of localpart, domainpart, and resourcepart. The first two parts are separated by the '@' character, and the last two are separated by the '/' character 🔥.

Here's the syntax for a JID, written in the Augmented Backus-Naur Form from [ABNF] 📚:

jid           = [ localpart "@" ] domainpart [ "/" resourcepart ]
localpart     = 1*(nodepoint)
                ;
                ; a "nodepoint" is a UTF-8 encoded Unicode code
                ; point that satisfies the Nodeprep profile of
                ; stringprep
                ;
domainpart    = IP-literal / IPv4address / ifqdn
                ;
                ; the "IPv4address" and "IP-literal" rules are
                ; defined in RFC 3986, and the first-match-wins
                ; (a.k.a. "greedy") algorithm described in RFC
                ; 3986 applies to the matching process
                ;
                ; note well that reuse of the IP-literal rule
                ; from RFC 3986 implies that IPv6 addresses are
                ; enclosed in square brackets (i.e., beginning
                ; with '[' and ending with ']'), which was not
                ; the case in RFC 3920
                ;
ifqdn         = 1*(namepoint)
                ;
                ; a "namepoint" is a UTF-8 encoded Unicode
                ; code point that satisfies the Nameprep
                ; profile of stringprep
                ;
resourcepart  = 1*(resourcepoint)
                ;
                ; a "resourcepoint" is a UTF-8 encoded Unicode
                ; code point that satisfies the Resourceprep
                ; profile of stringprep
                ;

Every JID is built on that structure 🌈.

Each allowable portion of a JID (localpart, domainpart, and resourcepart) MUST NOT be zero bytes in length 🙈. It also MUST NOT be more than 1023 bytes in length 😭. That puts the maximum total size at 3071 bytes, counting the '@' and '/' separators too 💖.

When an entity's address is used for communication over an XMPP network (for example, in the 'to' or 'from' address of an XMPP stanza), it MUST be represented as a JID 👑. It MUST NOT be a Uniform Resource Identifier [URI] or an Internationalized Resource Identifier [IRI] 💅. An XMPP IRI [XMPP-URI] is basically a JID with 'xmpp:' stuck on the front 🦋. The native addressing format in XMPP, though, is just a plain JID with no URI scheme 🫶. [XMPP-URI] is only there for identifying and interacting with JIDs outside of XMPP itself, like when you link to a JID from a web page 🧚. If you want to pull a JID out of an XMPP URI or IRI securely, see [XMPP-URI] for the process 🔒.

💅 Implementation Note: When you split a JID into its component parts, an implementation needs to match the separator characters '@' and '/' before applying any transformation algorithms. That's because some transformations might decompose certain Unicode code points into the separator characters. For example, U+FE6B SMALL COMMERCIAL AT might decompose into U+0040 COMMERCIAL AT 🙈.

2.2. Domainpart ✨

okay so the domainpart is the bit after the @ (if there is one) and before the / (if there is one) 💖 it's the main identifier and the ONLY REQUIRED piece of a JID, which means a bare domainpart is a totally valid JID 🫶 Usually the domainpart points to the "home" server that clients connect to for XML routing and data stuff. BUT it doesn't HAVE to be a core XMPP server. It can be a multi-user chat service, a publish-subscribe service, or a user directory. main character energy for every service 💅

The domainpart for every XMPP service MUST be a fully qualified domain name (FQDN; see [DNS]), an IPv4 address, an IPv6 address, or an unqualified hostname (i.e., a text label that is resolvable on a local network). 🌸

Interoperability Note: Domainparts that are IP addresses might not be accepted by other services for the sake of server-to-server communication, and domainparts that are unqualified hostnames cannot be used on public networks because they are resolvable only on a local network. 😭

If the domainpart ends with a final character that counts as a label separator (dot) according to [IDNA2003] or [DNS], this character MUST be stripped from the domainpart before the JID is used for routing an XML stanza, comparing against another JID, or constructing an [XMPP-URI]. Especially, the character MUST be stripped before any other canonicalization steps are taken, such as applying the [NAMEPREP] profile of [STRINGPREP] or completing the ToASCII operation as described in [IDNA2003]. the order matters bestie, don't skip ahead 🙈

A domainpart that's a fully qualified domain name MUST be an "internationalized domain name" as defined in [IDNA2003]. That means it MUST be "a domain name in which every label is an internationalized label" and MUST follow the rules for building internationalized domain names specified in [IDNA2003]. 🌈 When an application prepares a text label (a sequence of UTF-8 encoded Unicode code points) to be represented as an internationalized label while building an XMPP domainpart or comparing two XMPP domainparts, it MUST make sure that for each text label, the ToASCII operation in [IDNA2003] can be applied without failing, with the UseSTD3ASCIIRules flag set (which forbids ASCII code points other than letters, digits, and hyphens). If the ToASCII operation can be applied without failing, then the label is an internationalized label. (Note: the ToASCII operation includes applying the [NAMEPREP] profile of [STRINGPREP] and encoding with the algorithm specified in [PUNYCODE]; for details, see [IDNA2003].) Even though XMPP applications don't send the output of the ToASCII operation (called an "ACE label") over the wire, it MUST be possible to apply that operation without failing to each internationalized label. 🧚

If an XMPP application gets an ACE label as input, it SHOULD convert that ACE label into an internationalized label using the ToUnicode operation (see [IDNA2003]) before putting the label into an XMPP domainpart that will go over the wire on an XMPP network. Instead of converting it, though, there are legit reasons an application might just refuse the input and return an error to the entity that sent the bad data. ngl that's a very valid choice 🙅‍♀️

A domainpart MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length. ✨ This rule gets enforced AFTER any mapping or normalization from the Nameprep profile of stringprep. (For example, in Nameprep some characters can get mapped to nothing, which could leave you with a zero-length string.) Obviously the length limits of [DNS] apply too, and nothing in this document overrides those more fundamental limits. 💀

In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a "domain name slot". 🦋

2.3. Localpart 🎀

The localpart of a JID is an optional identifier that goes before the domainpart and is separated from it by the @ character. 💜 Usually a localpart uniquely identifies the entity that's requesting and using network access from a server (aka a local account), but it can also be other stuff, like a chat room in a multi-user chat service. The entity behind an XMPP localpart is addressed within a specific domain (i.e., <localpart@domainpart>).

A localpart MUST be formatted so that the Nodeprep profile of [STRINGPREP] can be applied without failing (see Appendix A). Before comparing two localparts, an application MUST first make sure the Nodeprep profile has been applied to each identifier. (It doesn't need to be applied every single time a comparison happens, as long as it was applied before the comparison. no need to be extra 🙄)

A localpart MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length. This rule gets enforced after any mapping or normalization from the Nodeprep profile of stringprep. (Like, in Nodeprep some characters can get mapped to nothing, which might leave you with a zero-length string. 😭)

2.4. Resourcepart 🌸

The resourcepart of a JID is an optional identifier that goes after the domainpart and is separated from it by the / character. 🍓 A resourcepart can modify either a <localpart@domainpart> address or a plain <domainpart> address. Typically a resourcepart uniquely identifies a specific connection (like a device or location) or object (like an occupant in a multi-user chat room) that belongs to the entity tied to an XMPP localpart at a domain (i.e., <localpart@domainpart/resourcepart>).

A resourcepart MUST be formatted so that the Resourceprep profile of [STRINGPREP] can be applied without failing (see Appendix B). Before comparing two resourceparts, an application MUST first make sure the Resourceprep profile has been applied to each identifier. (Same deal as before: it doesn't have to be applied every comparison, just before the comparison happens. 💅)

A resourcepart MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length. This rule gets enforced after any mapping or normalization from the Resourceprep profile of stringprep. (Like, in Resourceprep some characters can get mapped to nothing, which could leave a zero-length string. iykyk 🙈)

Informational Note: For historical reasons, the term "resource identifier" is often used in XMPP to refer to the optional portion of an XMPP address that follows the domainpart and the "/" separator character. To help prevent confusion between an XMPP "resource identifier" and the meanings of "resource" and "identifier" provided in Section 1.1 of [URI], this specification uses the term "resourcepart" instead of "resource identifier" (as in RFC 3920). 🧠

XMPP entities SHOULD consider resourceparts to be opaque strings and SHOULD NOT impute meaning to any given resourcepart. Specifically:

  • Using the / character as a separator between the domainpart and the resourcepart does NOT mean XMPP addresses are hierarchical the way HTTP addresses are. So an XMPP address like <localpart@domainpart/foo/bar> does not identify a resource "bar" that lives below a resource "foo" in a hierarchy of resources tied to the entity "localpart@domain". no nested vibes here 🪆
  • The @ character is allowed in the resourcepart, and it's often used in the "nick" shown in XMPP chatrooms. For example, the JID <room@chat.example.com/user@host> describes an entity that's an occupant of the room <room@chat.example.com> with an (asserted) nick of <user@host>. However, chatroom services do not necessarily check that asserted nick against the occupant's real JID. 👀

3. Internationalization Considerations 🌍

XMPP servers MUST, and XMPP clients SHOULD, support [IDNA2003] for domainparts (including the [NAMEPREP] profile of [STRINGPREP]), the Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and the Resourceprep (Appendix B) profile of [STRINGPREP] for resourceparts. 🌈 This is what lets XMPP addresses include a wide variety of characters outside the US-ASCII range. Rules for enforcing the XMPP address format are provided in [XMPP]. ✨

4. Security Considerations 🔐

4.1. Reuse of Stringprep 🧵

The security considerations described in [STRINGPREP] apply to the Nodeprep (Appendix A) and Resourceprep (Appendix B) profiles defined in this document for XMPP localparts and resourceparts. The security considerations described in [STRINGPREP] and [NAMEPREP] apply to the Nameprep profile that's reused here for XMPP domainparts. 🫶

4.2. Reuse of Unicode 🔤

The security considerations described in [UNICODE-SEC] apply to the use of Unicode characters in XMPP addresses. 👀

4.3. Address Spoofing 🚨

okay this part is SERIOUS bestie 😭 There are two forms of address spoofing: forging and mimicking.

4.3.1. Address Forging 💀

In the context of XMPP technologies, address forging happens when an entity can generate an XML stanza whose 'from' address doesn't match the account credentials it used to authenticate onto the network (or an authorization identity provided during SASL authentication [SASL] negotiation, as described in [XMPP]). For example, forging happens if an entity that authenticated as "juliet@im.example.com" can send XML stanzas from "nurse@im.example.com" or "romeo@example.net". 🥀

Address forging is difficult in XMPP systems, because sending servers have to stamp 'from' addresses and receiving servers have to verify sending domains through server-to-server authentication (see [XMPP]). HOWEVER, forging is still possible if:

  • A poorly implemented server ignores the requirement to stamp the 'from' address. This would let any entity that authenticated with the server send stanzas from any localpart@domainpart, as long as the domainpart matches the sending domain of the server. 😤
  • An actively malicious server generates stanzas on behalf of any registered account. 😈

So an entity outside the security perimeter of a particular server can't reliably tell apart JIDs of the form <localpart@domainpart> at that server, which means it can authenticate only the domainpart of such JIDs with any real level of assurance. This specification does NOT define methods for discovering or counteracting such poorly implemented or rogue servers. 🙃 However, end-to-end authentication or signing of XMPP stanzas could help mitigate this risk, since the rogue server would then need to generate false credentials in addition to modifying 'from' addresses. 🔏

Furthermore, an attacker can forge JIDs at other domains through a DNS poisoning attack if DNS security extensions [DNSSEC] are not used. 🕷️

4.3.2. Address Mimicking ✨

Okay bestie, so address mimicking is when someone has totally legit login credentials and sends XML stanzas from an account whose JID looks exactly like another JID to a human 🫣 In some XMPP clients, ju1iet@example.org (with the number one as the third character of the localpart) can look the same as juliet@example.org (with a lowercase letter "L") 😭 People call this "typejacking" 💀

It gets even sneakier when you use characters from outside the familiar Latin extended-A block of Unicode code points. For example, Cherokee letters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 can stand in for the plain US-ASCII "STPETER" 🙈 Iconic villain behaviour, honestly 💅

Lots of these look-alikes are so convincing that the average user can't tell the real JID from the fake one 🥺 And there's no programmatic way to know for sure which is which! In some communication contexts, the Cherokee JID might be the real one, and the US-ASCII JID is the one that looks fake 🤯 Since JIDs can contain almost any properly encoded Unicode code point, mimicking them in XMPP systems is pretty easy. This opens the door to the same kind of trouble the World Wide Web has dealt with for ages, namely phishing 🎣

Why does this happen? Unicode and ISO/IEC 10646 have tons of characters that look alike (so-called "confusable characters" or "confusables") 👀 XMPP users often compare JIDs by eye, like when checking who they're talking to. Mapping look-alike characters is basically impossible without lots of context (like knowing which fonts are being used), so stringprep and stringprep-based technologies (Nameprep, Nodeprep, and Resourceprep) don't map similar-looking characters together. They also don't ban characters just because they look like other characters 🙃 So XMPP localparts and resourceparts can contain confusables, which makes JIDs that mimic other JIDs and leads to security problems like these:

  • A localpart is one part of an entity's address in XMPP. A common use is as the username of an instant messaging user, and another is as the name of a multi-user chat room. Plenty of other entities could use localparts as part of their addresses too 💬 The security of these services could fall apart when people read an internationalized localpart differently. For example, a user typing a single internationalized localpart could reach another user's account information, or a user could get into a hidden or otherwise restricted chat room or service 😱
  • A resourcepart is one part of an entity's address in XMPP. A common use is as the name of an instant messaging user's connected resource, and another is as the nickname of a user in a multi-user chat room. Many other kinds of entities could use resourceparts as part of their addresses too 🌸 The security of these services could be compromised when people read an internationalized resourcepart differently. For example, two or more confusable resources could be bound to the same account at the same time, which leads to inconsistent authorization decisions in an XMPP application that uses full JIDs. Or a user could send a message to someone other than the intended recipient in a multi-user chat room 💀

Now, the Unicode Security Considerations [UNICODE-SEC] do offer some specific suggestions about identifying and handling confusable characters. Still, as noted in [IDNA-DEFS], "there are no comprehensive technical solutions to the problems of confusable characters" 😭 Mimicked JIDs made from characters from only one script, or from the script a particular user or community normally uses, are hard to fight. The simple typejacking attack above is an example, since it relies on the surface similarity between "1" and "l" in some fonts. Mimicked addresses that mix characters from more than one script, or from a script that a particular user or community doesn't normally use, can be mitigated a bit 🛡️ That happens through sensible registration policies at XMPP services and presentation policies in XMPP client software. So the following policies are encouraged 🫶

  1. An XMPP service that lets people register XMPP user accounts (localparts) is kind of like a registry for DNS domain names 🌐 So that service SHOULD establish a policy about which scripts or blocks of characters it allows in localparts. That policy is likely shaped by the languages and scripts people use to write their account names. To cut down on confusion, the service MAY forbid registering XMPP localparts that contain characters from more than one script, and it MAY limit registrations to characters from a very small number of scripts (for example, scripts that the service's administrators understand well) 🧐 These policies also make sense for XMPP services that let people register XMPP resourceparts, either temporarily or permanently, such as during resource binding [XMPP] or when joining an XMPP-based chat room [XEP-0045]. For related thinking in the context of domain name registration, check out Section 4.3 of [IDNA-PROTO] and Section 3.2 of [IDNA-RATIONALE]. Note well that methods for enforcing these restrictions are out of scope for this document 📌
  2. Every human user of an XMPP client presumably has a preferred language (or sometimes a small set of them) 🌍 So an XMPP client SHOULD gather that info, either by asking the user explicitly or by picking it up implicitly from the operating system of the user's device. Here's the thing: most languages are written in a single script (or a small set of scripts), and most scripts live in one or more blocks of characters. That's why an XMPP client SHOULD warn the user when showing a JID that mixes characters from more than one script or block, or that uses characters outside the normal range of the user's preferred language(s) ⚠️ This isn't meant to discourage communication between different language communities. It just recognizes that these communities exist and encourages some due caution when showing unfamiliar scripts or characters to people 🫶

5. IANA Considerations 📋

The following sections update the registrations provided in [RFC3920].

5.1. Nodeprep Profile of Stringprep

The Nodeprep profile of stringprep is defined under Nodeprep (Appendix A). IANA has registered Nodeprep in the "Stringprep Profiles" registry 🗂️

Name of this profile:

   Nodeprep

RFC in which the profile is defined:

   RFC 6122

Indicator whether or not this is the newest version of the profile:

   This is the first version of Nodeprep

5.2. Resourceprep Profile of Stringprep

The Resourceprep profile of stringprep is defined under Resourceprep (Appendix B). IANA has registered Resourceprep in the "Stringprep Profiles" registry 🗂️

Name of this profile:

   Resourceprep

RFC in which the profile is defined:

   RFC 6122

Indicator whether or not this is the newest version of the profile:

   This is the first version of Resourceprep

6. Conformance Requirements ✅

Okay so this section is basically a checklist 💖 It summarizes the conformance requirements of this specification as a protocol feature set, which is great for software certification, interoperability testing, and implementation reports 🧾 For each feature, the section gives you:

  • A human-readable name
  • An informational description
  • A reference to the particular section of this document that normatively defines the feature
  • Whether the feature applies to the Client role, the Server role, or both (where "N/A" means the feature doesn't apply to the specified role)
  • Whether the feature MUST or SHOULD be implemented, where the capitalized terms are understood as described in [KEYWORDS]

The feature set here tries to stick to the concepts and formats Larry Masinter proposed within the IETF's NEWTRK Working Group in 2005, as captured in [INTEROP] 🦋 It's more detailed than [REPORTS] asks for, but that's a good thing, because it gives a solid base for implementation reports. Those reports get submitted to help advance this specification from Proposed Standard to Draft Standard, following [PROCESS] 🚀

Feature:  address-domain-length
Description:  Ensure that the domainpart of an XMPP address is at
   least one byte in length and at most 1023 bytes in length, and
   conforms to the underlying length limits of the DNS.
Section:  Section 2.2
Roles:  Both MUST.

Feature:  address-domain-prep
Description:  Ensure that the domainpart of an XMPP address conforms
   to the Nameprep profile of stringprep.
Section:  Section 2.2
Roles:  Client SHOULD, Server MUST.

Feature:  address-localpart-length
Description:  Ensure that the localpart of an XMPP address is at
   least one byte in length and at most 1023 bytes in length.
Section:  Section 2.3
Roles:  Both MUST.

Feature:  address-localpart-prep
Description:  Ensure that the localpart of an XMPP address conforms
   to the Nodeprep profile of stringprep.
Section:  Section 2.3
Roles:  Client SHOULD, Server MUST.

Feature:  address-resource-length
Description:  Ensure that the resourcepart of an XMPP address is at
   least one byte in length and at most 1023 bytes in length.
Section:  Section 2.4
Roles:  Both MUST.

Feature:  address-resource-prep
Description:  Ensure that the resourcepart of an XMPP address
   conforms to the Resourceprep profile of stringprep.
Section:  Section 2.4
Roles:  Client SHOULD, Server MUST.

7. References 📚

7.1. Normative References

okay bestie, this is the list of stuff the spec needs you to have read 📚🎀 the normative refs. no skipping!!

  • [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [IDNA2003] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.

See Section 1 for an explanation of why the normative reference to an obsoleted specification is needed. 🙈

  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.

See Section 1 for an explanation of why the normative reference to an obsoleted specification is needed. 🙈

  • [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
  • [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000. The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/). 🌈
  • [UNICODE-SEC] The Unicode Consortium, "Unicode Technical Report #36: Unicode Security Considerations", 2008, <http://www.unicode.org/reports/tr36/>. 🔐
  • [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. ✨

7.2. Informative References

these ones are just extra reading, not required, but honestly so worth it 🧚💖

  • [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [IDNA-DEFS] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
  • [IDNA-PROTO] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
  • [IDNA-RATIONALE] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
  • [INTEROP] Masinter, L., "Formalizing IETF Interoperability Reporting", Work in Progress, October 2005.
  • [IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
  • [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [PUNYCODE] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
  • [REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
  • [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
  • [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
  • [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
  • [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [XEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF XEP 0029, October 2003.
  • [XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", XSF XEP 0030, June 2008.
  • [XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, July 2008.
  • [XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", XSF XEP 0060, July 2010.
  • [XEP-0165] Saint-Andre, P., "Best Practices to Discourage JID Mimicking", XSF XEP 0045, December 2007.
  • [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
  • [XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.

Appendix A. Nodeprep 🌸

A.1. Introduction

okay so this appendix defines the "Nodeprep" profile of stringprep 💅 basically it's a set of processing rules that help people type internationalized localparts in XMPP and get the string as right as possible. 🎀 (quick refresher: an XMPP localpart is the optional bit of an XMPP address that comes before the domainpart and the '@' separator. it's often, but not always, an instant messaging username.) these rules are ONLY for XMPP localparts, not for random text or any other part of an address, so don't go using them everywhere 🙅‍♀️

This profile defines the following, as required by [STRINGPREP]:

  • The intended applicability of the profile: internationalized localparts within XMPP
  • The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in A.2
  • The mappings used: specified in A.3
  • The Unicode normalization used: specified in A.4
  • The characters that are prohibited as output: specified in A.5
  • Bidirectional character handling: specified in A.6

A.2. Character Repertoire

this profile uses Unicode 3.2 with the list of unassigned code points in Table A.1, both as defined in Appendix A of [STRINGPREP]. the vibes are very specific here 🧐✨

A.3. Mapping

this profile specifies mapping using the following tables from [STRINGPREP]:

   Table B.1
   Table B.2

A.4. Normalization

this profile specifies the use of Unicode Normalization Form KC, as described in [STRINGPREP]. normalization is giving "make it consistent" energy 💖

A.5. Prohibited Output

this profile specifies the prohibition of using the following tables from [STRINGPREP]:

   Table C.1.1
   Table C.1.2
   Table C.2.1
   Table C.2.2
   Table C.3
   Table C.4
   Table C.5
   Table C.6
   Table C.7
   Table C.8
   Table C.9

and ALSO these extra Unicode characters are prohibited, no exceptions 🚫🍓

  • U+0022 (QUOTATION MARK), i.e., "
  • U+0026 (AMPERSAND), i.e., &
  • U+0027 (APOSTROPHE), i.e., '
  • U+002F (SOLIDUS), i.e., /
  • U+003A (COLON), i.e., :
  • U+003C (LESS-THAN SIGN), i.e., <
  • U+003E (GREATER-THAN SIGN), i.e., >
  • U+0040 (COMMERCIAL AT), i.e., @

A.6. Bidirectional Characters

this profile specifies checking bidirectional strings, as described in Section 6 of [STRINGPREP]. 🔄 reading-direction drama, handled.

A.7. Notes

okay this section is the important one, bestie 🚨 the extra characters Nodeprep prohibits are prohibited after normalization, so an implementation MUST NOT enable a human user to input any Unicode code point whose decomposition includes those characters 😭 and the list below is NOT the whole story, these are just examples (check [UNICODE] for the complete info):

  • U+2100 (ACCOUNT OF)
  • U+2101 (ADDRESSED TO THE SUBJECT)
  • U+2105 (CARE OF)
  • U+2106 (CADA UNA)
  • U+226E (NOT LESS-THAN)
  • U+226F (NOT GREATER-THAN)
  • U+2A74 (DOUBLE COLON EQUAL)
  • U+FE13 (PRESENTATION FORM FOR VERTICAL COLON)
  • U+FE60 (SMALL AMPERSAND)
  • U+FE64 (SMALL LESS-THAN SIGN)
  • U+FE65 (SMALL GREATER-THAN SIGN)
  • U+FE6B (SMALL COMMERCIAL AT)
  • U+FF02 (FULLWIDTH QUOTATION MARK)
  • U+FF06 (FULLWIDTH AMPERSAND)
  • U+FF07 (FULLWIDTH APOSTROPHE)
  • U+FF0F (FULLWIDTH SOLIDUS)
  • U+FF1A (FULLWIDTH COLON)
  • U+FF1C (FULLWIDTH LESS-THAN SIGN)
  • U+FF1E (FULLWIDTH GREATER-THAN SIGN)
  • U+FF20 (FULLWIDTH COMMERCIAL AT)

Appendix B. Resourceprep 🦋

B.1. Introduction

okay so this appendix defines the "Resourceprep" profile of stringprep 💜 same deal as Nodeprep: it's processing rules so people can enter internationalized resourceparts in XMPP and have the best shot at the string being correct. (quick reminder: an XMPP resourcepart is the optional bit of an XMPP address that comes after the domainpart and the '/' separator.) these rules are ONLY for XMPP resourceparts, not arbitrary text or any other part of an XMPP address 🙅‍♀️

This profile defines the following, as required by [STRINGPREP]:

  • The intended applicability of the profile: internationalized resourceparts within XMPP
  • The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in B.2
  • The mappings used: specified in B.3
  • The Unicode normalization used: specified in B.4
  • The characters that are prohibited as output: specified in B.5
  • Bidirectional character handling: specified in B.6

B.2. Character Repertoire

this profile uses Unicode 3.2 with the list of unassigned code points in Table A.1, both as defined in Appendix A of [STRINGPREP]. yes it's Table A.1 again, same list, no notes 🌈

B.3. Mapping

this profile specifies mapping using the following table from [STRINGPREP]:

   Table B.1

B.4. Normalization

this profile specifies the use of Unicode Normalization Form KC, as described in [STRINGPREP]. same normalization vibe as Nodeprep, slay 💅

B.5. Prohibited Output

this profile specifies the prohibition of using the following tables from [STRINGPREP]:

   Table C.1.2
   Table C.2.1
   Table C.2.2
   Table C.3
   Table C.4
   Table C.5
   Table C.6
   Table C.7
   Table C.8
   Table C.9

notice Table C.1.1 isn't on this list, that's the difference from Nodeprep 👀✨

B.6. Bidirectional Characters

this profile specifies checking bidirectional strings, as described in Section 6 of [STRINGPREP]. 🔄 same check as always, periodt.

Appendix C. Differences from RFC 3920 ✨

okay so bestie, this part is the receipts 🧾💅 the spec team checked these changes with real implementations and real deployments, plus formal interop testing, so none of this is vibes-based. here's everything that changed from RFC 3920 🎀

  • ok so the ABNF got a glow-up to match [URI] and [IRI] 💖 it's also consistent with RFC 3986 and [RFC5952] for IPv6 addresses, which means you wrap the IPv6 address in square brackets '[' and ']' 🧚 (see also Section 4.9.3.19 of [XMPP] 📖)
  • the grammar now refuses zero-length localparts, domainparts, and resourceparts 🙅‍♀️ and it's noted that the DNS length limits apply to domainparts, so no sneaky long ones 🌈
  • "node identifier" became "localpart" 🦋 because "node" was causing confusion with [XEP-0030] and [XEP-0060] 😭 but the name "Nodeprep" stayed for backward compatibility 🫶
  • "resource identifier" became "resourcepart" ✨ because "resource" and "identifier" were already doing a lot in [URI] and it was getting messy 💀
  • Nameprep processing now requires use of the UseSTD3ASCIIRules flag 🔥 iconic, strict, no notes

Appendix D. Acknowledgements 🫶

thank u thank u 💜 the people who gave feedback are Ben Campbell, Waqas Hussain, Jehan Pages, and Florian Zeitz 🌸 and big thanks to Richard Barnes and Elwyn Davies for their reviews 👑 on behalf of the Security Directorate and the General Area Review Team, respectively 🔥

the Working Group chairs were Ben Campbell and Joe Hildebrand 🎀 and the responsible Area Director was Gonzalo Camarillo 👑

some text in this document was borrowed or adapted from [IDNA-DEFS], [IDNA-PROTO], [IDNA-RATIONALE], and [XEP-0165] 📚 credit where credit is due, periodt 💅

Author's Address 🦋

Peter Saint-Andre
Cisco
1899 Wyknoop Street, Suite 600
Denver, CO  80202
USA

Phone: +1-303-308-3282
EMail: psaintan@cisco.com
📦 where this page comes from