One document matched: draft-ietf-precis-nickname-05.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-05" 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="November" day="6"/>

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

    <abstract>
      <t>This document describes how to prepare and compare Unicode strings representing nicknames, primarily for use within textual chatrooms.  This profile is intended to be used by messaging and text conferencing technologies such as the Extensible Messaging and Presence Protocol (XMPP), the Message Session Relay Protocol (MSRP), and Centralized Conferencing (XCON).</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'/> as well as multi-party chat technologies based on the Extensible Messaging and Presence Protocol (XMPP) <xref target='RFC6120'/> <xref target='XEP-0045'/>, the Message Session Relay Protocol (MSRP) <xref target='RFC4975'/> <xref target='I-D.ietf-simple-chat'/>, and Centralized Conferencing (XCON) <xref target='RFC5239'/> <xref target='I-D.boulton-xcon-session-chat'/>.  Recent chatroom technologies also allow internationalized nicknames because they support characters from outside the ASCII range <xref target='RFC20'/>, typically by means of the Unicode character set <xref target='UNICODE'/>.  Although such nicknames tend to be used primarily for display purposes, they are sometimes used for programmatic purposes as well (e.g., kicking users or avoiding nickname conflicts).  Note too that nicknames can be used not only in chatrooms but also more generally as a user's preferred display name (see for instance <xref target='XEP-0172'/>).</t>
      <t>To increase the likelihood that nicknames 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'/>.</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 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 (most commonly, when a chatroom client generates a nickname from user input for inclusion as a protocol element that represents a "nickname slot"), an application MUST at a minimum ensure that the string conforms to the "FreeClass" base string class defined in <xref target='I-D.ietf-precis-framework'/>; however, it MAY in addition perform the normalization and mapping operations specified below for comparison purposes.</t>
    <t>For comparison purposes (e.g., when a chatroom server determines if two nicknames are in conflict during the authorization process), an application MUST treat a nickname as follows, where the operations specified MUST be completed in the order shown (in particular, normalization MUST be performed before all other mapping steps and validity checks, consistent with <xref target='I-D.ietf-precis-framework'/>):</t>
    <t>
      <list style='numbers'>
        <t>The string MUST be normalized using Unicode Normalization Form KC (NFKC).  Because NFKC is more "aggressive" in finding matches than other normalization forms (in the terminology 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., U+2163 ROMAN NUMERAL FOUR would match the combination of U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V).<vspace blankLines='1'/></t>
        <t>Uppercase and titlecase characters MUST be mapped to their lowercase equivalents.  In applications that prohibit conflicting 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 chatroom at the same time.<vspace blankLines='1'/></t>
        <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 U+0020 SPACE.<vspace blankLines='1'/></t>
        <t>Leading and trailing whitespace (i.e., one or more instances of the ASCII space character at the beginning or end of a nickname) MUST be removed (e.g., "stpeter " is mapped to "stpeter").<vspace blankLines='1'/></t>
        <t>Interior sequences of more than one ASCII space character MUST be mapped to a single ASCII space character (e.g., "St  Peter" is mapped to "St Peter").<vspace blankLines='1'/></t>
        <t>Other mappings MAY be applied, such as those defined in <xref target='I-D.yoneya-precis-mappings'/>.  (Note that mapping of fullwidth and halfwidth characters to their decomposition equivalents is not necessary, since those mappings are performed as part of normalization using NFKC.)</t>
      </list>
    </t>
    <t>For both preparation and comparison, the "Bidi Rule" defined in <xref target='RFC5893'/> applies to the directionality of a nickname.</t>
  </section>

  <section title="Use in Application Protocols" anchor="use">
    <t>This specification defines only the PRECIS-based rules for handling of nickname strings.  It is the responsibility of an application protocol (e.g., MSRP, XCON, or XMPP) to specify the protocol slots in which nickname strings can appear, as well as the entities that are expected to enforce the rules governing nickname strings in that protocol (e.g., chat servers, chat clients, or both).  Above and beyond the PRECIS-based rules specified here, application protocols can also define application-specific rules governing nickname strings (rules regarding the minimum or maximum length of nicknames, further restrictions on allowable characters or character ranges, safeguards to mitigate the effects of visually similar characters, etc.).  Naturally, application protocols can also specify rules governing the actual use of nicknames in applications (reserved nicknames, authorization requirements for using nicknames, whether certain nicknames can be prohibited, handling of duplicates, the relationship between nicknames and underlying identifiers such as SIP URIs or Jabber Identifiers, etc.).</t>
  </section>

  <section title="IANA Considerations" anchor="iana">
    <t>The IANA shall add the following entry to the PRECIS Usage Registry:</t>
    <t>
      <list style='hanging'>
        <t hangText='Applicability:'>Nicknames in messaging and text conferencing technologies such as XMPP, MSRP, and XCON.</t>
        <t hangText='Base Class:'>FreeClass.</t>
        <t hangText='Subclass:'>No.</t>
        <t hangText='Normalization:'>NFKC.</t>
        <t hangText='Case Mapping:'>Map uppercase and titlecase characters to lowercase.</t>
        <t hangText='Width Mapping:'>None (handled via NFKC).</t>
        <t hangText='Additional Mappings:'>Map non-ASCII space characters to ASCII space, strip leading and trailing space characters, map interior sequences of multiple space characters to a single ASCII space.</t>
        <t hangText='Directionality:'>The "Bidi Rule" defined in RFC 5893 applies.</t>
        <t hangText='Specification:'>RFC &rfc.number;.  [Note to RFC Editor: please change XXXX to the number issued for this specification.]</t>
      </list>
    </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.</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 defined under <xref target='rules'/> of this document 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 provided in <xref target='UTR39'/>.</t>
    </section>
  </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='September' day='23' 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-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-06.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="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>

    </references>

    <references title="Informative References">

