idnits 2.17.1 draft-saintandre-precis-nickname-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-precis-framework-01 == Outdated reference: A later version (-18) exists of draft-ietf-simple-chat-14 ** Obsolete normative reference: RFC 6122 (Obsoleted by RFC 7622) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR39' -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0045' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PRECIS P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track March 5, 2012 5 Expires: September 6, 2012 7 Preparation and Comparison of Nicknames 8 draft-saintandre-precis-nickname-00 10 Abstract 12 This document describes how to prepare and compare Unicode strings 13 representing nicknames, primarily as used within textual chatrooms. 14 This profile is intended to be used by chatroom technologies based on 15 both the Extensible Messaging and Presence Protocol (XMPP) and the 16 Message Session Relay Protocol (MSRP). 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 6, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Visually Similar Characters . . . . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 63 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 1.1. Overview 70 Technologies for textual chatrooms customarily enable participants to 71 specify a nickname for use in the room; e.g., this is true of 72 Internet Relay Chat [RFC2811], Multi-User Chat (MUC) based on the 73 Extensible Messaging and Presence Protocol (XMPP) [XEP-0045], and 74 multi-party chat based on the Message Session Relay Protocol (MSRP) 75 [I-D.ietf-simple-chat]. Recent chatroom technologies also allow 76 internationalized nicknames because they support characters from the 77 outside the ASCII range, typically by means of the Unicode character 78 set [UNICODE]. Although such nicknames are often used primarily for 79 display purposes, they are sometimes used for programmatic purposes 80 as well (e.g., kicking users or avoiding nickname conflicts). 82 To increase the likelihood that nickname input and comparison will 83 work in ways that make sense for typical users throughout the world, 84 this document defines rules for preparing and comparing 85 internationalized nicknames. 87 1.2. Terminology 89 Many important terms used in this document are defined in 90 [I-D.ietf-precis-framework], [RFC6365], and [UNICODE]. Relevant XMPP 91 terms are defined in [RFC6120] and [XEP-0045], and relevant MSRP 92 terms in [RFC4975] and [I-D.ietf-simple-chat]. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in RFC 97 2119 [RFC2119]. 99 2. Rules 101 A nickname MUST NOT be zero bytes in length and MUST NOT be more than 102 1023 bytes in length (the latter restriction is derived from the 103 length restriction on XMPP resourceparts, see [RFC6122]). This rule 104 is to be enforced after any mapping or normalization of code points. 106 A nickname MUST consist only of Unicode code points that conform to 107 the "FreeClass" base string class defined in 108 [I-D.ietf-precis-framework]. 110 For preparation purposes (e.g., when a chatroom client generates a 111 nickname from user input for inclusion as a nickname protocol 112 element), an application MUST only ensure that the string conforms to 113 the "FreeClass" base string class defined in 114 [I-D.ietf-precis-framework]; however, it MAY also perform the mapping 115 and normalization operations specified below for comparison. 117 For comparison purposes (e.g., when a chatroom server determines if 118 two nicknames match during the authorization process), an application 119 MUST treat a nickname as follows, where the operations specified MUST 120 be completed in the order shown: 122 1. Non-ASCII space characters from the "N" category defined under 123 Section 6.14 of [I-D.ietf-precis-framework] MUST be mapped to 124 SPACE [U+0020]. 126 2. Uppercase and titlecase characters MUST be mapped to their 127 lowercase equivalents. In applications that prohibit matching 128 nicknames, this rule helps to reduce the possibility of confusion 129 by ensuring that nicknames differing only by case (e.g., 130 "stpeter" vs. "StPeter") would not be allowed in a room at the 131 same time. 133 3. All characters MUST be mapped using Unicode Normalization Form KC 134 (NFKC). Because NFKC is more "aggressive" in finding matches 135 than other normalization forms (in the language of Unicode, it 136 performs both canonical and compatibility decomposition before 137 recomposing code points), this rule helps to reduce the 138 possibility of confusion by increasing the number of characters 139 that would match (e.g., ROMAN NUMERAL FOUR [U+2163] would match 140 the combination of LATIN CAPITAL LETTER I [U+0049] and LATIN 141 CAPITAL LETTER V [U+0056]). 143 For both preparation and comparision, the "Bidi Rule" provided in 144 [RFC5893] applies to the directionality of a nickname. 146 3. Security Considerations 148 3.1. Reuse of PRECIS 150 The security considerations described in [I-D.ietf-precis-framework] 151 apply to the "FreeClass" base string class used in this document for 152 nicknames, respectively. 154 3.2. Reuse of Unicode 156 The security considerations described in [UTR39] apply to the use of 157 Unicode characters in nicknames. 159 3.3. Visually Similar Characters 161 [I-D.ietf-precis-framework] describes some of the security 162 considerations related to visually similar characters, also called 163 "confusable characters" or "confusables". 165 Although the mapping rules under Section 2 are designed in part to 166 reduce the possibility of confusion about nicknames, this document 167 does not yet provide more detailed recommendations regarding the 168 handling of visually similar characters, such as those in [UTR39]. 169 However, a future version of this document might provide such 170 recommendations. 172 4. IANA Considerations 174 The IANA shall add an entry to the PRECIS Usage Registry for reuse of 175 the PRECIS FreeClass for preparation and comparision of nicknames, as 176 follows: 178 Application Protocol: MSRP and XMPP. 179 Base Class: FreeClass 180 Subclassing: No. 181 Directionality: The "Bidi Rule" defined in RFC 5893 applies. 182 Casemapping: None. 183 Normalization: NFC. 184 Specification: RFC XXXX. 186 5. References 188 5.1. Normative References 190 [I-D.ietf-precis-framework] 191 Blanchet, M. and P. Saint-Andre, "Precis Framework: 192 Handling Internationalized Strings in Protocols", 193 draft-ietf-precis-framework-01 (work in progress), 194 October 2011. 196 [I-D.ietf-simple-chat] 197 Niemi, A., Garcia, M., and G. Sandbakken, "Multi-party 198 Chat Using the Message Session Relay Protocol (MSRP)", 199 draft-ietf-simple-chat-14 (work in progress), March 2012. 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 205 Internationalized Domain Names for Applications (IDNA)", 206 RFC 5893, August 2010. 208 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 209 Protocol (XMPP): Address Format", RFC 6122, March 2011. 211 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 212 6.1", 2012, 213 . 215 [UTR39] The Unicode Consortium, "Unicode Technical Report #39: 216 Unicode Security Mechanisms", August 2010, 217 . 219 [XEP-0045] 220 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 221 February 2012. 223 5.2. Informative References 225 [RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", 226 RFC 2811, April 2000. 228 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 229 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 231 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 232 Protocol (XMPP): Core", RFC 6120, March 2011. 234 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 235 Internationalization in the IETF", BCP 166, RFC 6365, 236 September 2011. 238 Author's Address 240 Peter Saint-Andre 241 Cisco Systems, Inc. 242 1899 Wynkoop Street, Suite 600 243 Denver, CO 80202 244 USA 246 Phone: +1-303-308-3282 247 Email: psaintan@cisco.com