rfc8266.xml

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

<rfc category="std" ipr="trust200902" number="8266" obsoletes="7700"
     submissionType="IETF" consensus="yes">

  <front>

    <title abbrev="PRECIS: Nicknames">Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames</title>

    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>Jabber.org</organization>
      <address>
        <postal>
          <street>P.O. Box 787</street>
          <city>Parker</city>
          <region>CO</region>
          <code>80134</code>
          <country>USA</country>
        </postal>
        <phone>+1 720 256 6756</phone>
        <email>stpeter@jabber.org</email>
        <uri>https://www.jabber.org/</uri>
      </address>
    </author>

    <date month="September" year="2017"/>

    <keyword>nickname</keyword>
    <keyword>SIP</keyword>
    <keyword>SIMPLE</keyword>
    <keyword>XMPP</keyword>
    <keyword>MSRP</keyword>
    <keyword>XCON</keyword>
    <keyword>chat rooms</keyword>

    <abstract>
      <t>This document describes methods for handling Unicode strings
      representing memorable, human-friendly names (called "nicknames",
      "display names", or "petnames") for people, devices, accounts, websites,
      and other entities.  This document obsoletes RFC 7700.</t>
    </abstract>

  </front>

  <middle>

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

    <section title="Overview" anchor="overview">
      <t>A number of technologies and applications provide the ability for a
      person to choose a memorable, human-friendly name in a communications
      context or to set such a name for another entity such as a device,
      account, contact, or website.  Such names are variously called
      "nicknames" (e.g., in chat room applications), "display names" (e.g., in
      Internet mail), or "petnames" (see <xref target='PETNAME-SYSTEMS'/>);
      for consistency, these are all called "nicknames" in this document.</t>
      <t>Nicknames are commonly supported in technologies for textual chat
      rooms, e.g., Internet Relay Chat <xref target='RFC2811'/> and
      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='RFC7701'/>, and Centralized
      Conferencing (XCON) <xref target='RFC5239'/> <xref
      target='XCON-SYSTEM'/>.  Recent chat room technologies also allow
      internationalized nicknames because they support code points from
      outside the ASCII range <xref target='RFC20'/>, typically by means of
      the Unicode coded 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 
      out of a chat room or avoiding nickname conflicts).</t>
      <t>A similar usage enables a person to set their own preferred display
      name or to set a preferred display name for another user (e.g., the
      "display-name" construct in the Internet message format <xref
      target='RFC5322'/> and the &lt;nick/&gt; element in XMPP <xref target='XEP-0172'/>).</t>
      <t>Memorable, human-friendly names are also used in contexts other than
      personal messaging, such as names for devices (e.g., in a network
      visualization application), websites (e.g., for bookmarks in a web
      browser), accounts (e.g., in a web interface for a list of payees in a
      bank account), people (e.g., in a contact list application), and the
      like.</t>
      <t>The rules specified in this document, can be applied in all of the 
      foregoing contexts.</t>
      <t>To increase the likelihood that memorable, human-friendly names will
      work in ways that make sense for typical users throughout the world,
      this document defines rules for handling nicknames in terms of the 
      preparation, enforcement, and comparison of internationalized 
      strings (PRECIS) framework specification <xref target='RFC8264'/>.</t>
    </section>

    <section title="Terminology" anchor="terms">
      <t>Many important terms used in this document are defined in <xref
      target='RFC8264'/>, <xref target='RFC6365'/>, and <xref
      target='Unicode'/>.</t>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
      "SHALL&nbsp;NOT", "SHOULD", "SHOULD&nbsp;NOT", "RECOMMENDED",
      "NOT&nbsp;RECOMMENDED", "MAY", and "OPTIONAL" in this document
      are to be interpreted as described in BCP&nbsp;14
      <xref format="default" pageno="false" target="RFC2119"/>
      <xref format="default" pageno="false" target="RFC8174"/> when,
      and only when, they appear in all capitals, as shown here.</t>
    </section>

  </section>

  <section title='Nickname Profile' anchor='rules'>

    <section title='Rules' anchor='rules-rules'>
      <t>The following rules apply within the Nickname profile of the
      PRECIS FreeformClass defined in the PRECIS framework specification
      <xref target='RFC8264'/>.</t>
      <t>
        <list style='numbers'>
          <t>Width Mapping Rule: There is no width mapping rule (such a rule
          is not necessary because width mapping is performed as part of
          normalization using Normalization Form KC (NFKC) as specified
          below).</t>
          <t>Additional Mapping Rule: The additional mapping rule consists of
          the following sub-rules.
            <list style="format %c.">
              <t>Map any instances of non-ASCII space to SPACE (U+0020);
              a non-ASCII space is any Unicode code point having a general
              category of "Zs", naturally with the exception of SPACE (U+0020).  (The
              inclusion of only ASCII space prevents confusion with various
              non-ASCII space code points, many of which are difficult to
              reproduce across different input methods.)</t>
              <t>Remove any instances of the ASCII space character at the
              beginning or end of a nickname (e.g., "stpeter&#160;" is mapped
              to "stpeter").</t>
              <t>Map interior sequences of more than one ASCII space character
              to a single ASCII space character (e.g., "St&#160;&#160;Peter"
              is mapped to "St&#160;Peter").</t>
            </list>
          </t>
          <t>Case Mapping Rule: Apply the Unicode toLowerCase() operation, as
          defined in the Unicode Standard <xref target='Unicode'/>.  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
          presented to a human user at the same time.  (As explained below,
          this is typically appropriate only for comparison, not for
          enforcement.)</t>
          <t>Normalization Rule: Apply Unicode Normalization Form KC.  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 code points that would match; for example,
          the character "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) would match the combination of
          "I" (LATIN CAPITAL LETTER I, U+0049) and "V" (LATIN CAPITAL LETTER V, U+0056).</t>
          <t>Directionality Rule: There is no directionality rule. The "Bidi
          Rule" (defined in <xref target='RFC5893'/>) and similar rules are
          unnecessary and inapplicable to nicknames, because it is perfectly
          acceptable for a given nickname to be presented differently in
          different layout systems (e.g., a user interface that is configured
          to handle primarily a right-to-left script versus an interface that
          is configured to handle primarily a left-to-right script), as long
          as the presentation is consistent in any given layout system.</t>
        </list>
      </t>
    </section>

    <section title='Preparation' anchor='rules-prep'>
      <t>An entity that prepares an input string for subsequent enforcement
      according to this profile MUST ensure that the string consists only of
      Unicode code points that conform to the FreeformClass string class
      defined in <xref target='RFC8264'/>.</t>
    </section>


    <section title='Enforcement' anchor='rules-enforce'>