<reference anchor='I-D.boulton-xcon-session-chat'>
<front>
<title>Chatrooms within a Centralized Conferencing (XCON) System</title>
<author initials='M' surname='Barnes' fullname='Mary Barnes'>
    <organization />
</author>
<author initials='C' surname='Boulton' fullname='Chris Boulton'>
    <organization />
</author>
<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
    <organization />
</author>
<date month='July' day='16' year='2011' />
<abstract><t>The document "A Framework for Centralized Conferencing" defines a centralized conference as both signaling and protocol agnostic.  The primary examples within this framework focus on audio and video as the media types for the session.  This document provides an overview of the mechanisms defined in the centralized conferencing framework that can be used to support multi-user chat.  In addition, the document describes additional functionality and requirements necessary to provide feature rich functionality.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-boulton-xcon-session-chat-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-boulton-xcon-session-chat-08.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='August' day='16' 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-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-16.txt' />
</reference>

<reference anchor='I-D.yoneya-precis-mappings'>
<front>
<title>Mapping characters for PRECIS classes</title>
<author initials='Y' surname='YONEYA' fullname='Yoshiro YONEYA'>
    <organization />
</author>
<author initials='T' surname='NEMOTO' fullname='Takahiro NEMOTO'>
    <organization />
</author>
<date month='October' day='3' year='2012' />
<abstract><t>Preparation and comparison of internationalized strings ("PRECIS") Framework [I-D.ietf-precis-framework] is defining several classes of strings for preparation and comparison.  In the document, case mapping is defined because many of protocols handle case sensitive or case insensitive string comparison and therefore preparation of string is mandatory.  As described in IDNA mapping [RFC5895] and PRECIS problem statement [I-D.ietf-precis-problem-statement], mappings in internationalized strings are not limited to case, but also width, delimiters and/or other specials are taken into consideration.  This document considers mappings other than case mapping in PRECIS context.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-yoneya-precis-mappings-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-yoneya-precis-mappings-03.txt' />
</reference>

<reference anchor='RFC20'>
<front>
<title>ASCII format for network interchange</title>
<author initials='V.' surname='Cerf' fullname='Vint Cerf'>
<organization>University California Los Angeles (UCLA)</organization></author>
<date year='1969' day='16' month='October' />
<abstract>
<t>For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0.</t></abstract></front>
<seriesInfo name='RFC' value='20' />
<format type='TXT' octets='18504' target='http://www.rfc-editor.org/rfc/rfc20.txt' />
</reference>

<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='RFC5239'>
<front>
<title>A Framework for Centralized Conferencing</title>
<author initials='M.' surname='Barnes' fullname='M. Barnes'>
<organization /></author>
<author initials='C.' surname='Boulton' fullname='C. Boulton'>
<organization /></author>
<author initials='O.' surname='Levin' fullname='O. Levin'>
<organization /></author>
<date year='2008' month='June' />
<abstract>
<t>This document defines the framework for Centralized Conferencing.  The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference.  The Centralized Conferencing Framework defines logical entities and naming conventions.  The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications.  The framework binds all the defined components together for the benefit of builders of conferencing systems. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5239' />
<format type='TXT' octets='146927' target='http://www.rfc-editor.org/rfc/rfc5239.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>

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

<reference anchor="XEP-0172">
  <front>
    <title>User Nickname</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <author initials="V." surname="Mercier" fullname="Valerie Mercier">
      <organization/>
      <address>
        <email>valerie.mercier@orange-ftgroup.com</email>
      </address>
    </author>
    <date day="21" month="March" year="2012"/>
  </front>
  <seriesInfo name="XSF XEP" value="0172"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0172.html"/>
</reference>

    </references>

  <section title="Acknowledgements" anchor="acks">
    <t>Thanks to Kim Alvefur, Mary Barnes, Dave Cridland, Miguel Garcia, Salvatore Loreto, and Enrico Marocco for their reviews and comments.</t>
  </section>

  </back>

</rfc>