JEP-0106: JID Escaping

Allow the display of Jabber Identifiers (JIDs) with characters prohibited by the Nodeprep profile of stringprep.

WARNING: Consideration of this JEP has been Deferred by the Jabber Software Foundation. Implementation of the protocol described herein is not recommended.

JEP Information

Status: Deferred
Type: Standards Track
Number: 0106
Version: 0.2
Last Updated: 2003-10-21
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: jid#20;escaping

Author Information

Joe Hildebrand

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. 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 <http://www.opencontent.org/openpub/>).

Discussion Venue

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core and XMPP IM 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.

1. Introduction

XMPP Core [1] defines the Nodeprep profile of stringprep (RFC 3454 [2]), which specifies that the following characters are invalid in the node identifier portion of a JID:

This restriction is a hardship for users who have these characters in their chosen usernames, particularly in the case of ('), which is common in names like O'Hara and D'Artagnan. The restriction is especially onerous if existing email addresses are mapped to JIDs, since some of the foregoing characters are allowed in the username portion of an email address. If (&) had not been in this list, then normal XML escaping conventions could have been used, and, for example, D'Artagnan could have been rended as d'artagnan [sic]. Since there are good reasons for each of the prohibited characters above, another escaping mechanism is desirable.

Although URL encoding (%27) was one possibility, since % is such an often-used character in JIDs (e.g, to replace @ in gateway addresses), this approach was rejected. Future gateways SHOULD use the approach specified by this JEP, instead.

2. Requirements

3. Use Cases

All transformations are exactly as specified. CASE IS SIGNIFICANT. Lowercase was selected since Nodeprep will case fold to lowercase.

3.1 Encoding Transformation

The following escaping transformations MAY be used by a conforming entity. Typically, this will only be done by a client that is retrieving information from a user in unescaped form, or by a gateway to some external system that needs to generate a JID.

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

Example 1. JID Encoding: Porthos starts a chat, typing into his client the JID d'artagnan@musketeers.bourbon.gov:

<message 
    from='porthos@musketeers.bourbon.gov/gate'
    to='d#27;artagnan@musketeers.bourbon.gov'
    type='chat'>
  <body>And do you always forget your eyes when you run?</body>
</message>

3.2 Decoding Transformation

The opposite unescaping transformations MAY be used by a conforming entity. Typically, this is only done by clients that want to display JIDs, and gateways that need to generate identifiers for foreign systems.

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

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

<message 
    from='d#27;artagnan@gascon.fr/elder'
    to='tréville%musketeers.bourbon.gov@smtp.jabber.org'>
  <body>I recommend my son to you.</body>
</message>

3.3 Discovery

If a client is going to encode identifiers for use by a gateway, the client needs to know which encoding scheme to use. Clients MUST assume that the gateway does not support this encoding scheme, unless it discovers that the service supports the jid#20;escaping [sic] feature. Namely, if there any errors in the disco exchange, or the jid#20;escaping feature is not discovered, the client SHOULD use the older escaping mechanism (@ transforms to %).

Example 3. Client requests features

<iq
    type='get'
    from='porthos@musketeers.bourbon.gov/gate'
    to='irc.shakespeare.lit'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 4. Service responds with features

<iq
    type='get'
    to='porthos@musketeers.bourbon.gov/gate'
    from='irc.shakespeare.lit'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
...
    <feature var='jid#20;escaping'/>
  </query>
</iq>

3.4 Exceptions

In order to maintain as much backward compatibility as possible, JIDs that contain partial escape sequences, or escape sequences that are not on the list, MUST be ignored.

Example 5. Partial escape sequence

foo#bar is not modified by escaping or unescaping transformations

Example 6. Invalid escape sequence

foob#41;r is not modified by escaping or unescaping transformations

4. Rules

As far as the bulk of the system is concerned, an escaped JID has no special processing associated with it. Clients SHOULD render them unescaped. Servers MAY unescape them for communication with external systems (e.g. LDAP), but only AFTER stringprep has been applied. The unescape transformation MUST be NFKC-safe -- i.e., it must conform to Unicode normalization form KC (see Appendix B.3 of RFC 3454). An entity MUST NOT use the unescaped version in any protocol sent to another entity, and MUST NOT use the unescaped version to compare with another JID. Note well: this JEP applies to the node identitier portion of a JID only, and MUST NOT be applied to domain identifiers or resource identifiers.

5. Error Codes

6. Security Considerations

Entities that enforce JID escaping MUST compare unescaped versions, otherwise a JID conflict could occur.

7. IANA Considerations

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

8. Jabber Registrar Considerations

The jid#20;escaping feature shall be registered with the Jabber Registrar [4] as a result of this JEP.

Notes

3. 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 <http://www.iana.org/>.

4. 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 <http://www.jabber.org/registrar/>.