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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>

<rfc category="std" docName="draft-saintandre-xmpp-i18n-01" ipr="trust200902">

  <front>
    <title abbrev="XMPP I18N">Internationalized Addresses in XMPP</title>

    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>Cisco</organization>
      <address>
        <email>psaintan@cisco.com</email>
      </address>
    </author>

    <date day="2" month="March" year="2010"/>
    <area>Applications</area>
    <workgroup>None</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>

    <section title="Introduction" anchor="intro">
      <t>The Extensible Messaging and Presence Protocol as defined in <xref target='XMPP-CORE'/> uses stringprep <xref target='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 <xref target='IDNA'/> and Nameprep <xref target='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 <xref target='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 <xref target='XMPPBIS'/>.</t>
    </section>

    <section title="Background" anchor="background">
      <t>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, <xref target='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.</t>
      <t>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.</t>
      <t>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.</t> 
      <t>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.</t>
      <t>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 <xref target='XMPPBIS'/> but might be considered by the XMPP Standards Foundation (e.g., in revisions to or a replacement for <xref target='IBR'/>.</t>
      <t>Furthermore, did not provide any guidance regarding scripts that are written right to left.  This oversight might need to be remedied in <xref target='XMPPBIS'/>, and <xref target='BIDI'/> might prove helpful in such work.</t>
      <t>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 <xref target='XMPP-CORE'/>), authorization (e.g., presence subscriptions as described in <xref target='XMPP-IM'/>), access (e.g., joining a chatroom as described in <xref target='MUC'/>), identification (e.g., in XMPP URIs or IRIs as described in <xref target='XMPP-URI'/>), and other security-related functions.</t>
    </section>

    <section title="Recommendations" anchor="recommendations">

      <t>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:</t>
      <t>
        <list style='numbers'>
          <t>Keep using Nameprep, Nodeprep, and/or Resourceprep as they are defined today.</t>
          <t>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 <xref target='STRINGPREP'/>.</t>
          <t>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.</t>
        </list>
      </t>
      <t>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.</t>

      <section title="Domainpart" anchor="domainpart">
        <t>RFC 3920 specifies the use of IDNA2003 for the domainpart of a JID (which in the terms of IDNA2008 <xref target='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 <xref target='XMPPBIS'/>.</t>
      </section>

      <section title="Localpart" anchor="localpart">
        <t>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).</t>
      </section>

      <section title="Resourcepart" anchor="resourcepart">
        <t>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).</t>
      </section>

    </section>

    <section title="Security Considerations" anchor="security">
      <t>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 <xref target='REVIEW'/> and <xref target='DEFS'/>).  These issues are explored at some length in <xref target='MIMIC'/>.  Other security considerations might apply and will be described in a future version of this specification.</t>
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>This document has no actions for the IANA.</t>
    </section>

  </middle>

  <back>

    <references title="Normative References">

<reference anchor='IDNA'>
<front>
<title>Internationalizing Domain Names in Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='A.' surname='Costello' fullname='A. Costello'>
<organization /></author>
<date month='March' year='2003' /></front>
<seriesInfo name='RFC' value='3490' />
<format type='TXT' octets='51943' target='ftp://ftp.isi.edu/in-notes/rfc3490.txt' />
</reference>

<reference anchor="NAMEPREP">
<front>
<title>Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)</title>
<author initials='P.' surname='Hoffman' fullname='P.  Hoffman'>
<organization /></author>
<author initials='M.' surname='Blanchet' fullname='M.  Blanchet'>
<organization /></author>
<date month='March' year='2003' /></front>
<seriesInfo name='RFC' value='3491' />
<format type='TXT' octets='10316' target='ftp://ftp.isi.edu/in-notes/rfc3491.txt' />
</reference>

<reference anchor="STRINGPREP">
<front>
<title>Preparation of Internationalized Strings ("stringprep")</title>
<author initials='P.' surname='Hoffman' fullname='P.  Hoffman'>
<organization /></author>
<author initials='M.' surname='Blanchet' fullname='M.  Blanchet'>
<organization /></author>
<date month='December' year='2002' /></front>
<seriesInfo name='RFC' value='3454' />
<format type='TXT' octets='138684' target='ftp://ftp.isi.edu/in-notes/rfc3454.txt' />
</reference>

