summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8266.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8266.txt')
-rw-r--r--doc/rfc/rfc8266.txt730
1 files changed, 730 insertions, 0 deletions
diff --git a/doc/rfc/rfc8266.txt b/doc/rfc/rfc8266.txt
new file mode 100644
index 0000000..6aac02b
--- /dev/null
+++ b/doc/rfc/rfc8266.txt
@@ -0,0 +1,730 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Saint-Andre
+Request for Comments: 8266 Jabber.org
+Obsoletes: 7700 October 2017
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Preparation, Enforcement, and Comparison of Internationalized Strings
+ Representing Nicknames
+
+Abstract
+
+ 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8266.
+
+Copyright Notice
+
+ Copyright (c) 2017 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
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ 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 Simplified BSD License.
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 1]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Nickname Profile . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3. Enforcement . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Use in Application Protocols . . . . . . . . . . . . . . . . 8
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 6.1. Authentication and Authorization . . . . . . . . . . . . 9
+ 6.2. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 10
+ 6.3. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 10
+ 6.4. Visually Similar Characters . . . . . . . . . . . . . . . 10
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 11
+ Appendix A. Changes from RFC 7700 . . . . . . . . . . . . . . . 12
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+1. Introduction
+
+1.1. Overview
+
+ 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 [PETNAME-SYSTEMS]); for
+ consistency, these are all called "nicknames" in this document.
+
+ Nicknames are commonly supported in technologies for textual chat
+ rooms, such as:
+
+ o Internet Relay Chat (IRC) [RFC2811]
+
+ o The Message Session Relay Protocol (MSRP) [RFC4975] [RFC7701]
+
+ o Centralized Conferencing (XCON) [RFC5239] [XCON-SYSTEM]
+
+ o The Extensible Messaging and Presence Protocol (XMPP) [RFC6120]
+ [XEP-0045]
+
+
+
+Saint-Andre Standards Track [Page 2]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ Recent chat room technologies also allow internationalized nicknames
+ because they support code points from outside the ASCII range
+ [RFC20], typically by means of the Unicode coded character set
+ [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).
+
+ 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 [RFC5322] and
+ the <nick/> element in XMPP [XEP-0172]).
+
+ 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.
+
+ The rules specified in this document can be applied in all of the
+ foregoing contexts.
+
+ It is important to understand that a nickname is a personally
+ memorable name or handle for something that has a more stable,
+ underlying identity, such as a URI or a file path. To ensure secure
+ operation of applications that use nicknames, authentication and
+ authorization decisions MUST be made on the basis of the thing's
+ identity, not its nickname.
+
+ 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 [RFC8264].
+
+1.2. Terminology
+
+ Many important terms used in this document are defined in [RFC8264],
+ [RFC6365], and [Unicode].
+
+ 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
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+
+
+
+
+Saint-Andre Standards Track [Page 3]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+2. Nickname Profile
+
+2.1. Rules
+
+ The following rules apply within the Nickname profile of the PRECIS
+ FreeformClass defined in the PRECIS framework specification
+ [RFC8264].
+
+ 1. 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).
+
+ 2. Additional Mapping Rule: The additional mapping rule consists of
+ the following sub-rules.
+
+ a. 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.)
+
+ b. Remove any instances of the ASCII space character at the
+ beginning or end of a nickname (e.g., "stpeter " is mapped to
+ "stpeter").
+
+ c. Map interior sequences of more than one ASCII space character
+ to a single ASCII space character (e.g., "St Peter" is
+ mapped to "St Peter").
+
+ 3. Case Mapping Rule: Apply the Unicode toLowerCase() operation, as
+ defined in the Unicode Standard [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.)
+
+ 4. 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
+
+
+
+
+Saint-Andre Standards Track [Page 4]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ 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).
+
+ 5. Directionality Rule: There is no directionality rule. The "Bidi
+ Rule" (defined in [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.
+
+ 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.
+
+2.2. Preparation
+
+ 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 [RFC8264].
+
+2.3. Enforcement
+
+ An entity that performs enforcement according to this profile MUST
+ prepare an input string as described in Section 2.2 and MUST also
+ apply the following rules specified in Section 2.1 in the order
+ shown:
+
+ 1. Additional Mapping Rule
+ 2. Normalization Rule
+
+ Note: An entity SHOULD apply the Case Mapping Rule only during
+ comparison.
+
+ 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).
+
+
+
+Saint-Andre Standards Track [Page 5]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ 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).
+
+2.4. Comparison
+
+ An entity that performs comparison of two strings according to this
+ profile MUST prepare each input string as specified in Section 2.2
+ and MUST apply the following rules specified in Section 2.1 in the
+ order shown:
+
+ 1. Additional Mapping Rule
+ 2. Case Mapping Rule
+ 3. Normalization Rule
+
+ 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").
+
+ 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).
+
+3. Examples
+
+ 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 "<" and ">" are used to delineate
+ the actual nickname and are not part of the nickname strings).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 6]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ +---------------------------+-------------------------------------+
+ | # | 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 |
+ | | | WITH DIALYTIKA, U+03CB) |
+ +---------------------------+-------------------------------------+
+ | 9 | <∞> | ∞ (INFINITY, U+221E) |
+ +---------------------------+-------------------------------------+
+ | 10 | <Richard Ⅳ> | <richard iv> |
+ +---------------------------+-------------------------------------+
+
+ Table 1: A Sample of Legal Nicknames
+
+ 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 Section 2.4 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.
+
+ Regarding example 8: this is an instance where applying the rules for
+ the Nickname profile is not an idempotent procedure (see
+ Section 2.1). In particular:
+
+ 1. 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 CAPITAL LETTER UPSILON WITH DIALYTIKA, U+03AB).
+
+
+
+
+Saint-Andre Standards Track [Page 7]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ 2. Applying toLowerCase() to "Ϋ" (GREEK CAPITAL LETTER UPSILON WITH
+ DIALYTIKA, U+03AB) results in the character "ϋ" (GREEK SMALL
+ LETTER UPSILON WITH DIALYTIKA, U+03CB), and applying NFKC to that
+ character results in no changes.
+
+ Regarding example 9: symbol characters such as "∞" (INFINITY, U+221E)
+ are allowed by the PRECIS FreeformClass and thus can be used in
+ nicknames.
+
+ 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).
+
+4. Use in Application Protocols
+
+ 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
+ [RFC8264] for guidelines about using PRECIS profiles in applications.
+
+ 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.).
+
+ 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.).
+
+ Entities that enforce the rules specified in this document are
+ encouraged to be liberal in what they accept by following this
+ procedure:
+
+ 1. Where possible, map characters (e.g., through width mapping,
+ additional mapping, case mapping, or normalization) and accept
+ the mapped string.
+
+
+
+Saint-Andre Standards Track [Page 8]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ 2. If mapping is not possible (e.g., because a character is
+ disallowed in the FreeformClass), reject the string.
+
+5. IANA Considerations
+
+ IANA has added the following entry to the "PRECIS Profiles" registry:
+
+ Name: Nickname.
+
+ Base Class: FreeformClass.
+
+ Applicability: Nicknames or display names in messaging and text
+ conferencing technologies; petnames for devices, accounts, and
+ people; and other uses of nicknames, display names, or petnames.
+
+ Replaces: None.
+
+ Width Mapping Rule: None (handled via NFKC).
+
+ 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 single
+ instance of SPACE (U+0020).
+
+ Case Mapping Rule: Map uppercase and titlecase code points to
+ lowercase using the Unicode toLowerCase() operation.
+
+ Normalization Rule: NFKC.
+
+ Directionality Rule: None.
+
+ Enforcement: To be specified by applications.
+
+ Specification: RFC 8266.
+
+6. Security Considerations
+
+6.1. Authentication and Authorization
+
+ It is important to understand that a nickname is a personally
+ memorable name or handle for something that has a more stable,
+ underlying identity, such as a URI or a file path. To ensure secure
+ operation of applications that use nicknames, authentication and
+ authorization decisions MUST be made on the basis of the thing's
+ identity, not its nickname.
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 9]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+6.2. Reuse of PRECIS
+
+ The security considerations described in [RFC8264] apply to the
+ FreeformClass string class used in this document for nicknames.
+
+6.3. Reuse of Unicode
+
+ The security considerations described in [UTS39] apply to the use of
+ Unicode code points in nicknames.
+
+6.4. Visually Similar Characters
+
+ [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.
+
+ Although the mapping rules defined in Section 2 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 [UTS39].
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
+ for Internationalized Domain Names for Applications
+ (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
+ <https://www.rfc-editor.org/info/rfc5893>.
+
+ [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
+ Internationalization in the IETF", BCP 166, RFC 6365,
+ DOI 10.17487/RFC6365, September 2011,
+ <https://www.rfc-editor.org/info/rfc6365>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 10]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
+ Preparation, Enforcement, and Comparison of
+ Internationalized Strings in Application Protocols",
+ RFC 8264, DOI 10.17487/RFC8264, October 2017,
+ <https://www.rfc-editor.org/info/rfc8264>.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard",
+ <http://www.unicode.org/versions/latest/>.
+
+ [UTS39] Unicode Technical Standard #39, "Unicode Security
+ Mechanisms", edited by Mark Davis and Michel Suignard,
+ <http://unicode.org/reports/tr39/>.
+
+7.2. Informative References
+
+ [Err4570] RFC Errata, Erratum ID 4570, RFC 7700,
+ <https://www.rfc-editor.org/errata/eid4570>.
+
+ [PETNAME-SYSTEMS]
+ Stiegler, M., "An Introduction to Petname Systems",
+ updated June 2010, February 2005,
+ <http://www.skyhunter.com/marcs/petnames/
+ IntroPetNames.html>.
+
+ [RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
+ RFC 20, DOI 10.17487/RFC0020, October 1969,
+ <https://www.rfc-editor.org/info/rfc20>.
+
+ [RFC2811] Kalt, C., "Internet Relay Chat: Channel Management",
+ RFC 2811, DOI 10.17487/RFC2811, April 2000,
+ <https://www.rfc-editor.org/info/rfc2811>.
+
+ [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
+ "The Message Session Relay Protocol (MSRP)", RFC 4975,
+ DOI 10.17487/RFC4975, September 2007,
+ <https://www.rfc-editor.org/info/rfc4975>.
+
+ [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
+ Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239,
+ June 2008, <https://www.rfc-editor.org/info/rfc5239>.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ <https://www.rfc-editor.org/info/rfc5322>.
+
+ [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
+ March 2011, <https://www.rfc-editor.org/info/rfc6120>.
+
+
+
+Saint-Andre Standards Track [Page 11]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ [RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison
+ of Internationalized Strings Representing Nicknames",
+ RFC 7700, DOI 10.17487/RFC7700, December 2015,
+ <https://www.rfc-editor.org/info/rfc7700>.
+
+ [RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-
+ party Chat Using the Message Session Relay Protocol
+ (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015,
+ <https://www.rfc-editor.org/info/rfc7701>.
+
+ [XCON-SYSTEM]
+ Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within
+ a Centralized Conferencing (XCON) System", Work in
+ Progress, draft-boulton-xcon-session-chat-08, July 2012.
+
+ [XEP-0045]
+ Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
+ September 2017,
+ <https://xmpp.org/extensions/xep-0045.html>.
+
+ [XEP-0172]
+ Saint-Andre, P. and V. Mercier, "User Nickname", XSF
+ XEP 0172, March 2012,
+ <https://xmpp.org/extensions/xep-0172.html>.
+
+Appendix A. Changes from RFC 7700
+
+ The following changes were made from [RFC7700].
+
+ o Addressed [Err4570] by removing the directionality rule from
+ Sections 2.3 and 2.4.
+
+ o In accordance with working group discussions and updates to
+ [RFC8264], removed the use of the Unicode toCaseFold() operation
+ in favor of the Unicode toLowerCase() operation.
+
+ o Clarified several editorial matters.
+
+ o Updated references.
+
+Acknowledgements
+
+ Thanks to William Fisher for his implementation feedback, especially
+ regarding idempotence.
+
+ Thanks to Sam Whited for his feedback and for submitting [Err4570].
+
+
+
+
+
+Saint-Andre Standards Track [Page 12]
+
+RFC 8266 PRECIS: Nicknames October 2017
+
+
+ See [RFC7700] for acknowledgements related to the specification that
+ this document supersedes.
+
+Author's Address
+
+ Peter Saint-Andre
+ Jabber.org
+ P.O. Box 787
+ Parker, CO 80134
+ United States of America
+
+ Phone: +1 720 256 6756
+ Email: stpeter@jabber.org
+ URI: https://www.jabber.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 13]