One document matched: draft-ietf-precis-nickname-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>

<rfc category="std" docName="draft-ietf-precis-nickname-00" ipr="trust200902">

  <front>

    <title abbrev="PRECIS Nickname">Preparation and Comparison of Nicknames</title>

    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>1899 Wynkoop Street, Suite 600</street>
          <city>Denver</city>
          <region>CO</region>
          <code>80202</code>
          <country>USA</country>
        </postal>
        <phone>+1-303-308-3282</phone>
        <email>psaintan@cisco.com</email>
      </address>
    </author>

    <date year="2012" month="August" day="1"/>

    <area>Applications</area>
    <workgroup>PRECIS</workgroup>
    <keyword>nickname</keyword>
    <keyword>SIP</keyword>
    <keyword>SIMPLE</keyword>
    <keyword>MSRP</keyword>
    <keyword>XMPP</keyword>
    <keyword>chatrooms</keyword>

    <abstract>
      <t>This document describes how to prepare and compare Unicode strings representing nicknames, primarily as used within textual chatrooms.  This profile is intended to be used by chatroom technologies based on both the Message Session Relay Protocol (MSRP) and the Extensible Messaging and Presence Protocol (XMPP).</t>
    </abstract>

  </front>

  <middle>

  <section title="Introduction" anchor="intro">

    <section title="Overview" anchor="overview">
      <t>Technologies for textual chatrooms customarily enable participants to specify a nickname for use in the room; e.g., this is true of Internet Relay Chat <xref target='RFC2811'/>, Multi-User Chat (MUC) based on the Extensible Messaging and Presence Protocol (XMPP) <xref target='XEP-0045'/>, and multi-party chat based on the Message Session Relay Protocol (MSRP) <xref target='I-D.ietf-simple-chat'/>.  Recent chatroom technologies also allow internationalized nicknames because they support characters from outside the ASCII range, typically by means of the Unicode character set <xref target='UNICODE'/>.  Although such nicknames are often used primarily for display purposes, they are sometimes used for programmatic purposes as well (e.g., kicking users or avoiding nickname conflicts).</t>
      <t>To increase the likelihood that nickname input and comparison will work in ways that make sense for typical users throughout the world, this document defines rules for preparing and comparing internationalized nicknames.</t>
    </section>

    <section title="Terminology" anchor="terms">
      <t>Many important terms used in this document are defined in <xref target='I-D.ietf-precis-framework'/>, <xref target='RFC6365'/>, and <xref target='UNICODE'/>.  Relevant XMPP terms are defined in <xref target='RFC6120'/> and <xref target='XEP-0045'/>, and relevant MSRP terms in <xref target='RFC4975'/> and <xref target='I-D.ietf-simple-chat'/>.</t>
      <t>The key words "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 <xref target='RFC2119'/>.</t>
    </section>

  </section>

  <section title='Rules' anchor='rules'>
    <t>A nickname MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length (the latter restriction is derived from the length restriction on XMPP resourceparts, see <xref target='RFC6122'/>).  This rule is to be enforced after any mapping or normalization of code points.</t>
    <t>A nickname MUST consist only of Unicode code points that conform to the "FreeClass" base string class defined in <xref target='I-D.ietf-precis-framework'/>.</t>
    <t>For preparation purposes (e.g., when a chatroom client generates a nickname from user input for inclusion as a nickname protocol element), an application MUST ensure that the string conforms to the "FreeClass" base string class defined in <xref target='I-D.ietf-precis-framework'/>; however, it MAY also perform the mapping and normalization operations specified below for comparison.</t>
    <t>For comparison purposes (e.g., when a chatroom server determines if two nicknames match during the authorization process), an application MUST treat a nickname as follows, where the operations specified MUST be completed in the order shown:</t>
    <t>
      <list style='numbers'>
        <t>Non-ASCII space characters from the "N" category defined under Section 6.14 of <xref target='I-D.ietf-precis-framework'/> MUST be mapped to SPACE [U+0020].<vspace blankLines='1'/></t>
        <t>Uppercase and titlecase characters MUST be mapped to their lowercase equivalents.  In applications that prohibit matching nicknames, this rule helps to reduce the possibility of confusion by ensuring that nicknames differing only by case (e.g., "stpeter" vs. "StPeter") would not be allowed in a room at the same time.<vspace blankLines='1'/></t>
        <t>All characters MUST be mapped using Unicode Normalization Form KC (NFKC).  Because NFKC is more "aggressive" in finding matches than other normalization forms (in the language of Unicode, it performs both canonical and compatibility decomposition before recomposing code points), this rule helps to reduce the possibility of confusion by increasing the number of characters that would match (e.g., ROMAN NUMERAL FOUR [U+2163] would match the combination of LATIN CAPITAL LETTER I [U+0049] and LATIN CAPITAL LETTER V [U+0056]).  Note well that normalization MUST be performed before all other mapping steps and validity checks, consistent with <xref target='I-D.ietf-precis-framework'/>.</t>
      </list>
    </t>
    <t>For both preparation and comparison, the "Bidi Rule" provided in <xref target='RFC5893'/> applies to the directionality of a nickname.</t>
  </section>

  <section title="Security Considerations" anchor="security">
    <section title="Reuse of PRECIS" anchor="security-precis">
      <t>The security considerations described in <xref target="I-D.ietf-precis-framework"/> apply to the "FreeClass" base string class used in this document for nicknames, respectively.</t>
    </section>
    <section title="Reuse of Unicode" anchor="security-unicode">
      <t>The security considerations described in <xref target='UTR39'/> apply to the use of Unicode characters in nicknames.</t>
    </section>
    <section title="Visually Similar Characters" anchor="security-similar">
      <t><xref target='I-D.ietf-precis-framework'/> describes some of the security considerations related to visually similar characters, also called "confusable characters" or "confusables".</t>
      <t>Although the mapping rules under <xref target='rules'/> are designed in part to reduce the possibility of confusion about nicknames, this document does not provide more detailed recommendations regarding the handling of visually similar characters, such as those in <xref target='UTR39'/>.</t>
    </section>
  </section>

  <section title="IANA Considerations" anchor="iana">
    <t>The IANA shall add an entry to the PRECIS Usage Registry for reuse of the PRECIS FreeClass in the preparation and comparison of nicknames.</t>
    <t>
      <list style='hanging'>
        <t hangText='Application Protocol:'>MSRP and XMPP.</t>
        <t hangText='Base Class:'>FreeClass.</t>
        <t hangText='Subclassing:'>No.</t>
        <t hangText='Directionality:'>The "Bidi Rule" defined in RFC 5893 applies.</t>
        <t hangText='Casemapping:'>Map uppercase and titlecase characters to lowercase.</t>
        <t hangText='Normalization:'>NFKC.</t>
        <t hangText='Specification:'>RFC &rfc.number;.</t>
      </list>
    </t>
  </section>

  </middle>

  <back>

    <references title="Normative References">