<reference anchor='XMPP-CORE'>
<front>
<title abbrev='XMPP Core'>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='Peter Saint-Andre' role='editor'>
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email></address></author>
<date year='2004' month='October' />
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints.  While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.</t></abstract></front>
<seriesInfo name='RFC' value='3920' />
<format type='TXT' octets='194313' target='ftp://ftp.isi.edu/in-notes/rfc3920.txt' />
<format type='HTML' octets='237435' target='http://xml.resource.org/public/rfc/html/rfc3920.html' />
<format type='XML' octets='234474' target='http://xml.resource.org/public/rfc/xml/rfc3920.xml' />
</reference>

    </references>

    <references title="Informative References">

<reference anchor='BIDI'>
<front>
<title>Right-to-left scripts for IDNA</title>
<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
    <organization />
</author>
<author initials='C' surname='Karp' fullname='Cary Karp'>
    <organization />
</author>
<date month='January' day='14' year='2010' />
<abstract><t>The use of right-to-left scripts in internationalized domain names has presented several challenges.  This memo proposes a new BIDI rule for IDNA labels, based on the encountered problems with some scripts, and some shortcomings in the 2003 IDNA BIDI criterion.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-idnabis-bidi-07' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-idnabis-bidi-07.txt' />
</reference>

<reference anchor='DEFS'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J' surname='Klensin' fullname='John Klensin'>
    <organization />
</author>
<date month='January' day='7' year='2010' />
<abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-idnabis-defs-13' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-idnabis-defs-13.txt' />
</reference>

<reference anchor="IBR">
  <front>
    <title>In-Band Registration</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <date day="15" month="September" year="2009"/>
  </front>
  <seriesInfo name="XSF XEP" value="0077"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0077.html"/>
</reference>

<reference anchor="MIMIC">
  <front>
    <title>Best Practices to Discourage JID Mimicking</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <date day="13" month="December" year="2007"/>
  </front>
  <seriesInfo name="XSF XEP" value="0165"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0165.html"/>
</reference>

<reference anchor="MUC">
  <front>
    <title>Multi-User Chat</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <date day="21" month="January" year="in progress, last updated 2010"/>
  </front>
  <seriesInfo name="XSF XEP" value="0045"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0045.html"/>
</reference>

<reference anchor='RATIONALE'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale</title>
<author initials='J' surname='Klensin' fullname='John Klensin'>
    <organization />
</author>
<date month='January' day='11' year='2010' />
<abstract><t>Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode.  Some of these issues require tuning of the existing protocols and the tables on which they depend.  This document provides an overview of a revised system and provides explanatory material for its components.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-idnabis-rationale-17' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-idnabis-rationale-17.txt' />
</reference>

<reference anchor='REVIEW'>
<front>
<title>Review and Recommendations for Internationalized Domain Names (IDNs)</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<author>
<organization>IAB</organization></author>
<date year='2006' month='September' />
<abstract>
<t>This note describes issues raised by the deployment and use of Internationalized Domain Names.  It describes problems both at the time of registration and for use of those names in the DNS.  It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF.  In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed.  This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4690' />
<format type='TXT' octets='100929' target='ftp://ftp.isi.edu/in-notes/rfc4690.txt' />
</reference>

<reference anchor='XMPP-IM'>
<front>
<title abbrev='XMPP IM'>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='Peter Saint-Andre' role='editor'>
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email></address></author>
<date year='2004' month='October' />
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.</t></abstract></front>
<seriesInfo name='RFC' value='3921' />
<format type='TXT' octets='217527' target='ftp://ftp.isi.edu/in-notes/rfc3921.txt' />
<format type='HTML' octets='239708' target='http://xml.resource.org/public/rfc/html/rfc3921.html' />
<format type='XML' octets='234332' target='http://xml.resource.org/public/rfc/xml/rfc3921.xml' />
</reference>

<reference anchor='XMPP-URI'>
<front>
<title>Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2008' month='February' />
<abstract>
<t>This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5122' />
<format type='TXT' octets='55566' target='ftp://ftp.isi.edu/in-notes/rfc5122.txt' />
</reference>

<reference anchor='XMPPBIS'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
    <organization />
</author>
<date month='November' day='17' year='2009' />
<abstract><t>This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities.  XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built.  The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions.  This document also specifies the format for XMPP addresses, which are fully internationalizable.  This document obsoletes RFC 3920.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-3920bis-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-3920bis-04.txt' />
</reference>

    </references>

  </back>
</rfc>