<t>An entity that performs enforcement according to this profile MUST prepare
an input string as described in <xref target='rules-prep'/> and MUST also
apply the following rules specified in <xref target='rules-rules'/> in the
order shown:
<list style="numbers">
<?rfc subcompact="yes"?>
<t>Additional Mapping Rule</t>
<t>Normalization Rule</t>
</list></t>
<?rfc subcompact="no"?>
<t>Note: An entity SHOULD apply the Case Mapping Rule only during
comparison.</t>
<t>After all of the foregoing rules have been enforced, the entity MUST
  ensure that the nickname is not zero bytes in length (this is done
  after enforcing the rules to prevent applications from mistakenly
  omitting a nickname entirely, because when internationalized
  strings are accepted a non-empty sequence of characters can
  result in a zero-length nickname after canonicalization).</t>
<t>The result of the foregoing operations is an output string that conforms 
to the Nickname profile.  Until an implementation produces such an output
string, it MUST NOT treat the string as conforming (in particular, it MUST NOT
assume that an input string is conforming before the enforcement operation 
has been completed).</t>
</section>

    <section title="Comparison" anchor="rules-comp">
<t>  An entity that performs comparison of two strings according to this
  profile MUST prepare each input string as specified in <xref
  target='rules-prep'/> and MUST apply the following rules specified in <xref
  target='rules-rules'/> in the order shown:
<?rfc subcompact="yes"?>
<list style="numbers">
<t>Additional Mapping Rule</t>
<t>Case Mapping Rule</t>
<t>Normalization Rule</t>
</list>

