RFC 4622

Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)

📅 published August 2006, from ietf

RFC 4622 🎀

okay bestie, this is RFC 4622 💖 It's called Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre wrote it, from JSF 🧚 It's on the Standards Track and it's dated July 2006. The title block doesn't list anything it obsoletes or updates.

Status of This Memo ✨

This one is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

Copyright Notice 💅

Abstract 🫶

This document defines how IRIs and URIs get used when you're identifying or interacting with entities that can communicate over the Extensible Messaging and Presence Protocol (XMPP) 💜

Table of Contents 🍓

1. Introduction ....................................................3
   1.1. Terminology ................................................3
   2. Use of XMPP IRIs and URIs .......................................4
      2.1. Rationale ..................................................4
      2.2. Form .......................................................4
      2.3. Authority Component ........................................6
      2.4. Path Component .............................................7
      2.5. Query Component ............................................7
      2.6. Fragment Identifier Component ..............................9
      2.7. Generation of XMPP IRIs/URIs ...............................9
           2.7.1. Generation Method ...................................9
           2.7.2. Generation Notes ...................................10
           2.7.3. Generation Example .................................11
      2.8. Processing of XMPP IRIs/URIs ..............................12
           2.8.1. Processing Method ..................................12
           2.8.2. Processing Notes ...................................13
           2.8.3. Processing Example .................................14
      2.9. Internationalization ......................................14
   3. IANA Registration of xmpp URI Scheme ...........................15
      3.1. URI Scheme Name ...........................................15
      3.2. Status ....................................................15
      3.3. URI Scheme Syntax .........................................15
      3.4. URI Scheme Semantics ......................................16
      3.5. Encoding Considerations ...................................16
      3.6. Applications/protocols That Use This URI Scheme Name ......16
      3.7. Interoperability Considerations ...........................16
      3.8. Security Considerations ...................................16
      3.9. Contact ...................................................17
      3.10. Author/Change Controller .................................17
      3.11. References ...............................................17
   4. IANA Considerations ............................................17
   5. Security Considerations ........................................17
      5.1. Reliability and Consistency ...............................17
      5.2. Malicious Construction ....................................18
      5.3. Back-End Transcoding ......................................18
      5.4. Sensitive Information .....................................18
      5.5. Semantic Attacks ..........................................19
      5.6. Spoofing ..................................................19
   6. References .....................................................20
      6.1. Normative References ......................................20
      6.2. Informative References ....................................20

1. Introduction 🧚

okay so XMPP is a streaming XML technology 💅 It lets any two entities on a network swap well-defined but extensible XML elements (called "XML stanzas") at a rate that's close to real time ⚡

As [XMPP-CORE] lays out, entity addresses used in XMPP communications must not be prepended with a Uniform Resource Identifier (URI) scheme (as specified in [URI]) 🙈 But applications outside an XMPP network might still need to identify XMPP entities, either as URIs or, the more modern way, as Internationalized Resource Identifiers (IRIs; see [IRI]) 🌸 Think databases that need to store XMPP addresses, or non-native user agents like web browsers and calendaring apps that give you an interface to XMPP services 💖

An XMPP address is defined in [XMPP-CORE] 🎀 It can contain nearly any [UNICODE] character and has to follow various profiles of [STRINGPREP]. The result is that an XMPP address is fully internationalizable and is basically an IRI without a scheme, lowkey iconic ✨ But since there's no standalone registry of IRI schemes, XMPP identifiers have to be defined primarily as URIs rather than IRIs, and an XMPP URI scheme gets registered instead of an IRI scheme 💜 So this document does the following:

Specifies how to identify XMPP entities as IRIs or URIs.
Specifies how to interact with XMPP entities as IRIs or URIs.
Formally defines the syntax for XMPP IRIs and URIs.
Specifies how to transform XMPP IRIs into URIs and vice-versa.
Registers the xmpp URI scheme.

1.1. Terminology 🦋

This document inherits terminology from [IRI], [URI], and [XMPP-CORE] 🫶

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

2. Use of XMPP IRIs and URIs 🌈

2.1. Rationale 💅