<reference anchor='I-D.ietf-precis-framework'>
<front>
<title>Precis Framework: Handling Internationalized Strings in Protocols</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
    <organization>Cisco</organization>
</author>
<author initials='M' surname='Blanchet' fullname='Marc Blanchet'>
    <organization>Viagenie</organization>
</author>
<date month='August' day='1' year='2012' />
<abstract><t>Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization).  This document defines a framework enabling application protocols to handle various classes of strings in a way that depends on the properties of Unicode code points and that is agile with respect to versions of Unicode; as a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454).  A specification that reuses this framework can either directly use the base string classes or subclass the base string classes as needed.  This framework takes an approach similar to the revised internationalized domain names in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in RFC 4690, albeit for application technologies other than the Domain Name System (DNS).  This document obsoletes RFC 3454.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-precis-framework-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-05.txt' />
</reference>

<reference anchor='I-D.ietf-simple-chat'>
<front>
<title>Multi-party Chat Using the Message Session Relay Protocol (MSRP)</title>
<author initials='A' surname='Niemi' fullname='Aki Niemi'>
    <organization />
</author>
<author initials='M' surname='Garcia' fullname='Miguel Garcia'>
    <organization />
</author>
<author initials='G' surname='Sandbakken' fullname='Geir Sandbakken'>
    <organization />
</author>
<date month='July' day='13' year='2012' />
<abstract><t>The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP).  This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-simple-chat-15' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-15.txt' />
</reference>

<reference anchor="RFC2119">
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass.  Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date month='March' year='1997' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>

<reference anchor='RFC5893'>
<front>
<title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization />
</author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization />
</author>
<date year='2010' month='August' />
<abstract>
<t>The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges.  This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5893' />
<format type='TXT' octets='38870' target='http://www.rfc-editor.org/rfc/rfc5893.txt' />
</reference>

<reference anchor='RFC6122'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Address Format</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters.  This document updates RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6122' />
<format type='TXT' octets='50646' target='http://www.rfc-editor.org/rfc/rfc6122.txt' />
</reference>

<reference anchor="UNICODE" target="http://www.unicode.org/versions/Unicode6.1.0/">
  <front>
    <title>The Unicode Standard, Version 6.1</title>
    <author>
      <organization>The Unicode Consortium</organization>
    </author>
    <date year="2012" />
  </front>
</reference>

<reference anchor="UTR39" target='http://unicode.org/reports/tr39/'>
  <front>
    <title>Unicode Technical Report #39: Unicode Security Mechanisms</title>
    <author>
      <organization>The Unicode Consortium</organization>
    </author>
    <date month="August" year="2010" />
  </front>
</reference>

<reference anchor="XEP-0045">
  <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="08" month="February" year="2012"/>
  </front>
  <seriesInfo name="XSF XEP" value="0045"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0045.html"/>
</reference>

    </references>

    <references title="Informative References">

<reference anchor='RFC2811'>
<front>
<title>Internet Relay Chat: Channel Management</title>
<author initials='C.' surname='Kalt' fullname='C. Kalt'>
<organization /></author>
<date year='2000' month='April' />
<abstract>
<t>This document specifies how channels, their characteristics and properties are managed by IRC servers.  This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='2811' />
<format type='TXT' octets='40788' target='http://www.rfc-editor.org/rfc/rfc2811.txt' />
</reference>

<reference anchor='RFC4975'>
<front>
<title>The Message Session Relay Protocol (MSRP)</title>
<author initials='B.' surname='Campbell' fullname='B. Campbell'>
<organization /></author>
<author initials='R.' surname='Mahy' fullname='R. Mahy'>
<organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'>
<organization /></author>
<date year='2007' month='September' />
<abstract>
<t>This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session.  Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4975' />
<format type='TXT' octets='144254' target='http://www.rfc-editor.org/rfc/rfc4975.txt' />
</reference>

<reference anchor='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.  This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>

<reference anchor='RFC6365'>
<front>
<title>Terminology Used in Internationalization in the IETF</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2011' month='September' />
<abstract>
<t>This document provides a list of terms used in the IETF when discussing internationalization.  The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.  This memo documents an Internet Best Current Practice.</t></abstract></front>
<seriesInfo name='BCP' value='166' />
<seriesInfo name='RFC' value='6365' />
<format type='TXT' octets='103155' target='http://www.rfc-editor.org/rfc/rfc6365.txt' />
</reference>

    </references>

  </back>

</rfc>