</t>
<?rfc subcompact="no"?>
<t>The two strings are to be considered equivalent if and only if they are an
exact octet-for-octet match (sometimes called "bit-string identity").
</t>
<t>Until an implementation determines whether two strings are to be considered
equivalent, it MUST NOT treat them as equivalent (in particular, it MUST NOT
assume that two input strings are equivalent before the comparison
operation has been completed).</t>
    </section>

  </section>

  <section title="Examples" anchor="examples">
    <t>The following examples illustrate a small number of nicknames that are
    consistent with the format defined above, along with the output string
    resulting from application of the PRECIS rules for comparison purposes (note that the characters
    "&lt;" and "&gt;" are used to delineate the actual nickname and are not
    part of the nickname strings).</t>
    <figure align="center">
      <artwork align="center"><![CDATA[
+---------------------------+-------------------------------------+
| #  | Nickname              | Output for Comparison              |
+---------------------------+-------------------------------------+
| 1  | <Foo>                 | <foo>                              |
+---------------------------+-------------------------------------+
| 2  | <foo>                 | <foo>                              |
+---------------------------+-------------------------------------+
| 3  | <Foo Bar>             | <foo bar>                          |
+---------------------------+-------------------------------------+
| 4  | <foo bar>             | <foo bar>                          |
+---------------------------+-------------------------------------+
| 5  | <Σ>                   | σ (GREEK SMALL LETTER SIGMA,       |
|    |                       | U+03C3)                            |
+---------------------------+-------------------------------------+
| 6  | <σ>                   | σ (GREEK SMALL LETTER SIGMA,       |
|    |                       | U+03C3)                            |
+---------------------------+-------------------------------------+
| 7  | <ς>                   | ς (GREEK SMALL LETTER FINAL SIGMA, | 
|    |                       | U+03C2)                            |
+---------------------------+-------------------------------------+
| 8  | <ϔ>                   | υ (GREEK SMALL LETTER UPSILON,     | 
|    |                       | U+03C5) and ¨ (COMBINING DIARESIS, |
|    |                       | U+0308)                            |
+---------------------------+-------------------------------------+
| 9  | <♚>                   | ♚ (BLACK CHESS KING, U+265A)       |
+---------------------------+-------------------------------------+
| 10 | <Richard Ⅳ>           | <richard iv>                       |
+---------------------------+-------------------------------------+
      ]]></artwork>
      <postamble>Table 1: A Sample of Legal Nicknames</postamble>
    </figure>

  <t>Regarding examples 5, 6, and 7: applying the Unicode toLowerCase() operation
  to the character "Σ" (GREEK CAPITAL LETTER SIGMA, U+03A3) results in the character
  "σ" (GREEK SMALL LETTER SIGMA, U+03C3); however, the toLowerCase() operation does 
  not modify the character "ς" (GREEK SMALL LETTER FINAL SIGMA, U+03C2).  Therefore, 
  the comparison operation defined in <xref target="rules-comp"/> would result in 
  matching of the nicknames in examples 5 and 6 but not the nicknames in examples 
  5 and 7 or 6 and 7.</t>
  
  <t>Regarding example 8: this is an instance where applying the
  rules for the Nickname profile is not an idempotent procedure (see 
  <xref target='use'/>). In particular:</t>
  
  <t>
    <list style='numbers'>
      <t>Applying toLowerCase() to the character "ϔ" (GREEK UPSILON WITH DIARESIS AND 
      HOOK SYMBOL, U+03D4) results in no changes, and applying NFKC to
      that character results in the character "Ϋ" (GREEK UPSILON WITH HOOK 
      SYMBOL, U+03D2).</t>
      <t>Applying toLowerCase() to "Ϋ" (GREEK UPSILON WITH HOOK SYMBOL, U+03D2)
      results in the character "ϋ" (GREEK SMALL LETTER UPSILON WITH DIALYTIKA,
      U+03CB), and applying NFKC to that character results in no changes.</t>
    </list>
  </t>
  
  <t>Regarding example 9: symbol characters such as "♚" (BLACK CHESS 
  KING, U+265A) are allowed by the PRECIS FreeformClass and thus can be
  used in nicknames.</t>
  
  <t>Regarding example 10: applying the Unicode 
  toLowerCase() operation to the character "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) 
  results in the character "ⅳ" (SMALL ROMAN NUMERAL FOUR, U+2173), and applying 
  NFKC to the character "ⅳ" (SMALL ROMAN NUMERAL FOUR, U+2173) results in the 
  characters "i" (LATIN SMALL LETTER I, U+0069) and "v" (LATIN SMALL
  LETTER V, U+0076).</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) or application definition to specify the
    protocol slots in which nickname strings can appear, the entities that are
    expected to enforce the rules governing nickname strings, and the point during
    protocol processing or interface handling when the rules need to be enforced.
    See Section 6 of <xref target='RFC8264'/> for guidelines about using
    PRECIS profiles in applications.</t>
    <t>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 code points or character ranges,
    safeguards to mitigate the effects of visually similar characters,
    etc.).</t>
    <t>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 IDs, etc.).</t>
    <t>Entities that enforce the rules specified in this document are
    encouraged to be liberal in what they accept by following this
    procedure:</t>
    <t>
      <list style='numbers'>
        <t>Where possible, map characters (e.g., through width mapping,
        additional mapping, case mapping, or normalization) and accept the
        mapped string.</t>
        <t>If mapping is not possible (e.g., because a character is disallowed
        in the FreeformClass), reject the string.</t>
      </list>
    </t>
    <t>Implementation experience has shown that applying the rules for the
    Nickname profile is not an idempotent procedure for all code
    points. Therefore, an implementation SHOULD apply the rules repeatedly
    until the output string is stable; if the output string does not stabilize
    after reapplying the rules three (3) additional times after the first application, the implementation
    SHOULD terminate application of the rules and reject the input string as
    invalid.</t>

  </section>

  <section title="IANA Considerations" anchor="iana">

    <t>IANA has added the following entry to the "PRECIS Profiles"
    registry:</t>
    <t>
      <list style='hanging'>
        <t hangText='Name:'>Nickname</t>
        <t hangText='Base Class:'>FreeformClass</t>
        <t hangText='Applicability:'>Nicknames or display names in messaging and text
        conferencing technologies; petnames for devices, accounts, and people;
        and other uses of nicknames, dsiplay names, or petnames.</t>
        <t hangText='Replaces:'>None</t>
        <t hangText='Width Mapping Rule:'>None (handled via NFKC)</t>
        <t hangText='Additional Mapping Rule:'>Map non-ASCII space characters
        to SPACE (U+0020), strip leading and trailing space characters, and map
        interior sequences of multiple space characters to a since instance of
        SPACE (U+0020).</t>
        <t hangText='Case Mapping Rule:'>Map uppercase and titlecase code
        points to lowercase using the Unicode toLowerCase() operation.</t>
        <t hangText='Normalization Rule:'>NFKC</t>
        <t hangText='Directionality Rule:'>None</t>
        <t hangText='Enforcement:'>To be specified by applications.</t>
        <t hangText='Specification:'>RFC 8266</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="RFC8264"/> apply to the FreeformClass 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='UTS39'/> apply
      to the use of Unicode code points in nicknames.</t>
    </section>
    <section title="Visually Similar Characters" anchor="security-similar">
      <t><xref target='RFC8264'/> describes some of the
      security considerations related to visually similar characters, also
      called "confusable characters" or "confusables", and provides some
      examples of such characters.</t>
      <t>Although the mapping rules defined in <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='UTS39'/>.</t>
    </section>
  </section>

  </middle>

  <back>

    <references title="Normative References">

<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.5893.xml"?>
<?rfc include="reference.RFC.6365.xml"?>
<?rfc include="reference.RFC.8174.xml"?>

<!-- draft-ietf-precis-7564bis (RFC 8264) -->
<reference anchor="RFC8264" target="https://www.rfc-editor.org/info/rfc8264">
<front>
<title>PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
    <organization />
</author>
<author initials='M' surname='Blanchet' fullname='Marc Blanchet'>
    <organization />
</author>
<date month='September' year='2017' />
</front>
<seriesInfo name="RFC" value="8264"/>
<seriesInfo name="DOI" value="10.17487/RFC8264"/>
</reference>

<reference anchor="Unicode" target="http://www.unicode.org/versions/latest/">
  <front>
    <title>The Unicode Standard</title>
    <author>
      <organization>The Unicode Consortium</organization>
    </author>
    <date />
  </front>
</reference>

<reference anchor="UTS39" target='http://unicode.org/reports/tr39/'>
  <front>
    <title>Unicode Security Mechanisms</title>
    <author>
      <organization>Unicode Technical Standard #39</organization>
    </author>
  <date/>
  </front>
 <seriesInfo name='edited by Mark Davis' value='and Michel Suignard'/>
</reference>

    </references>

    <references title="Informative References">

<reference  anchor='RFC20' target='https://www.rfc-editor.org/info/rfc20'>
<front>
<title>ASCII format for network interchange</title>
<author initials='V.G.' surname='Cerf' fullname='V.G. Cerf'><organization /></author>
<date year='1969' month='October' />
</front>
<seriesInfo name='STD' value='80'/>
<seriesInfo name='RFC' value='20'/>
<seriesInfo name='DOI' value='10.17487/RFC0020'/>
</reference>

<?rfc include="reference.RFC.2811.xml"?>
<?rfc include="reference.RFC.4975.xml"?>
<?rfc include="reference.RFC.5239.xml"?>
<?rfc include="reference.RFC.5322.xml"?>
<?rfc include="reference.RFC.6120.xml"?>
<?rfc include="reference.RFC.7700.xml"?>
<?rfc include="reference.RFC.7701.xml"?>

<!-- draft-boulton-xcon-session-chat (Expired) -->
<reference anchor='XCON-SYSTEM'>
<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' year='2012' />
</front>
<seriesInfo name='Work in Progress,' value='draft-boulton-xcon-session-chat-08' />
</reference>

<reference anchor="XEP-0045" target="https://xmpp.org/extensions/xep-0045.html">
  <front>
    <title>Multi-User Chat</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
    </author>
    <date month="May" year="2017"/>
  </front>
  <seriesInfo name="XSF XEP" value="0045"/>
</reference>

<reference anchor="XEP-0172" target="https://xmpp.org/extensions/xep-0172.html">
  <front>
    <title>User Nickname</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
    </author>
    <author initials="V." surname="Mercier" fullname="Valerie Mercier">
      <organization/>
    </author>
    <date day="21" month="March" year="2012"/>
  </front>
  <seriesInfo name="XSF XEP" value="0172"/>
</reference>

<reference anchor="PETNAME-SYSTEMS" target="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">
  <front>
    <title>An Introduction to Petname Systems</title>
    <author initials="M." surname="Stiegler" fullname="Marc Stiegler">
      <organization/>
      <address>
        <email></email>
      </address>
    </author>
    <date month="February" year="2005"/>
  </front>
  <seriesInfo name="updated June" value="2010"/>
</reference>

<reference anchor="Err4570" quote-title="false" target="https://www.rfc-editor.org/errata/eid4570">
     <front>
       <title>Erratum ID 4570</title>
       <author>
         <organization>RFC Errata</organization>
       </author>
       <date month="" year="" />
     </front>
     <seriesInfo name="RFC" value="7700" />
   </reference>

  </references>

  <section title="Changes from RFC 7700" anchor="changes">
    <t>The following changes were made from <xref target='RFC7700'/>.</t>
    <t>
      <list style='symbols'>
        <t>Addressed <xref target="Err4570"/> by removing the directionality
        rule from Section 2.3 and Section 2.4.</t>
        <t>In accordance with working group discussions and updates to <xref
        target='RFC8264'/>, removed the use of the Unicode toCaseFold()
        operation in favor of the Unicode toLowerCase() operation.</t>
        <t>Clarified several editorial matters.</t>
        <t>Updated references.</t>
      </list>
    </t>
  </section>

  <section title="Acknowledgements" anchor="acks" numbered="no">
    <t>Thanks to William Fisher for his implementation feedback, especially
    regarding idempotence.</t>
    <t>Thanks to Sam Whited for his feedback and for submitting <xref
    target="Err4570"/>.</t>
    <t>See <xref target='RFC7700'/> for acknowledgements related to the
    specification that this document supersedes.</t>
  </section>

  </back>

</rfc>