As [XMPP-IM] describes, instant messaging and presence apps of XMPP must handle im: and pres: URIs (as specified by [CPIM] and [CPP]) 💬 But there are loads of other XMPP apps (network management, workflow systems, generic publish-subscribe, remote procedure calls, content syndication, gaming, and middleware) that don't do instant messaging or presence stuff at all 🎮 A generic XMPP entity doesn't implement the semantics of any existing URI scheme either, like http:, ftp:, or mailto: 🙈 So it makes sense to define a new URI scheme that lets you identify or interact with any XMPP entity, not just the IM and presence ones, as an IRI or URI 👑

XMPP IRIs and URIs are meant for non-native interfaces and applications, and they're mainly for identification rather than interaction (for that distinction, see Section 1.2.2 of [URI]) 🧚 To keep XMPP networks interoperable, when data gets routed to an XMPP entity (for example, when an XMPP address sits in the 'to' or 'from' attribute of an XML stanza), or when an XMPP entity is otherwise identified in standard XMPP protocol elements, the entity MUST be addressed as <[node@]domain[/resource]> (i.e., without a prepended scheme) 🔥 The "node identifier", "domain identifier", and "resource identifier" parts of an XMPP address have to conform to the definitions in Section 3 of [XMPP-CORE] ✨

(Note: For historical reasons, XMPP uses the term "resource identifier" for the optional part of an XMPP address that comes after the domain identifier and the "/" separator character (for details, see Section 3.4 of [XMPP-CORE]). Don't mix this up with the meanings of "resource" and "identifier" in Section 1.1 of [URI] 🙈)

2.2. Form 🍓

As [XMPP-CORE] describes, an XMPP address used natively on an XMPP network is a string of Unicode characters that (1) conforms to a certain set of [STRINGPREP] profiles and [IDNA] restrictions, (2) follows a certain set of syntax rules, and (3) is encoded as [UTF-8] 💖 You can write the form of such an address in Augmented Backus-Naur Form ([ABNF]) like this:

[ node "@" ] domain [ "/" resource ]

Here the "node" and "resource" rules rely on separate profiles of [STRINGPREP], and the "domain" rule relies on the idea of an internationalized domain name as described in [IDNA] 🌸 (Note: There's no need to mention punycode in the IRI syntax itself, since any punycode representation would only show up inside an XMPP application to represent internationalized domain names. However, it's the processing application's job to convert [IRI] syntax into [IDNA] syntax before addressing XML stanzas to the specified entity on an XMPP network 🧚)

Now, to become an IRI or URI, an XMPP address has to get the scheme prepended (specifically, the xmpp scheme), and it may also need transformations that follow the rules in [IRI] and [URI] 🎀 Also, if you want more advanced interaction with an XMPP entity instead of just identifying it, it's useful to use other parts of URI syntax and semantics, like authority components, query components, and fragment identifier components 👑

So here's the ABNF syntax for an XMPP IRI 🦋 The "ifragment", "ihost", and "iunreserved" rules are defined in [IRI], the "pct-encoded" rule is defined in [URI], and DQUOTE is defined in [ABNF] 💅

  xmppiri    = "xmpp" ":" ihierxmpp
               [ "?" iquerycomp ]
               [ "#" ifragment ]
  ihierxmpp  = iauthpath / ipathxmpp
  iauthpath  = "//" iauthxmpp [ "/" ipathxmpp ]
  iauthxmpp  = inodeid "@" ihost
  ipathxmpp  = [ inodeid "@" ] ihost [ "/" iresid ]
  inodeid    = *( iunreserved / pct-encoded / nodeallow )
  nodeallow  = "!" / "$" / "(" / ")" / "*" / "+" / "," / ";" /
               "=" / "[" / "\" / "]" / "^" / "`" / "{" / "|" /
               "}"
  iresid     = *( iunreserved / pct-encoded / resallow )
  resallow   = "!" / DQUOTE / "$" / "&" / "'" / "(" / ")" /
               "*" / "+" / "," / ":" / ";" / "<" / "=" / ">" /
               "[" / "\" / "]" / "^" / "`" / "{" / "|" / "}"
  iquerycomp = iquerytype [ *ipair ]
  iquerytype = *iunreserved
  ipair      = ";" ikey "=" ivalue
  ikey       = *iunreserved
  ivalue     = *( iunreserved / pct-encoded )

However, the syntax above isn't right for registering the xmpp URI scheme, since the IANA only recognizes URI schemes and not IRI schemes 🙈 So the ABNF syntax for an XMPP URI (rather than an IRI) is defined in Section 3.3 of this document (see below under "IANA Registration") 🌈 If you need to convert IRI syntax into URI syntax, an application MUST follow the mapping procedure specified in Section 3.1 of [IRI] 🔥

Here's a basic example of an XMPP IRI/URI, used to identify a node associated with an XMPP server 🧚

xmpp:node@example.com

The following sections describe the different components of an XMPP IRI/URI 💖

2.3. Authority Component ✨

Okay so, like Section 2.8 of this doc explains, if there's no authority component, the processing app just logs in as a configured user at a configured XMPP server. 💅 That means the authority component section is basically unnecessary and should be ignored if the app has been set up with default credentials. Iconic, right? 🎀

Per Section 3.2 of RFC 3986, the authority component starts with a double slash ("//") and ends at the next slash ("/"), question mark ("?"), or number sign ("#") character, or at the end of the IRI/URI. As Section 2.8.1 of this document explains more fully, having an authority component tells the app to log in as the node@domain in the authority instead of a configured node@domain. (Check the Security Considerations section about authentication, it's seriously important 🫶.) Honestly, it's unlikely most XMPP IRIs will include one, but the scheme allows for it if it makes sense. 🦋

So this XMPP IRI/URI tells the app to authenticate as "guest@example.com":

xmpp://guest@example.com

Note well 🙈 this is totally different from the next one, which identifies a node "guest@example.com" but does NOT tell the app to log in as that node:

xmpp:guest@example.com

Now, using a query component of "?message" to open an interface for sending a message, this one tells the app to authenticate as "guest@example.com" and send a message to "support@example.com":

xmpp://guest@example.com/support@example.com?message

Meanwhile this one tells the app to authenticate as its configured default account and send a message to "support@example.com":

xmpp:support@example.com?message

2.4. Path Component 🧚

The path component of an XMPP IRI/URI identifies an XMPP address, or specifies the XMPP address that an XML stanza shall be directed to at the end of IRI/URI processing. 💖

For example, this XMPP IRI/URI identifies a node associated with an XMPP server:

xmpp:example-node@example.com

This one identifies a node associated with an XMPP server, plus a particular XMPP resource identifier associated with that node:

xmpp:example-node@example.com/some-resource

Including a node is optional in XMPP addresses, so this XMPP IRI/URI just identifies an XMPP server:

xmpp:example.com

2.5. Query Component 🌸

There are so many potential use cases for putting info in the query component of an XMPP IRI/URI. Some examples (but not all, bestie, the list keeps going) include:

sending an XMPP message stanza (see [XMPP-IM]),
adding a roster item (see [XMPP-IM]),
sending a presence subscription (see [XMPP-IM]),
probing for current presence information (see [XMPP-IM]),
triggering a remote procedure call (see [JEP-0009]),
discovering the identity or capabilities of another entity (see [JEP-0030]),
joining an XMPP-based text chat room (see [JEP-0045]),
interacting with publish-subscribe channels (see [JEP-0060]),
providing a SOAP interface (see [JEP-0072]), and
registering with another entity (see [JEP-0077]).

A lot of these use cases are application specific, and we can't predict every app, since XMPP keeps growing. 📈 Still, the Jabber/XMPP developer community agrees that all the uses envisioned so far can be packed into a "query type", optionally with one or more "key-value" pairs. (It's kind of like the "application/x-www-form-urlencoded" MIME type described in [HTML], so if you know that one, you're already ahead 🧠.)

Say you wanted an XMPP IRI/URI that opens an interface for sending a message to the XMPP entity "example-node@example.com". It could look like this:

xmpp:example-node@example.com?message

And if you also wanted to set a particular subject for that message, it would look like this:

xmpp:example-node@example.com?message;subject=Hello%20World

Here's the important bit ⚠️: if the processing app doesn't understand query components or the specified query type, it MUST ignore the query component and treat the IRI/URI as consisting of, for example, <xmpp:example-node@example.com> rather than <xmpp:example-node@example.com?query>. And if the processing app doesn't understand a particular key within the query component, it MUST ignore that key and its associated value. 🫠

As I said, there are tons of XMPP apps (real and future), and they can define their own query types and keys for the query component. The Jabber Registrar function (see [JEP-0053]) of the Jabber Software Foundation keeps a registry of these query types and keys at <http://www.jabber.org/registrar/querytypes.html>. For interoperability (aka everyone playing nicely together 🥹), any app using the formats in this document SHOULD submit its query types and keys to that registry, following the procedures in [JEP-0147].

2.6. Fragment Identifier Component 🦋

As Section 3.5 of [URI] puts it, "The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information." 📚 Now, the resource an XMPP IRI/URI identifies doesn't make any media type available (see [MIME]), so (in the terminology of [URI]) there's no representation at an XMPP resource. That means the fragment identifier component in XMPP IRIs/URIs is "considered unknown and, effectively, unconstrained" (ibid.). Totally chill. 😌

Particular XMPP apps MAY use the fragment identifier component for their own purposes. However, if a processing app doesn't understand fragment identifier components, or the syntax of a particular fragment identifier component in an XMPP IRI/URI, it MUST ignore that fragment identifier component. 💜

2.7. Generation of XMPP IRIs/URIs 🏗️

2.7.1. Generation Method

Okay so, to form an XMPP IRI from an XMPP node identifier, domain identifier, and resource identifier, the generating app MUST first make sure the XMPP address follows the rules in [XMPP-CORE], including the relevant [STRINGPREP] stuff. Then it MUST concatenate the following:

The "xmpp" scheme and the ":" character
Optionally (if an authority component is to be included before the node identifier), the characters "//", an authority component of the form node@domain, and the character "/".
Optionally (if the XMPP address contained an XMPP "node identifier"), a string of Unicode characters that conforms to the "inodeid" rule, followed by the "@" character.
A string of Unicode characters that conforms to the "ihost" rule.
Optionally (if the XMPP address contained an XMPP "resource identifier"), the character "/" and a string of Unicode characters that conforms to the "iresid" rule.
Optionally (if a query component is to be included), the "?" character and query component.
Optionally (if a fragment identifier component is to be included), the "#" character and fragment identifier component.

To turn the resulting IRI into an XMPP URI, an app MUST adhere to the mapping procedure in Section 3.1 of [IRI]. 🔁

2.7.2. Generation Notes

Some characters are allowed in the node identifier, domain identifier, and resource identifier parts of a native XMPP address, but the "inodeid", "ihost", and "iresid" rules of an XMPP IRI ban them. 🙃 Specifically, the "#" and "?" characters are allowed in node identifiers, and the "/", "?", "#", and "@" characters are allowed in resource identifiers. But in XMPP IRIs these are delimiters, so they're a no-go. Also, the " " ([US-ASCII] space) character is allowed in resource identifiers but prohibited in IRIs. So all of these MUST be percent-encoded when transforming an XMPP address into an XMPP IRI. 🍓

Let's look at a nasty node in an XMPP address:

nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com

That address would be transformed into this XMPP IRI:

xmpp:nasty!%23$%25()*+,-.;=%3F[\]^_`{|}~node@example.com

Next, a repulsive resource in an XMPP address (split into two lines for layout purposes):

node@example.com
/repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource

That address would be transformed into this XMPP IRI (also split into two lines for layout purposes):

xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource

Also, basically any character outside the [US-ASCII] range is allowed in an XMPP address, and therefore in an XMPP IRI too. But URI syntax forbids those characters directly, and says they MUST be percent-encoded. 🌍 To figure out the URI for an XMPP IRI, an app MUST adhere to the mapping procedure in Section 3.1 of [IRI].

2.7.3. Generation Example

Let's try this XMPP address:

<ji&#x159;i@&#x10D;echy.example/v Praze>

Quick note 📝: "ř" stands for the Unicode character LATIN SMALL LETTER R WITH CARON, and "č" stands for the Unicode character LATIN SMALL LETTER C WITH CARON. That's the "XML Notation" [IRI] uses for characters that can't be rendered in ASCII-only documents. (These characters are also in their stringprep canonical form, which is very responsible of them 🤓.) The '<' and '>' characters aren't part of the address, they're just there to frame it. If you don't read Czech, this one could be Anglicized as "george@czech-lands.example/In Prague". 🇨🇿

Following the process above, the generating app would do this to make a valid XMPP IRI from that address:

Make sure the XMPP address follows the rules in [XMPP-CORE], including the relevant [STRINGPREP] profiles, and is encoded as a [UTF-8] string.
Concatenate the following:
1. The "xmpp" scheme and the ":" character.
2. An "authority component" if included (not shown in this example).
3. A string of Unicode characters that represents the XMPP address, transformed according to the "inodeid", "ihost", and "iresid" rules.
4. The "?" character followed by a "query component", if appropriate to the application (not shown in this example).
5. The "#" character followed by a "fragment identifier component", if appropriate to the application (not shown in this example).

The result is this XMPP IRI:

<xmpp:ji&#x159;i@&#x10D;echy.example/v%20Praze>

And to generate a valid XMPP URI from that IRI, the app MUST adhere to the procedure in Section 3.1 of [IRI], which gives us:

<xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>

2.8. Processing of XMPP IRIs/URIs 🔮

2.8.1. Processing Method

Okay bestie, this is where the processing app gets to do its thing 💅. If it's handed an XMPP URI and not an XMPP IRI, it MUST first convert the URI into an IRI by following the procedure in Section 3.2 of [IRI] 🦋.

To take apart an XMPP IRI so it can talk to the entity it points at, a processing application MUST separate:

The "xmpp" scheme and the ":" character.
The authority component, if it's included. This is the string of Unicode characters between the "//" characters and the next "/" character, the "?" character, the "#" character, or the end of the IRI.
A string of Unicode characters representing an XMPP address that has been transformed according to the "inodeid", "ihost", and "iresid" rules.
Optionally, the query component, if it's included, using the "?" character as a separator.
Optionally, the fragment identifier component, if it's included, using the "#" character as a separator.

At this point the processing application MUST make sure the resulting XMPP address follows the rules in [XMPP-CORE], including applying the relevant [STRINGPREP] ✨. Then it can either (1) finish the XMPP handling itself or (2) call a helper application to finish it. That XMPP handling would most likely look something like this:

If it isn't already connected to an XMPP server, it connects either as the user named in the authority component or as the configured user at the configured XMPP server. It usually does this by following the XMPP connection procedures in [XMPP-CORE]. (Note: The processing application SHOULD ignore the authority component if it has been configured with a set of default credentials.)
Optionally, it works out what kind of entity the intended recipient is (for example, via [JEP-0030]).
Optionally, it shows the user an interface that fits the kind of recipient and/or the contents of the query component.
It generates an XMPP stanza that turns any user or application inputs into their XMPP equivalents.
It sends the XMPP stanza over the authenticated server connection so it reaches the intended recipient 🚀.

2.8.2. Processing Notes

It might help implementors to know that the first two steps of "further XMPP handling," described at the end of Section 2.8.1, are similar to HTTP authentication ([HTTP-AUTH]). The next three steps are similar to how mailto: URIs get handled ([MAILTO]) 📬.

As noted in Section 2.7.2 of this document, some characters are allowed in the node identifier, domain identifier, and resource identifier parts of a native XMPP address, but the "inodeid", "ihost", and "iresid" rules of an XMPP IRI don't allow them. The percent-encoded octets for those characters in XMPP IRIs MUST be turned back into the characters that XMPP addresses allow when the XMPP IRI is processed for talking to the XMPP entity it represents 🙈.

Here's a messy node in an XMPP IRI:

   xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com

That IRI would be transformed into the following XMPP address:

   nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com

Here's a super extra resource in an XMPP IRI (split across two lines so it fits):

   xmpp:node@example.com
   /repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource

That IRI would be transformed into the following XMPP address (also split across two lines):

   node@example.com
   /repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource

2.8.3. Processing Example

Let's use the XMPP URI from the last example:

    <xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>

To make a valid XMPP IRI out of that URI, the application MUST follow the procedure in Section 3.2 of [IRI], which gives this IRI:

    <xmpp:ji&#x159;i@&#x10D;echy.example/v%20Praze>

Following the process above, the processing application would drop the "xmpp" scheme and the ":" character to pull out the XMPP address from this XMPP IRI. It also turns any percent-encoded octets from the "inodeid", "ihost", and "iresid" rules back into their characters. For example, "%20" becomes a space character 🌸.

The result is this XMPP address:

    <ji&#x159;i@&#x10D;echy.example/v Praze>

2.9. Internationalization

XMPP addresses are [UTF-8] strings, and octets outside the [US-ASCII] range in XMPP addresses can be turned into percent-encoded octets really easily. That's why XMPP addresses work so well with Internationalized Resource Identifiers ([IRI]) 🌈. Apart from stringprep checking, converting syntax-relevant [US-ASCII] characters (like "?"), and turning percent-encoded octets from the "inodeid", "ihost", and "iresid" rules back into their characters (like "%20" becoming the [US-ASCII] space character), you can build an XMPP IRI straight from an XMPP address just by putting the "xmpp" scheme and ":" character in front of it. An XMPP IRI can also be turned into URI syntax by following the procedure in Section 3.1 of [IRI]. An XMPP URI can be turned into IRI syntax by following the procedure in Section 3.2 of [IRI]. This keeps things working with apps that can handle URIs but can't handle IRIs 🫶.

3. IANA Registration of xmpp URI Scheme ✨

In accordance with [URI-SCHEMES], this section has the info needed to register the xmpp URI scheme 💜.

3.1. URI Scheme Name

xmpp

3.2. Status

permanent

3.3. URI Scheme Syntax

The syntax for an xmpp URI is defined below using Augmented Backus-Naur Form as specified by [ABNF]. The "fragment", "host", "pct-encoded", and "unreserved" rules are defined in [URI], and DQUOTE is defined in [ABNF]:

     xmppuri   = "xmpp" ":" hierxmpp [ "?" querycomp ] [ "#" fragment ]
     hierxmpp  = authpath / pathxmpp
     authpath  = "//" authxmpp [ "/" pathxmpp ]
     authxmpp  = nodeid "@" host
     pathxmpp  = [ nodeid "@" ] host [ "/" resid ]
     nodeid    = *( unreserved / pct-encoded / nodeallow )
     nodeallow = "!" / "$" / "(" / ")" / "*" / "+" / "," / ";" /
                 "=" / "[" / "\" / "]" / "^" / "`" / "{" / "|" /
                 "}"
     resid     = *( unreserved / pct-encoded / resallow )
     resallow   = "!" / DQUOTE / "$" / "&" / "'" / "(" / ")" /
                  "*" / "+" / "," / ":" / ";" / "<" / "=" / ">" /
                  "[" / "\" / "]" / "^" / "`" / "{" / "|" / "}"
     querycomp = querytype [ *pair ]
     querytype = *( unreserved / pct-encoded )
     pair      = ";" key "=" value
     key       = *( unreserved / pct-encoded )
     value     = *( unreserved / pct-encoded )

3.4. URI Scheme Semantics

The xmpp URI scheme identifies entities that natively communicate using the Extensible Messaging and Presence Protocol (XMPP). It's mainly used for identification rather than locating resources 🔍. Still, if an application processing an xmpp URI lets someone interact with the XMPP address the URI identifies, it MUST follow the methodology in Section 2 of RFC 4622, Use of XMPP IRIs and URIs. That means rebuilding the encapsulated XMPP address, connecting to an appropriate XMPP server, and sending an appropriate XMPP "stanza" (XML fragment) to the XMPP address. (Note: There is no MIME type associated with the xmpp URI scheme.)

3.5. Encoding Considerations

Besides XMPP URIs, there are also XMPP Internationalized Resource Identifiers (IRIs). Before an Extensible Messaging and Presence Protocol (XMPP) address gets turned into an IRI (following [XMPP-CORE]), the generating application has to represent the address as [UTF-8]. For example, it might turn its internal UTF-16 string into a UTF-8 string. Then the UTF-8 string gets the "xmpp" scheme and ":" character added in front. However, an XMPP URI can only contain [US-ASCII] characters, so the UTF-8 string of an XMPP IRI has to be transformed into URI syntax by following the procedure in RFC 3987 🧩.

3.6. Applications/protocols That Use This URI Scheme Name

The xmpp URI scheme is meant for interfaces to an XMPP network from non-native user agents, like web browsers. It's also for non-native applications that need to identify XMPP entities as full URIs or IRIs 🌐.

3.7. Interoperability Considerations

There are no known interoperability concerns with the xmpp URI scheme. To help keep things interoperable, the Jabber Registrar function of the Jabber Software Foundation keeps a registry of query types and keys that can be used in the query components of XMPP URIs and IRIs. You'll find it at <http://www.jabber.org/registrar/querytypes.html> 📒.

3.8. Security Considerations

See Section 5 of RFC 4622, Security Considerations 🔐.

3.9. Contact

Peter Saint-Andre [mailto:stpeter@jabber.org, xmpp:stpeter@jabber.org]

3.10. Author/Change Controller

This scheme is registered under the IETF tree, so the IETF is in charge of change control 👑.

3.11. References

[XMPP-CORE]

4. IANA Considerations

This document registers a URI scheme. The registration template is in Section 3 of this document. To help keep things interoperable, the Jabber Registrar function of the Jabber Software Foundation keeps a registry of query types and keys that can be used in the query components of XMPP URIs and IRIs. You'll find it at <http://www.jabber.org/registrar/querytypes.html> 🎀.

5. Security Considerations

Okay, this part is serious, bestie 😭. Giving non-native apps an interface to XMPP services brings in new security concerns 🚨. The security considerations in [IRI], [URI], and [XMPP-CORE] apply to XMPP IRIs. The ones in [URI] and [XMPP-CORE] apply to XMPP URIs. Following Section 2.7 of [URI-SCHEMES] and Section 7 of [URI], the particular security considerations are laid out in the following sections 💀.

5.1. Reliability and Consistency ✨

okay so addresses that look like node@domain.tld are usually made when someone registers at an XMPP server, or when an admin provisions one 🧚. that also means they can be unregistered or deprovisioned, so the XMPP IRI/URI pointing at one may not be reliably and consistently tied to the same principal, account owner, application, or device 💀.

node@domain.tld/resource addresses are even more ephemeral 🦋. A resource identifier is usually tied to one temporary session of a client at a server, so the IRI/URI for it probably will not reliably and consistently be associated with the same session. BUT the procedures in Section 10 of [XMPP-CORE] effectively wipe out any confusion that the lack of reliability and consistency could cause, so we're good 🫶.

domain.tld addresses are the long-lived queens of XMPP: servers or associated services 👑. Admins can always decommission a server or service at any time, but the IRIs/URIs for these are typically the most reliable and consistent XMPP IRIs/URIs out there.

domain.tld/resource addresses aren't super common on XMPP networks yet 🌸. Their reliability and consistency would likely land somewhere between domain.tld addresses and node@domain.tld addresses.

5.2. Malicious Construction 🙈

The ban on port numbers in XMPP IRIs/URIs makes malicious construction less likely, because port numbers are supposed to be discovered through [DNS-SRV] records, as specified in [XMPP-CORE]. no port number to play with, no sneaky business 🔒.

5.3. Back-End Transcoding 🍓

The base XMPP protocol is built to swap messages and presence info, not to fetch files or call system functions, so it's considered unlikely that using XMPP IRIs/URIs would lead to harmful dereferencing 💜. HOWEVER, if an XMPP protocol extension defines methods for retrieving information, it MUST define appropriate controls over access to that information. Also, XMPP servers SHOULD NOT natively parse XMPP IRIs/URIs. Instead they SHOULD accept only the XML wire protocol specified in [XMPP-CORE], plus any extensions the server wants ✨.

5.4. Sensitive Information 🕵️‍♀️

Being able to interact with XMPP entities through a web browser or another non-native app can expose sensitive info, like which XMPP application protocol extensions someone supports 🙀. That can make attacks possible, or more likely, that just wouldn't work on a native XMPP network. Due care must be taken when deciding what info belongs in XMPP IRIs or URIs 💅.

Putting XMPP IRIs/URIs in public places, like websites, can make it easier for bad actors to harvest XMPP addresses from the authority and path components, and then spam the users or applications behind those addresses with unsolicited bulk messages 📬. Due care should be taken to balance the perks of open information exchange against the cost of unwanted communications.

To help stop sensitive info from leaking, passwords and other user credentials are forbidden in the authority component of XMPP IRIs/URIs. Honestly they aren't even needed, because XMPP authenticates through [SASL], which means you can use the SASL ANONYMOUS mechanism if you want 🎀.

5.5. Semantic Attacks 🌈

Even though non-hierarchical URI schemes like [MAILTO] exist, people kind of expect every URI to have the "//" characters after the scheme name and the ":" character 🤔. In XMPP IRIs/URIs, though, the "//" characters come before the authority component, not the path component. So xmpp://guest@example.com means "authenticate as 'guest@example.com'", while xmpp:guest@example.com identifies the node "guest@example.com" 🧠.

Processing applications MUST clearly tell these two forms apart. User agents SHOULD discourage humans from putting "//" in XMPP IRIs/URIs, since the authority component is only really useful in specialized scenarios, not everyday ones 🙅‍♀️.

5.6. Spoofing 🎭

Being able to use basically the full range of Unicode characters in an XMPP IRI can make address mimicking (also called "spoofing") easier to pull off 😬. XMPP IRIs aren't any different from other IRIs here, though. Applications that will show XMPP IRIs to humans must adhere to best practices on address mimicking to help prevent attacks from spoofed addresses, like the phenomenon known as "phishing" 🎣. For the details, check the Security Considerations of [IRI].

6. References 📚

6.1. Normative References

[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.

6.2. Informative References 🦋

[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[HTML] Raggett, D., "HTML 4.0 Specification", W3C REC REC-html40-19980424, April 1998.
[HTTP-AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[JEP-0009] Adams, D., "Jabber-RPC", JSF JEP 0009, February 2006.
[JEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", JSF JEP 0030, January 2006.
[JEP-0045] Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, September 2005.
[JEP-0053] Saint-Andre, P., "Jabber Registrar", JSF JEP 0053, May 2004.
[JEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", JSF JEP 0060, June 2005.
[JEP-0072] Forno, F. and P. Saint-Andre, "SOAP Over XMPP", JSF JEP 0072, December 2005.
[JEP-0077] Saint-Andre, P., "In-Band Registration", JSF JEP 0077, January 2006.
[JEP-0147] Saint-Andre, P., "XMPP IRI/URI Query Components", JSF JEP 0147, March 2006.
[MAILTO] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[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/).

[URI-SCHEMES] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, February 2006.
[US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.

Author's Address 💌

Peter Saint-Andre Jabber Software Foundation

EMail: stpeter@jabber.org

URI: xmpp:stpeter@jabber.org

Full Copyright Statement 💜

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ✨

okay bestie, so the IETF is NOT taking a side on whether any IPR claims are valid or how far they reach 🙅‍♀️ and it's also not saying it went digging to find any. the might-or-might-not licensing stuff? totally unclear, no cap. if you want the rules for IPR in RFC docs, check out BCP 78 and BCP 79 💅

the receipts for IPR disclosures sent to the IETF Secretariat, plus any promised licenses, plus whatever happened when someone tried to get a general license or permission to use the proprietary stuff (for implementers or users of this spec), all live in the IETF's online IPR repository at http://www.ietf.org/ipr 🗂️

and the IETF literally invites anyone to speak up 📣 if they know about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send it to ietf-ipr@ietf.org 💌 bestie, this is the spot where you flag it!!

Acknowledgement 🫶

the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) 💖 so that's who keeps the lights on for the RFC Editor 🌈

📦 where this page comes from

ietf: rfc4622 2006-08
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms