JEP-0106: JID Escaping

This JEP specifies a mechanism that enables the display of Jabber Identifiers (JIDs) with characters disallowed by the Nodeprep profile of stringprep.

NOTICE: This JEP is currently within Last Call or under consideration by the Jabber Council for advancement to the next stage in the JSF standards process. For further details, visit <>.

JEP Information

Status: Proposed
Type: Standards Track
Number: 0106
Version: 0.5
Last Updated: 2005-04-21
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0030
Supersedes: None
Superseded By: None
Short Name: jid#20;escaping

Author Information

Joe Hildebrand


Peter Saint-Andre


Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "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.

Table of Contents

1. Introduction
2. Requirements
3. Transformations
3.1. Concepts
3.2. Encoding Transformation
3.3. Decoding Transformation
4. Discovery
5. Business Rules
5.1. Exceptions
5.2. Processing
5.3. JID Escaping vs. Older Methods
6. Security Considerations
7. IANA Considerations
8. Jabber Registrar Considerations
8.1. Service Discovery Features
Revision History

1. Introduction

XMPP Core [1] defines the Nodeprep profile of stringprep (RFC 3454 [2]), which specifies that the following Unicode code points are disallowed in the node identifier portion of a JID (hereafter we refer to these as "the disallowed characters"):

This restriction is an inconvenience for users who have one or more of the foregoing nine disallowed characters in their desired usernames, particularly in the case of the ' character, which is common in names like O'Hara and D'Artagnan. The restriction is a positive hardship if existing email addresses are mapped to JIDs, since some of the disallowed characters are allowed in the username portion of an email address (e.g., the characters & ' / as described in sections 3.2.4 and 3.2.5 of RFC 2822 [3]).

If the & character had not been in the list of disallowed characters, then normal XML escaping conventions (as specified in XML 1.0 [4]) could have been used, with the result that D'Artagnan (for example) could have been rendered as D&apos;artagnan [sic]. Since there are good reasons for each of the disallowed characters, another escaping mechanism is needed.

It might have been desirable to use percent-encoding (e.g., %27 for the ' character) as specified in Section 2.1 of RFC 3986 [5]. However, that approach was rejected since the % character is an often-used character in JIDs (e.g., to replace the @ character in gateway addresses) and the resulting ambiguity would have caused confusion and, most likely, misdelivered or undeliverable XML stanzas. Therefore, a new mechanism is described herein to escape only the disallowed characters and only in the node identifier portion of Jabber IDs.

2. Requirements

This JEP addresses the following requirements:

  1. The escaping mechanism shall apply to the node identitier portion of a JID only, and MUST NOT be applied to domain identifiers or resource identifiers.
  2. Escaped JIDs MUST conform to the definition of a Jabber ID as specified in RFC 3920, including the Nodeprep profile of stringprep. In particular this means that even after passing through Nodeprep, the JID MUST be valid, with the result that Unicode look-alikes like U+02BC (Modifier Letter Apostrophe) MUST NOT be used.
  3. It MUST NOT be possible for clients to use this escaping mechanism to avoid the goal of stringprep; namely, that JIDs that look alike should have same character representation after being processed by stringprep. Therefore, this mechanism MUST NOT be applied to any characters other than the disallowed characters.
  4. Existing JIDs that include portions of the escaping mechanism MUST continue to be valid.
  5. The escaping mechanism SHOULD NOT place undue strain upon server implementations; implementations or deployments that do not need to unescape SHOULD be able to ignore the escaping mechanism.

3. Transformations

3.1 Concepts

Rather than encoding a disallowed character as %hexhex as in URI syntax, this JEP specifies encoding such a character as #hexhex; where "hexhex" is the hexadecimal value of the Unicode code point in question, ignoring the leading "00" in the code point (e.g., 27 for the ' character, resulting in an encoding of #27;). Full encoding and decoding transformations for all nine disallowed characters are provided in the following sections.

Note: All transformations are exactly as specified below. CASE IS SIGNIFICANT. Lowercase was selected since Nodeprep will case fold to lowercase for US-ASCII characters such as A, C, E, and F.

3.2 Encoding Transformation

The encoding transformations are defined in the following table. Typically, encoding is performed only by a client that is processing information provided by a human user in unescaped form, or by a gateway to some external system (e.g., email or LDAP) that needs to generate a JID.

Table 1: Mapping from Unescaped to Encoded Characters

Unescaped Character Encoded Character
<space> #20;
" #22;
# #23;
& #26;
' #27;
/ #2f;
: #3a;
< #3c;
> #3e;
@ #40;

Example 1. JID Encoding: Porthos starts a chat, typing into his client the JID d'

  <body>And do you always forget your eyes when you run?</body>

3.3 Decoding Transformation

The decoding transformations are defined in the following table. Typically, decoding is performed only by a client that wants to display JIDs containing encoded characters to a human user, or by a gateways to some external system (e.g., email or LDAP) that needs to generate identifiers for foreign systems.

Table 2: Mapping from Encoded to Decoded Characters

Encoded Character Decoded Character
#20; <space>
#22; "
#23; #
#26; &
#27; '
#2f; /
#3a; :
#3c; <
#3e; >
#40; @

Example 2. JID Encoding: D'Artagnan the elder sends SMTP mail through a gateway:

  <body>I recommend my son to you.</body>

4. Discovery

If an entity needs to discover whether another entity supports JID escaping, it MUST send a disco#info request to the other entity as specified in Service Discovery [6].

Example 3. Client requests features

  <query xmlns=''/>

If the queried entity supports JID escaping, it MUST return a jid#20;escaping [sic] feature in its reply.

Example 4. Service responds with features

  <query xmlns=''>
    <feature var='jid#20;escaping'/>

5. Business Rules

5.1 Exceptions

In order to maintain as much backward compatibility as possible, partial escape sequences and escape sequences corresponding to characters not on the list of disallowed characters MUST be ignored.

Example 5. Partial escape sequence 1

the#1solution is not modified by encoding or decoding transformations.

Example 6. Partial escape sequence 2

#1;#2;#3; is not modified by encoding or decoding transformations.

Example 7. Invalid escape sequence 1

foo#ba;r is not modified (to fooºr) by encoding or decoding transformations.

Example 8. Invalid escape sequence 2

foob#41;r is not modified (to foobAr) by encoding or decoding transformations.

5.2 Processing

The following processing rules apply:

  1. A client SHOULD render an encoded character as its decoded equivalent when presenting it to a human user.
  2. A server MAY decode an encoded character for communication with external systems (e.g. LDAP), but only after the Nodeprep profile of stringprep has been applied.
  3. The decoding transformation MUST be NFKC-safe -- i.e., it MUST conform to Unicode normalization form KC (see Appendix B.3 of RFC 3454).
  4. An entity MUST NOT include the unescaped or decoded version of an encoded character over the wire in any XML stanzas sent to another entity.
  5. An entity MUST NOT use the unescaped or decoded version of an encoded character when comparing two JIDs.

5.3 JID Escaping vs. Older Methods

When a client attempts to communicate with another entity through a gateway, it needs to know which encoding mechanism to use. A client MUST assume that the gateway does not support the JID escaping mechanism unless it explicitly discovers support via Service Discovery as shown above. If there any errors in the service discovery exchange or if support for the jid#20;escaping [sic] feature is not discovered, the client SHOULD proceed as follows:

  1. If the gateway supports the 'jabber:iq:gateway' protocol (as specified in Gateway Interaction [7]), use that protocol.
  2. If the gateway does not support the 'jabber:iq:gateway' protocol, use customary escaping mechanisms (such as the transformation of the @ character to the % character).

6. Security Considerations

Entities that enforce JID escaping MUST compare unescaped/decoded versions, otherwise stanzas could be directed to an incorrect JID.

7. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [8].

8. Jabber Registrar Considerations

8.1 Service Discovery Features

The Jabber Registrar [9] shall include the jid#20;escaping [sic] feature in its registry of service discovery features.


1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <>.

2. RFC 3454: Preparation of Internationalized Strings (stringprep) < >.

3. RFC 2822: Internet Message Format <>.

4. Extensible Markup Language (XML) 1.0 (Third Edition) <>.

5. RFC 3986: Uniform Resource Identifiers (URI): Generic Syntax <>.

6. JEP-0030: Service Discovery <>.

7. JEP-0100: Gateway Interaction <>.

8. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <>.

9. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <>.

Revision History

Version 0.5 (2005-04-21)

Used U+00xx format for code points; added references to various RFCs; corrected terminology; cleaned up text and flow. (psa)

Version 0.4 (2005-04-04)

Corrected several small textual errors and ambiguities; slightly reorganized textual flow. (psa)

Version 0.3 (2005-03-16)

Clarified relationship between JID escaping and traditional client proxy gateway behavior; fixed several small errors. (psa)

Version 0.2 (2003-10-21)

Editorial cleanup; added security considerations. (psa)

Version 0.1 (2003-07-21)

Initial version. (jjh)