Internationalized Addresses in XMPP
draft-saintandre-xmpp-i18n-00

Abstract

XMPP as defined in RFC 3920 uses stringprep in the preparation and comparison of non-ASCII characters within JabberIDs. This document explores whether it makes sense to use stringprep in the document that supersedes RFC 3920.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 3, 2010.

Copyright Notice

Copyright (c) 2010 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Background
3.  Recommendations
    3.1.  Domainpart
    3.2.  Localpart
    3.3.  Resourcepart
4.  Security Considerations
5.  IANA Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Author's Address

1.  Introduction

The Extensible Messaging and Presence Protocol as defined in [XMPP] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) uses stringprep [STRINGPREP] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.) in the preparation and comparison of non-ASCII characters within JabberIDs (JIDs). XMPP addresses are of the form <localpart@domainpart/resourcepart>, where the localpart and resourcepart are optional but quite common. RFC 3920 did the following: (1) specified the use of IDNA2003 [IDNA] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) and Nameprep [NAMEPREP] (Hoffman, P. and M. Blanchet, “Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN),” March 2003.) for the domainpart of a JID, (2) defined the Nodeprep profile of stringprep for the localpart of a JID, and (3) defined the Resourceprep profile of stringprep for the resourecepart of a JID. The change from stringprep in IDNA2003 to an inclusion approach to internationalized addresses in IDNA2008 (see for example [RATIONALE] (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale,” January 2010.)) raises the question whether it makes sense for XMPP to also change its approach to the preparation and comparison of non-ASCII characters in the localpart and resourcepart aspects of a JID. Therefore this document explores the issue of internationalized addresses in XMPP as input to the revisions captured more formally in [XMPPBIS] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” November 2009.).

2.  Background

The inclusion approach in IDNA2008 makes sense because domain names were always limited to the letter-digits-hyphen ("LDH") pattern; the progression to non-ASCII simply introduced more characters that might qualify as letters and (in some cases) digits. Extrapolating from that pattern, [RATIONALE] (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale,” January 2010.) argues that there is no good reason for a domain name to include characters such as symbols (e.g., hearts and stars), since the purpose of a domain name is to provide a stable identifier for communication and interaction over the Internet, not a personally expressive name for a person or a fun tag for information.

The localpart and resourcepart of a JID might serve a different kind of purpose. Many end users of XMPP-based instant messaging (IM) systems might expect that the username (localpart) portion of a JID could be expressive of their identity in some way. Similarly, occupants of XMPP-based chatrooms might expect that their in-room nickname (resourcepart) could be a fun conversation-starter, perhaps even more so than a normal username; for example, a regular visitor to an XMPP chatroom that I frequent has an in-room nickname of "The King" where "King" is represented by the Unicode codepoint 'BLACK CHESS KING' (U+265A). Such characters might difficult to communicate in some contexts (e.g., in screen readers for the blind), but are expressive and fun, which is not an unimportant consideration for many IM users.

Does the desire for an expressive username or nickname trump the need for human-readable identifiers? Given the wide implementation of full-Unicode addresses in user-oriented XMPP applications, IM client developers seem to think so.

These admittedly anecdotal and subjective considerations vaguely indicate that the inclusion approach pursued in the IDNA2008 initiative is quite appropriate for the more restricted class of domain names but perhaps not as appropriate for the localpart or resourcepart of an XMPP address.

That being said, some XMPP implementations (e.g., a custom client) or deployments (e.g., a military system) might wish to "lock down" the expressive potential of XMPP addresses. Currently there is no way for an implementation or deployment to do so in standardized manner that can be communicated to other entities on the network (e.g., during account provisioning). Given that a deployed XMPP service acts in some ways like a registrar does for domain names, such methods might be helpful, even if out of scope for [XMPPBIS] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” November 2009.).

3.  Recommendations

This document does not yet provide definitive recommendations, but instead mainly seeks to foster discussion about internationalized addresses in XMPP. However, there are three possible approaches that the XMPP WG might pursue in relation to its existing stringprep profiles:

1. Keep using Nameprep, Nodeprep, and/or Resourceprep as they are defined today.
2. Collaborate with other interested parties or working groups to define a new version of stringprep that tracks changes to Unicode since Unicode 3.2 as currently specified in [STRINGPREP] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.).
3. Pursue the general model followed in the IDNA2008 work by defining a tiered model of valid, disallowed, and unassigned characters; such an effort might be pursued only within the XMPP community (for Nodeprep, Resourceprep, or both) or more generally in concert with other users of stringprep.

The XMPP WG might even decide to use a mix of these approaches, e.g. to use the new, non-stringprep IDNA2008 approach for domainparts but the existing Nodeprep and Resourceprep profiles for localparts and resourceparts.

3.1.  Domainpart

RFC 3920 specifies the use of IDNA2003 for the domainpart of a JID. This document does not question the reasoning behind the IDNA2008 work and therefore recommends the use of IDNA2008 technologies in [XMPPBIS] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” November 2009.).

3.2.  Localpart

This document does not yet provide a recommendation regarding the localpart of a JID (e.g., whether to replace or update the Nodeprep profile of stringprep).

3.3.  Resourcepart

This document does not yet provide a recommendation regarding the resourcepart of a JID (e.g., whether to replace or update the Resourceprep profile of stringprep).

4.  Security Considerations

The inclusion of non-ASCII characters in XMPP addresses has important security implications, such as the ability to mimic characters or entire addresses. These issues are explored at some length in [MIMIC] (Saint-Andre, P., “Best Practices to Discourage JID Mimicking,” December 2007.). Other security considerations might apply and will be described in a future version of this specification.

5.  IANA Considerations

This document has no actions for the IANA.

6.  References

6.1. Normative References

6.2. Informative References

Author's Address