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