One document matched: draft-saintandre-xmpp-i18n-01.txt

Differences from draft-saintandre-xmpp-i18n-00.txt

None                                                      P. Saint-Andre
Internet-Draft                                                     Cisco
Intended status: Standards Track                           March 2, 2010
Expires: September 3, 2010


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

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



Saint-Andre             Expires September 3, 2010               [Page 1]

Internet-Draft                  XMPP I18N                     March 2010


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Domainpart  . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.2.  Localpart . . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Resourcepart  . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7






























Saint-Andre             Expires September 3, 2010               [Page 2]

Internet-Draft                  XMPP I18N                     March 2010


1.  Introduction

   The Extensible Messaging and Presence Protocol as defined in
   [XMPP-CORE] uses stringprep [STRINGPREP] 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] and
   Nameprep [NAMEPREP] 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]) 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].


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] 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 an
   unambiguous, memorable label for identifying and referring to
   resources on the Internet, not a personally expressive "handle" or a
   fun "tag" for interaction.

   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 -- even at the expense of reliability.




Saint-Andre             Expires September 3, 2010               [Page 3]

Internet-Draft                  XMPP I18N                     March 2010


   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 to limit provisioned addresses
   to a particular subset or version of Unicode, to specify which
   scripts, languages, code points, and text directions are supported,
   etc.  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; they are out of
   scope for [XMPPBIS] but might be considered by the XMPP Standards
   Foundation (e.g., in revisions to or a replacement for [IBR].

   Furthermore, did not provide any guidance regarding scripts that are
   written right to left.  This oversight might need to be remedied in
   [XMPPBIS], and [BIDI] might prove helpful in such work.

   Finally, any move away from Nameprep, Nodeprep, and Resourceprep as
   they are defined today will inevitably introduce the potential for
   migration issues, such as JIDs that were not ambiguous before the
   migration but that become ambiguous after the migration.  These
   issues need to be clearly defined and well understood so that the
   costs and benefits of any change can be properly assessed --
   especially if the change might have an impact on authentication
   (e.g., as described in [XMPP-CORE]), authorization (e.g., presence
   subscriptions as described in [XMPP-IM]), access (e.g., joining a
   chatroom as described in [MUC]), identification (e.g., in XMPP URIs
   or IRIs as described in [XMPP-URI]), and other security-related
   functions.


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



Saint-Andre             Expires September 3, 2010               [Page 4]

Internet-Draft                  XMPP I18N                     March 2010


   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].
   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
   (which in the terms of IDNA2008 [DEFS] is a "domain name slot").
   This document does not question the reasoning behind the IDNA2008
   work and therefore recommends the use of IDNA2008 technologies in
   [XMPPBIS].

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 through the inclusion of "confusable characters"
   (see [REVIEW] and [DEFS]).  These issues are explored at some length
   in [MIMIC].  Other security considerations might apply and will be
   described in a future version of this specification.




Saint-Andre             Expires September 3, 2010               [Page 5]

Internet-Draft                  XMPP I18N                     March 2010


5.  IANA Considerations

   This document has no actions for the IANA.


6.  References

6.1.  Normative References

   [IDNA]     Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [NAMEPREP]
              Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
              Profile for Internationalized Domain Names (IDN)",
              RFC 3491, March 2003.

   [STRINGPREP]
              Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              December 2002.

   [XMPP-CORE]
              Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

6.2.  Informative References

   [BIDI]     Alvestrand, H. and C. Karp, "Right-to-left scripts for
              IDNA", draft-ietf-idnabis-bidi-07 (work in progress),
              January 2010.

   [DEFS]     Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              draft-ietf-idnabis-defs-13 (work in progress),
              January 2010.

   [IBR]      Saint-Andre, P., "In-Band Registration", XSF XEP 0077,
              September 2009.

   [MIMIC]    Saint-Andre, P., "Best Practices to Discourage JID
              Mimicking", XSF XEP 0165, December 2007.

   [MUC]      Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
              January in progress, last updated 2010.

   [RATIONALE]



Saint-Andre             Expires September 3, 2010               [Page 6]

Internet-Draft                  XMPP I18N                     March 2010


              Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", draft-ietf-idnabis-rationale-17 (work in
              progress), January 2010.

   [REVIEW]   Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
              Recommendations for Internationalized Domain Names
              (IDNs)", RFC 4690, September 2006.

   [XMPP-IM]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 3921, October 2004.

   [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.

   [XMPPBIS]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-04 (work
              in progress), November 2009.


Author's Address

   Peter Saint-Andre
   Cisco

   Email: psaintan@cisco.com





















Saint-Andre             Expires September 3, 2010               [Page 7]