idnits 2.17.1
draft-blanchet-precis-framework-03.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 (August 19, 2011) is 4626 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)
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'
== Outdated reference: A later version (-09) exists of
draft-iab-identifier-comparison-00
== Outdated reference: A later version (-09) exists of
draft-ietf-precis-problem-statement-03
-- Obsolete informational reference (is this intentional?): RFC 3454
(Obsoleted by RFC 7564)
-- Obsolete informational reference (is this intentional?): RFC 3490
(Obsoleted by RFC 5890, RFC 5891)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
== Outdated reference: A later version (-02) exists of
draft-saintandre-xmpp-6122bis-01
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Blanchet
3 Internet-Draft Viagenie
4 Obsoletes: 3454 (if approved) P. Saint-Andre
5 Intended status: Standards Track Cisco
6 Expires: February 20, 2012 August 19, 2011
8 PRECIS Framework: Handling Internationalized Strings in Protocols
9 draft-blanchet-precis-framework-03
11 Abstract
13 Application protocols that make use of Unicode code points in
14 protocol strings need to prepare such strings in order to perform
15 comparison operations (e.g., for purposes of authentication or
16 authorization). In general, this problem has been labeled the
17 "preparation and comparison of internationalized strings" or
18 "PRECIS". This document defines a framework that enables application
19 protocols to prepare various classes of strings in a way that depends
20 on the properties of Unicode code points. Because this framework
21 does not depend on large tables of Unicode code points as in
22 stringprep (RFC 3454), it is more agile with regard to changes in the
23 underlying Unicode database and thus provides improved flexibility to
24 application protocols. A specification that uses this framework
25 either can directly use the base string classes defined in this
26 document or can subclass the base string classes as needed. This
27 framework uses an approach similar to that of the revised
28 internationalized domain names in applications (IDNA) technology (RFC
29 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the
30 high-level design goals described in RFC 4690, albeit for application
31 technologies other than the Domain Name System (DNS). This document
32 obsoletes RFC 3454.
34 Status of this Memo
36 This Internet-Draft is submitted in full conformance with the
37 provisions of BCP 78 and BCP 79.
39 Internet-Drafts are working documents of the Internet Engineering
40 Task Force (IETF). Note that other groups may also distribute
41 working documents as Internet-Drafts. The list of current Internet-
42 Drafts is at http://datatracker.ietf.org/drafts/current/.
44 Internet-Drafts are draft documents valid for a maximum of six months
45 and may be updated, replaced, or obsoleted by other documents at any
46 time. It is inappropriate to use Internet-Drafts as reference
47 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on February 20, 2012.
50 Copyright Notice
52 Copyright (c) 2011 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
69 3. String Classes . . . . . . . . . . . . . . . . . . . . . . . . 6
70 3.1. NameClass . . . . . . . . . . . . . . . . . . . . . . . . 7
71 3.1.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 7
72 3.1.2. Disallowed . . . . . . . . . . . . . . . . . . . . . . 8
73 3.1.3. Unassigned . . . . . . . . . . . . . . . . . . . . . . 8
74 3.1.4. Directionality . . . . . . . . . . . . . . . . . . . . 8
75 3.1.5. Case Mapping . . . . . . . . . . . . . . . . . . . . . 8
76 3.1.6. Normalization . . . . . . . . . . . . . . . . . . . . 8
77 3.2. SecretClass . . . . . . . . . . . . . . . . . . . . . . . 8
78 3.2.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 9
79 3.2.2. Disallowed . . . . . . . . . . . . . . . . . . . . . . 9
80 3.2.3. Unassigned . . . . . . . . . . . . . . . . . . . . . . 9
81 3.2.4. Directionality . . . . . . . . . . . . . . . . . . . . 9
82 3.2.5. Case Mapping . . . . . . . . . . . . . . . . . . . . . 9
83 3.2.6. Normalization . . . . . . . . . . . . . . . . . . . . 9
84 3.3. FreeClass . . . . . . . . . . . . . . . . . . . . . . . . 10
85 3.3.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 10
86 3.3.2. Disallowed . . . . . . . . . . . . . . . . . . . . . . 10
87 3.3.3. Unassigned . . . . . . . . . . . . . . . . . . . . . . 10
88 3.3.4. Directionality . . . . . . . . . . . . . . . . . . . . 10
89 3.3.5. Case Mapping . . . . . . . . . . . . . . . . . . . . . 10
90 3.3.6. Normalization . . . . . . . . . . . . . . . . . . . . 11
91 4. Use of PRECIS String Classes . . . . . . . . . . . . . . . . . 11
92 4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 11
93 4.2. Subclassing . . . . . . . . . . . . . . . . . . . . . . . 11
94 4.3. Registration . . . . . . . . . . . . . . . . . . . . . . . 11
95 5. Code Point Properties . . . . . . . . . . . . . . . . . . . . 12
96 6. Category Definitions Used to Calculate Derived Property
97 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
98 6.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . . 14
99 6.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . . 14
100 6.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 15
101 6.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 15
102 6.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 15
103 6.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . . 15
104 6.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . . 16
105 6.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 17
106 6.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 17
107 6.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . . 17
108 6.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . . 18
109 6.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . . 18
110 6.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 18
111 6.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . . 18
112 6.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 18
113 6.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 19
114 6.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 19
115 7. Calculation of the Derived Property . . . . . . . . . . . . . 19
116 8. Code Points . . . . . . . . . . . . . . . . . . . . . . . . . 20
117 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
118 9.1. PRECIS Derived Property Value Registry . . . . . . . . . . 20
119 9.2. PRECIS Usage Registry . . . . . . . . . . . . . . . . . . 21
120 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
121 10.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 21
122 10.2. Local Character Set Issues . . . . . . . . . . . . . . . . 22
123 10.3. Visually Similar Characters . . . . . . . . . . . . . . . 22
124 10.4. Security of the SecretClass . . . . . . . . . . . . . . . 24
125 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
126 12. Codepoints 0x0000 - 0x10FFFF . . . . . . . . . . . . . . . . . 25
127 12.1. Codepoints in Unicode Character Database (UCD) format . . 25
128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
129 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
130 13.2. Informative References . . . . . . . . . . . . . . . . . . 25
131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
133 1. Introduction
135 A number of IETF application technologies use stringprep [RFC3454] as
136 the basis for comparing protocol strings that contain Unicode
137 characters or "code points" [UNICODE]. Since the publication of
138 [RFC3454] in 2002, the Internet community has gained much more
139 experience with internationalization, some of it reflected in
140 [RFC4690]. In particular, the IETF's technology for
141 internationalized domain names (IDNs) has changed significantly:
142 IDNA2003 [RFC3490], which was based on stringprep, has been
143 superseded by IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893],
144 [RFC5894]), which does not use stringprep. This migration away from
145 stringprep for internationalized domain names has prompted other
146 "customers" of stringprep to consider new approaches to the
147 preparation and comparison of internationalized strings ("PRECIS"),
148 as described in [PROBLEM].
150 This document proposes a technical framework for a post-stringprep
151 approach to the preparation and comparison of internationalized
152 strings in application protocols. The framework is based on several
153 principles:
155 1. Define a small set of base string classes appropriate for common
156 application protocol constructs such as usernames, passwords, and
157 free-form identifiers.
159 2. Define each base string class in terms of Unicode code points and
160 their properties, specifying whether each code point or character
161 category is valid, disallowed, or unassigned.
163 3. Enable application protocols to subclass the base string classes,
164 mainly to disallow particular code points that are currently
165 disallowed in the relevant application protocol (e.g., characters
166 with special or reserved meaning, such as "@" and "/" when used
167 as separators within identifiers).
169 4. Leave various mapping operations (e.g., case preservation or
170 lowercasing, Unicode normalization, right-to-left characters) as
171 the responsibility of application protocols, as was done for
172 IDNA2008 via [RFC5895].
174 It is expected that this framework will yield the following benefits:
176 o Application protocols will be more version-agile with regard to
177 the Unicode database.
178 o Implementers will be able to share code point tables and software
179 code across application protocols, most likely by means of
180 software libraries.
182 o End users will be able to acquire more accurate expectations about
183 the code points that are acceptable in various contexts. Given
184 this more uniform set of string classes, it is also expected that
185 copy/paste operations between software implementing different
186 application protocols will be more predictable and coherent.
188 Although this framework is similar to IDNA2008 and borrows some of
189 the character categories defined in [RFC5892], it defines additional
190 string classes and character categories to meet the needs of common
191 application protocols.
193 2. Terminology
195 Many important terms used in this document are defined in [PROBLEM],
196 [I18N-TERMS], [RFC5890], and [UNICODE].
198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
200 "OPTIONAL" in this document are to be interpreted as described in
201 [RFC2119].
203 3. String Classes
205 IDNA2008 essentially defines a base string class of internationalized
206 domain name, although it does not use the term "string class". (This
207 document does not define a string class for domain names, and
208 application protocols are strongly encouraged to use IDNA2008 as the
209 appropriate method to prepare domain names and hostnames.)
211 We propose the following additional base string classes for use in
212 application protocols:
214 NameClass: a sequence of letters, numbers, and symbols that is used
215 to identify or address a network entity such as a user, an
216 account, a venue (e.g., a chatroom), an information source (e.g.,
217 a data feed), or a collection of data (e.g., a file).
219 SecretClass: a sequence of letters, numbers, and symbols that is
220 used as a secret for access to some resource on a network (e.g., a
221 password or passphrase).
223 FreeClass: a sequence of letters, numbers, symbols, spaces, and
224 other code points that is used for more expressive purposes in an
225 application protocol (e.g., a free-form identifier such as a
226 human-friendly nickname in a chatroom).
228 The following subsections discuss these string classes in more
229 detail, with reference to the dimensions described in Section 3 of
230 [PROBLEM].
232 Each string class is defined by the following behavioral rules:
234 Valid: defines which code points and character categories are
235 treated as valid input to preparation of the string.
237 Disallowed: defines which code points and character categories are
238 treated as disallowed during preparation of the string.
240 Unassigned: defines application behavior in the presence of code
241 points that are unassigned, i.e. unknown for the version of
242 Unicode the application is built upon.
244 Directionality: defines application behavior in the presence of code
245 points that have directionality, in particular right-to-left code
246 points as defined in the Unicode database (see [UAX9]).
248 Casemapping: defines if case mapping is used for this class, and how
249 the mapping is done.
251 Normalization: defines which Unicode normalization form (D, KD, C,
252 or KC) is to be applied (see [UAX15]).
254 This document defines the valid, disallowed, and unassigned rules.
255 Application protocols that use the PRECIS string classes MUST define
256 the directionality, casemapping, and normalization rules, as further
257 described under Section 9.2.
259 3.1. NameClass
261 Most application technologies need a special class of strings that
262 can be used to refer to, include, or communicate things like
263 usernames, chatroom names, file names, and data feed names. We group
264 such things into a bucket called "NameClass" having the following
265 features.
267 3.1.1. Valid
269 o Letters and numbers, i.e., the LetterDigits ("A") category first
270 defined in [RFC5892] and listed here under Section 6.1.
271 o Code points in the range U+0021 through U+007E, i.e., the ASCII7
272 ("K") rule defined under Section 6.11. These code points are
273 valid even if they would otherwise be disallowed according to the
274 property-based rules specified in the next section.
276 3.1.2. Disallowed
278 o Control characters, i.e., the Controls ("L") category defined
279 under Section 6.12.
280 o Space characters, i.e., the Spaces ("N") category defined under
281 Section 6.14.
282 o Symbol characters, i.e., the Symbols ("O") category defined under
283 Section 6.15.
284 o Punctuation characters, i.e., the Punctuation ("P") category
285 defined under Section 6.16.
286 o Any character that has a compatibility equivalent, i.e., the
287 HasCompat ("Q") category defined under Section 6.17. These code
288 points are disallowed even if they would otherwise be valid
289 according to the property-based rules specified in the previous
290 section.
292 3.1.3. Unassigned
294 Any code points that are not yet assigned in the Unicode character
295 set SHALL be considered Unassigned for purposes of the NameClass.
297 3.1.4. Directionality
299 The directionality rule MUST be specified by each application
300 protocol that uses or subclasses the NameClass.
302 3.1.5. Case Mapping
304 The casemapping rule MUST be specified by each application protocol
305 that uses or subclasses the NameClass.
307 3.1.6. Normalization
309 The normalization form MUST be specified by each application protocol
310 that uses or subclasses the NameClass.
312 However, in accordance with [RFC5198], normalization form C (NFC) is
313 RECOMMENDED.
315 3.2. SecretClass
317 Many application technologies need a special class of strings that
318 can be used to communicate secrets of the kind that are typically
319 used as passwords or passphrases. We group such things into a bucket
320 called "SecretClass" having the following features.
322 NOTE: Consult Section 10.4 for relevant security considerations.
324 3.2.1. Valid
326 o Letters and numbers, i.e., the LetterDigits ("A") category first
327 defined in [RFC5892] and listed here under Section 6.1.
328 o Code points in the range U+0021 through U+007E, i.e., the ASCII7
329 ("K") rule defined under Section 6.11. These code points are
330 valid even if they would otherwise be disallowed according to the
331 property-based rules specified in the next section.
332 o Any character that has a compatibility equivalent, i.e., the
333 HasCompat ("Q") category defined under Section 6.17.
334 o Symbol characters, i.e., the Symbols ("O") category defined under
335 Section 6.15.
336 o Punctuation characters, i.e., the Punctuation ("P") category
337 defined under Section 6.16.
339 3.2.2. Disallowed
341 o Control characters, i.e., the Controls ("L") category defined
342 under Section 6.12.
343 o Space characters, i.e., the Spaces ("N") category defined under
344 Section 6.14.
346 3.2.3. Unassigned
348 Any code points that are not yet assigned in the Unicode character
349 set SHALL be considered Unassigned for purposes of the SecretClass.
351 3.2.4. Directionality
353 The directionality rule MUST be specified by each application
354 protocol that uses or subclasses the SecretClass.
356 3.2.5. Case Mapping
358 The casemapping rule MUST be specified by each application protocol
359 that uses or subclasses the SecretClass.
361 However, in order to maximize the entropy of passwords and
362 passphrases, it is NOT RECOMMENDED for application protocols to map
363 uppercase and titlecase code points to their lowercase equivalents;
364 instead, it is RECOMMENDED to preserve the case of all code points
365 contained in string that conform to or subclass the SecretClass.
367 3.2.6. Normalization
369 The normalization form MUST be specified by each application protocol
370 that uses or subclasses the SecretClass.
372 However, in accordance with [RFC5198], normalization form C (NFC) is
373 RECOMMENDED.
375 3.3. FreeClass
377 Some application technologies need a special class of strings that
378 can be used in a free-form way (e.g., a nickname in a chatroom). We
379 group such things into a bucket called "FreeClass" having the
380 following features.
382 3.3.1. Valid
384 o Letters and numbers, i.e., the LetterDigits ("A") category first
385 defined in [RFC5892] and listed here under Section 6.1.
386 o Code points in the range U+0021 through U+007E, i.e., the ASCII7
387 ("K") rule defined under Section 6.11.
388 o Any character that has a compatibility equivalent, i.e., the
389 HasCompat ("Q") category defined under Section 6.17.
390 o Space characters, i.e., the Spaces ("N") category defined under
391 Section 6.14.
392 o Symbol characters, i.e., the Symbols ("O") category defined under
393 Section 6.15.
394 o Punctuation characters, i.e., the Punctuation ("P") category
395 defined under Section 6.16.
397 3.3.2. Disallowed
399 o Control characters, i.e., the Controls ("L") category defined
400 under Section 6.12.
402 3.3.3. Unassigned
404 Any code points that are not yet assigned in the Unicode character
405 set SHALL be considered Unassigned for purposes of the FreeClass.
407 3.3.4. Directionality
409 The directionality rule MUST be specified by each application
410 protocol that uses or subclasses the FreeClass.
412 3.3.5. Case Mapping
414 The casemapping rule MUST be specified by each application protocol
415 that uses or subclasses the FreeClass.
417 3.3.6. Normalization
419 The normalization form MUST be specified by each application protocol
420 that uses or subclasses the FreeClass.
422 However, in accordance with [RFC5198], normalization form C (NFC) is
423 RECOMMENDED.
425 4. Use of PRECIS String Classes
427 4.1. Principles
429 This document defines the valid, disallowed, and unassigned rules.
430 Application protocols that use the PRECIS string classes MUST define
431 the directionality, casemapping, and normalization rules. Such
432 definitions MUST at a minimum specify the following:
434 Directionality: Whether any instance of the class that contains a
435 right-to-left code point is to be considered a right-to-left
436 string, or whether some other rule is to be applied (e.g., the
437 "Bidi Rule" from [RFC5893]).
439 Casemapping: Whether uppercase and titlecase code points are to be
440 (a) preserved or (b) mapped to lowercase.
442 Normalization: Which Unicode normalization form (D, KD, C, or KC) is
443 to be applied (see [UAX15] for background information); in
444 accordance with [RFC5198], NFC is RECOMMENDED.
446 4.2. Subclassing
448 Application protocols are allowed to subclass the base string classes
449 specified in this document. As the word "subclass" implies, a
450 subclass MUST NOT add as valid any code points or character
451 categories that are disallowed by the base string class. However, a
452 subclass MAY do either of the following:
454 1. Exclude specific code points that are included in the base string
455 class.
456 2. Exclude characters matching certain Unicode properties (e.g.,
457 math symbols) that are included in the base string class.
459 4.3. Registration
461 Application protocols that use the PRECIS string classes MUST
462 register with the IANA as described under Section 9.2. This is
463 especially important for protocols that subclass the PRECIS string
464 classes.
466 5. Code Point Properties
468 In order to implement the string classes described above, this
469 document does the following:
471 1. Reviews and classifies the collections of code points in the
472 Unicode character set by examining various code point properties.
474 2. Defines an algorithm for determining a derived property value,
475 which can vary depending on the string class being used by the
476 relevant application protocol.
478 This document is not intended to specify precisely how derived
479 property values are to be applied in protocol strings. That
480 information should be defined in the protocol specification that uses
481 or subclasses a base string class from this document.
483 The value of the property is to be interpreted as follows.
485 PROTOCOL VALID Those code points that are allowed to be used in any
486 PRECIS string class (NameClass, SecretClass, and FreeClass). Code
487 points with this property value are permitted for general use in
488 any string class. The abbreviated term PVALID is used to refer to
489 this value in the remainder of this document.
491 SPECIFIC CLASS PROTOCOL VALID Those code points that are allowed to
492 be used in specific string classes. Code points with this
493 property value are permitted for use in specific string classes.
494 In the remainder of this document, the abbreviated term *_PVALID
495 is used, where * = (NAMECLASS | SECRETCLASS | FREECLASS).
497 CONTEXTUAL RULE REQUIRED Some characteristics of the character, such
498 as its being invisible in certain contexts or problematic in
499 others, require that it not be used in labels unless specific
500 other characters or properties are present. The abbreviated term
501 CONTEXT is used to refer to this value in the remainder of this
502 document. There are two subdivisions of CONTEXTUAL RULE REQUIRED,
503 the first for Join_controls (called CONTEXTJ) and the second for
504 other characters (called CONTEXTO).
506 DISALLOWED Those code points that must not be included in any string
507 class. Code points with this property value are not permitted in
508 any string class.
510 SPECIFIC CLASS DISALLOWED Those code points that are not to be
511 included in a specific string class. Code points with this
512 property value are not permitted in one of the string classes but
513 might be permitted in others. In the remainder of this document,
514 the abbreviated term *_DISALLOWED is used, where * = (NAMECLASS |
515 SECRETCLASS | FREECLASS).
517 UNASSIGNED Those code points that are not designated (i.e. are
518 unassigned) in the Unicode Standard.
520 The mechanisms described here allow determination of the value of the
521 property for future versions of Unicode (including characters added
522 after Unicode 5.2 or 6.0 depending on the category, since some
523 categories in this document are reused from IDNA2008). Changes in
524 Unicode properties that do not affect the outcome of this process do
525 not affect this framework. For example, a character can have its
526 Unicode General_Category value [UNICODE] change from So to Sm, or
527 from Lo to Ll, without affecting the algorithm results. Moreover,
528 even if such changes were to result, the BackwardCompatible list
529 (Section 6.7) can be adjusted to ensure the stability of the results.
531 Some code points need to be allowed in exceptional circumstances, but
532 should be excluded in all other cases; these rules are also described
533 in other documents. The most notable of these are the Join Control
534 characters, U+200D ZERO WIDTH JOINER and U+200C ZERO WIDTH NON-
535 JOINER. Both of them have the derived property value CONTEXTJ. A
536 character with the derived property value CONTEXTJ or CONTEXTO
537 (CONTEXTUAL RULE REQUIRED) is not to be used unless an appropriate
538 rule has been established and the context of the character is
539 consistent with that rule. It is invalid to generate a string
540 containing these characters unless such a contextual rule is found
541 and satisfied. PRECIS does not define its own contextual rules, but
542 instead re-uses the contextual rules defined for IDNA2008; please see
543 Appendix A of [RFC5892] for more information.
545 6. Category Definitions Used to Calculate Derived Property Value
547 The derived property obtains its value based on a two-step procedure:
549 1. Characters are placed in one or more character categories either
550 (1) based on core properties defined by the Unicode Standard or
551 (2) by treating the code point as an exception and addressing the
552 code point as its code point value. These categories are not
553 mutually exclusive.
555 2. Set operations are used with these categories to determine the
556 values for a property that is specific to a given string class.
557 These operations are specified under Section 7.
559 (NOTE: Unicode property names and property value names might have
560 short abbreviations, such as "gc" for the General_Category property
561 and "Ll" for the Lowercase_Letter property value of the gc property.)
563 In the following specification of character categories, the operation
564 that returns the value of a particular Unicode character property for
565 a code point is designated by using the formal name of that property
566 (from the Unicode PropertyAliases.txt [1]) followed by '(cp)' for
567 "code point". For example, the value of the General_Category
568 property for a code point is indicated by General_Category(cp).
570 The first ten categories (A-J) shown below were previously defined
571 for IDNA2008 and are copied directly from [RFC5892]. Some of these
572 categories are reused in PRECIS and some of them are not; however,
573 the lettering of categories is retained to prevent overlap and to
574 ease implementation of both IDNA2008 and PRECIS in a single software
575 application. The next seven categories (K-Q) are specific to PRECIS.
577 6.1. LetterDigits (A)
579 NOTE: This category is defined in [RFC5892] and copied here for use
580 in PRECIS.
582 A: General_Category(cp) is in {Ll, Lu, Lo, Nd, Lm, Mn, Mc}
584 These rules identify characters commonly used in mnemonics and often
585 informally described as "language characters".
587 For more information, see section 4.5 of [UNICODE].
589 The categories used in this rule are:
590 o Ll - Lowercase_Letter
591 o Lu - Uppercase_Letter
592 o Lo - Other_Letter
593 o Nd - Decimal_Number
594 o Lm - Modifier_Letter
595 o Mn - Nonspacing_Mark
596 o Mc - Spacing_Mark
598 6.2. Unstable (B)
600 NOTE: This category is defined in [RFC5892] but not used in PRECIS.
602 6.3. IgnorableProperties (C)
604 NOTE: This category is defined in [RFC5892] but not used in PRECIS.
605 See the "PrecisIgnorableProperties (M)" category below for a more
606 inclusive category used in PRECIS identifiers.
608 6.4. IgnorableBlocks (D)
610 NOTE: This category is defined in [RFC5892] but not used in PRECIS.
612 6.5. LDH (E)
614 NOTE: This category is defined in [RFC5892] but not used in PRECIS.
615 See the "ASCII7 (K)" category below for a more inclusive category
616 used in PRECIS identifiers.
618 6.6. Exceptions (F)
620 NOTE: This category is defined in [RFC5892] and might be used in a
621 future version of this specification.
623 F: cp is in {00B7, 00DF, 0375, 03C2, 05F3, 05F4, 0640, 0660,
624 0661, 0662, 0663, 0664, 0665, 0666, 0667, 0668,
625 0669, 06F0, 06F1, 06F2, 06F3, 06F4, 06F5, 06F6,
626 06F7, 06F8, 06F9, 06FD, 06FE, 07FA, 0F0B, 3007,
627 302E, 302F, 3031, 3032, 3033, 3034, 3035, 303B,
628 30FB}
630 This category explicitly lists code points for which the category
631 cannot be assigned using only the core property values that exist in
632 the Unicode standard. The values are according to the table below:
634 PVALID -- Would otherwise have been DISALLOWED
636 00DF; PVALID # LATIN SMALL LETTER SHARP S
637 03C2; PVALID # GREEK SMALL LETTER FINAL SIGMA
638 06FD; PVALID # ARABIC SIGN SINDHI AMPERSAND
639 06FE; PVALID # ARABIC SIGN SINDHI POSTPOSITION MEN
640 0F0B; PVALID # TIBETAN MARK INTERSYLLABIC TSHEG
641 3007; PVALID # IDEOGRAPHIC NUMBER ZERO
643 CONTEXTO -- Would otherwise have been DISALLOWED
645 00B7; CONTEXTO # MIDDLE DOT
646 0375; CONTEXTO # GREEK LOWER NUMERAL SIGN (KERAIA)
647 05F3; CONTEXTO # HEBREW PUNCTUATION GERESH
648 05F4; CONTEXTO # HEBREW PUNCTUATION GERSHAYIM
649 30FB; CONTEXTO # KATAKANA MIDDLE DOT
650 CONTEXTO -- Would otherwise have been PVALID
652 0660; CONTEXTO # ARABIC-INDIC DIGIT ZERO
653 0661; CONTEXTO # ARABIC-INDIC DIGIT ONE
654 0662; CONTEXTO # ARABIC-INDIC DIGIT TWO
655 0663; CONTEXTO # ARABIC-INDIC DIGIT THREE
656 0664; CONTEXTO # ARABIC-INDIC DIGIT FOUR
657 0665; CONTEXTO # ARABIC-INDIC DIGIT FIVE
658 0666; CONTEXTO # ARABIC-INDIC DIGIT SIX
659 0667; CONTEXTO # ARABIC-INDIC DIGIT SEVEN
660 0668; CONTEXTO # ARABIC-INDIC DIGIT EIGHT
661 0669; CONTEXTO # ARABIC-INDIC DIGIT NINE
662 06F0; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT ZERO
663 06F1; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT ONE
664 06F2; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT TWO
665 06F3; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT THREE
666 06F4; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT FOUR
667 06F5; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT FIVE
668 06F6; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT SIX
669 06F7; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT SEVEN
670 06F8; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT EIGHT
671 06F9; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT NINE
673 DISALLOWED -- Would otherwise have been PVALID
675 0640; DISALLOWED # ARABIC TATWEEL
676 07FA; DISALLOWED # NKO LAJANYALAN
677 302E; DISALLOWED # HANGUL SINGLE DOT TONE MARK
678 302F; DISALLOWED # HANGUL DOUBLE DOT TONE MARK
679 3031; DISALLOWED # VERTICAL KANA REPEAT MARK
680 3032; DISALLOWED # VERTICAL KANA REPEAT WITH VOICED SOUND MARK
681 3033; DISALLOWED # VERTICAL KANA REPEAT MARK UPPER HALF
682 3034; DISALLOWED # VERTICAL KANA REPEAT WITH VOICED SOUND MARK
683 UPPER HA
684 3035; DISALLOWED # VERTICAL KANA REPEAT MARK LOWER HALF
685 303B; DISALLOWED # VERTICAL IDEOGRAPHIC ITERATION MARK
687 6.7. BackwardCompatible (G)
689 NOTE: This category is defined in [RFC5892] and copied here for use
690 in PRECIS. Because of how the PRECIS string classes are defined,
691 only changes that would result in code points being added to or
692 removed from the LetterDigits ("A") category would result in
693 backward-incompatible modifications to code point assignments.
694 Therefore, management of this category is handled via the processes
695 specified in [RFC5892].
697 G: cp is in {}
698 This category includes the code points for which property values in
699 versions of Unicode after 5.2 have changed in such a way that the
700 derived property value would no longer be PVALID or DISALLOWED. If
701 changes are made to future versions of Unicode so that code points
702 might change property value from PVALID or DISALLOWED, then this
703 table can be updated and keep special exception values so that the
704 property values for code points stay stable.
706 6.8. JoinControl (H)
708 NOTE: This category is defined in [RFC5892] and copied here for use
709 in PRECIS.
711 H: Join_Control(cp) = True
713 This category consists of Join Control characters (i.e., they are not
714 in LetterDigits (Section 6.1)) but are still required in strings
715 under some circumstances.
717 6.9. OldHangulJamo (I)
719 NOTE: This category is defined in [RFC5892] and copied here for use
720 in PRECIS.
722 I: Hangul_Syllable_Type(cp) is in {L, V, T}
724 This category consists of all conjoining Hangul Jamo (Leading Jamo,
725 Vowel Jamo, and Trailing Jamo).
727 Elimination of conjoining Hangul Jamos from the set of PVALID
728 characters results in restricting the set of Korean PVALID characters
729 just to preformed, modern Hangul syllable characters. Old Hangul
730 syllables, which must be spelled with sequences of conjoining Hangul
731 Jamos, are not PVALID for string classes.
733 6.10. Unassigned (J)
735 NOTE: This category is defined in [RFC5892] and copied here for use
736 in PRECIS.
738 J: General_Category(cp) is in {Cn} and
739 Noncharacter_Code_Point(cp) = False
741 This category consists of code points in the Unicode character set
742 that are not (yet) assigned. It should be noted that Unicode
743 distinguishes between 'unassigned code points' and 'unassigned
744 characters'. The unassigned code points are all but (Cn -
745 Noncharacters), while the unassigned *characters* are all but (Cn +
746 Cs).
748 6.11. ASCII7 (K)
750 This PRECIS-specific category exempts most characters in the ASCII-7
751 range from other rules that might be applied during PRECIS
752 processing, on the assumption that these code points are in such wide
753 use that disallowing them would be counter-productive.
755 K: cp is in {0021..007E}
757 6.12. Controls (L)
759 L: Control(cp) = True
761 6.13. PrecisIgnorableProperties (M)
763 This PRECIS-specific category is used to group code points that are
764 not recommended for use in PRECIS string classes.
766 M: Default_Ignorable_Code_Point(cp) = True or
767 Noncharacter_Code_Point(cp) = True
769 The definition for Default_Ignorable_Code_Point can be found in the
770 DerivedCoreProperties.txt [2] file, and at the time of Unicode 6.0 is
771 as follows:
773 Other_Default_Ignorable_Code_Point
774 + Cf (Format characters)
775 + Variation_Selector
776 - White_Space
777 - FFF9..FFFB (Annotation Characters)
778 - 0600..0603, 06DD, 070F (exceptional Cf characters
779 that should be visible)
781 6.14. Spaces (N)
783 This PRECIS-specific category is used to group code points that are
784 space characters.
786 N: General_Category(cp) is in {Zs}
788 6.15. Symbols (O)
790 This PRECIS-specific category is used to group code points that are
791 symbols.
793 O: General_Category(cp) is in {Sc}
795 6.16. Punctuation (P)
797 This PRECIS-specific category is used to group code points that are
798 punctuation marks.
800 P: General_Category(cp) is in {Pi}
802 6.17. HasCompat (Q)
804 This PRECIS-specific category is used to group code points that have
805 compatibility equivalents as explained in Chapter 2 and Chapter 3 of
806 [UNICODE].
808 Q: toNFKC(cp) != cp
810 The toNFKC() operation returns the code point in normalization form
811 KC. For more information, see Section 5 of [UAX15].
813 7. Calculation of the Derived Property
815 Possible values of the derived property are:
817 o PVALID
818 o NAMECLASS_VALID
819 o SECRETCLASS_VALID
820 o FREECLASS_VALID
821 o CONTEXTJ
822 o CONTEXTO
823 o DISALLOWED
824 o NAMECLASS_DISALLOWED
825 o SECRETCLASS_DISALLOWED
826 o FREECLASS_DISALLOWED
827 o UNASSIGNED
829 NOTE: In some instances, the value of the derived property calculated
830 depends on the string class (e.g., if an identifier used in an
831 application protocol is defined as using or subclassing the PRECIS
832 NameClass, then a space character would be assigned to
833 NAMECLASS_DISALLOWED).
835 The algorithm to calculate the value of the derived property is as
836 follows. (NOTE: Use of the name of a rule (such as "Exception")
837 implies the set of code points that the rule defines, whereas the
838 same name as a function call (such as "Exception(cp)") implies the
839 value that the code point has in the Exceptions table.)
840 If .cp. .in. Exceptions Then Exceptions(cp);
841 Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp);
842 Else If .cp. .in. Unassigned Then UNASSIGNED;
843 Else If .cp. .in. ASCII7 Then PVALID;
844 Else If .cp. .in. JoinControl Then CONTEXTJ;
845 Else If .cp. .in. PrecisIgnorableProperties Then DISALLOWED;
846 Else If .cp. .in. Controls Then DISALLOWED;
847 Else If .cp. .in. OldHangulJamo Then DISALLOWED;
848 Else If .cp. .in. LetterDigits Then PVALID;
849 Else If .cp. .in. Spaces Then NAMECLASS_DISALLOWED
850 or SECRETCLASS_DISALLOWED
851 or FREECLASS_VALID;
852 Else If .cp. .in. Symbols Then NAMECLASS_DISALLOWED
853 or SECRETCLASS_DISALLOWED
854 or FREECLASS_VALID;
855 Else If .cp. .in. Punctuation Then NAMECLASS_DISALLOWED
856 or SECRETCLASS_DISALLOWED
857 or FREECLASS_VALID;
858 Else If .cp. .in. HasCompat Then NAMECLASS_DISALLOWED
859 or SECRETCLASS_VALID
860 or FREECLASS_VALID;
861 Else DISALLOWED;
863 8. Code Points
865 The Categories and Rules defined in Section 6 and Section 7 apply to
866 all Unicode code points. The table in Section 12 shows, for
867 illustrative purposes, the consequences of the categories and
868 classification rules, and the resulting property values.
870 The list of code points that can be found in Section 12 is non-
871 normative. Instead, the rules defined by Section 6 and Section 7 are
872 normative, and any tables are derived from the rules.
874 9. IANA Considerations
876 9.1. PRECIS Derived Property Value Registry
878 IANA is requested to create a PRECIS-specific registry with the
879 Derived Properties for the versions of Unicode that are released
880 after (and including) version 6.0. The derived property value is to
881 be calculated in cooperation with a designated expert [RFC5226]
882 according to the specifications in Section 6 and Section 7, and not
883 by copying the non-normative table found in Section 12.
885 If during this process (creation of the table of derived property
886 values) followed by a designated expert review, either backward-
887 incompatible changes to the table of derived properties are
888 discovered, or otherwise problems during the creation of the table
889 arises, that is to be flagged to the IESG. Changes to the rules (as
890 specified in Section 6 and Section 7) require IETF Review, as
891 described in [RFC5226].
893 9.2. PRECIS Usage Registry
895 IANA is requested to create a registry of application protocols that
896 use the base string classes. The registry will include one entry for
897 each use (e.g., if a protocol uses both the NameClass and the
898 FreeClass then the specification for that protocol would submit two
899 registrations). In accordance with [RFC5226], the registration
900 policy is "First Come First Served".
902 The registration template is as follows:
904 Application Protocol: [the application protocol that is using or
905 subclassing the PRECIS string class]
906 Base Class: [which base class is being used]
907 Subclassing: [whether the base class is being subclassed and, if so,
908 where documentation of the subclassing can be found]
909 Directionality: [the behavioral rule for handling of right-to-left
910 code points]
911 Casemapping: [the behavioral rule for handling of case]
912 Normalization: [which Unicode normalization form is applied]
913 Specification: [a pointer to relevant documentation, such as an RFC
914 or Internet-Draft]
916 10. Security Considerations
918 10.1. General Issues
920 The security of applications that use this framework can depend in
921 part on the proper preparation and comparison of internationalized
922 strings. For example, such strings can be used to make
923 authentication and authorization decisions, and the security of an
924 application could be compromised if an entity providing a given
925 string is connected to the wrong account or online resource based on
926 different interpretations of the string.
928 Specifications of application protocols that use this framework are
929 encouraged to describe how internationalized strings are used in the
930 protocol, including the security implications of any false positives
931 and false negatives that might result from various comparison
932 operations. For some helpful guidelines, refer to [IDENTIFIER],
934 [RFC5890], [UTR36], and [UTR39].
936 10.2. Local Character Set Issues
938 When systems use local character sets other than ASCII and Unicode,
939 these specifications leave the problem of converting between the
940 local character set and Unicode up to the application or local
941 system. If different applications (or different versions of one
942 application) implement different rules for conversions among coded
943 character sets, they could interpret the same name differently and
944 contact different application servers or other network entities.
945 This problem is not solved by security protocols, such as Transport
946 Layer Security (TLS) [RFC5246] and the Simple Authentication and
947 Security Layer (SASL) [RFC4422], that do not take local character
948 sets into account.
950 10.3. Visually Similar Characters
952 Some characters are visually similar and thus can cause confusion
953 among humans. Such characters are often called "confusable
954 characters" or "confusables".
956 The problem of confusable characters is not necessarily caused by the
957 use of Unicode code points outside the US-ASCII range. For example,
958 in some presentations and to some individuals the string "ju1iet"
959 (spelled with the Arabic numeral one as the third character) might
960 appear to be the same as "juliet" (spelled with the lowercase version
961 of the letter "L"), especially on casual visual inspection. This
962 phenomenon is sometimes called "typejacking".
964 However, the problem is made more serious by introducing the full
965 range of Unicode code points into protocol strings. For example, the
966 characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the
967 Cherokee block look similar to the US-ASCII characters "STPETER" as
968 they might look when presented in a "creative" font.
970 In some examples of confusable characters, it is unlikely that the
971 average human could tell the difference between the real string and
972 the fake string. (Indeed, there is no programmatic way to
973 distinguish with full certainty which is the fake string and which is
974 the real string; in some contexts, the string formed of Cherokee
975 characters might be the real string and the string formed of US-ASCII
976 characters might be the fake string.) Because PRECIS-compliant
977 strings can contain almost any properly encoded Unicode code point,
978 it can be relatively easy to fake or mimic some strings in systems
979 that use the PRECIS framework. The fact that some strings are easily
980 confused introduces security vulnerabilities of the kind that have
981 also plagued the World Wide Web, specifically the phenomenon known as
982 phishing.
984 Despite the fact that some specific suggestions about identification
985 and handling of confusable characters appear in the Unicode Security
986 Considerations [UTR36], it is also true (as noted in [RFC5890]) that
987 "there are no comprehensive technical solutions to the problems of
988 confusable characters". Because it is impossible to map visually
989 similar characters without a great deal of context (such as knowing
990 the fonts used), the PRECIS framework does nothing to map similar-
991 looking characters together, nor does it prohibit some characters
992 because they look like others.
994 However, specifications for application protocols that use this
995 framework MUST describe how confusable characters can be used to
996 compromise the security of systems that use the protocol in question,
997 and any protocol-specific suggestions for overcoming those threats.
998 In particular, software implementations and service deployments that
999 use PRECIS-based technologies are strongly encouraged to define and
1000 implement consistent policies regarding the registration, storage,
1001 and presentation of visually similar characters. The following
1002 recommendations are appropriate:
1004 1. An application service SHOULD define a policy that specifies the
1005 scripts or blocks of characters that the service will allow to be
1006 registered (e.g., in an account name) or stored (e.g., in a file
1007 name). Such a policy SHOULD be informed by the languages and
1008 scripts that are used to write registered account names; in
1009 particular, to reduce confusion, the service SHOULD forbid
1010 registration or storage of stings that contain characters from
1011 more than one script and to restrict registrations to characters
1012 drawn from a very small number of scripts (e.g., scripts that are
1013 well-understood by the administrators of the service, to improve
1014 manageability).
1016 2. User-oriented application software SHOULD define a policy that
1017 specifies how internationalized strings will be presented to a
1018 human user. Because every human user of such software has a
1019 preferred language or a small set of preferred languages, the
1020 software SHOULD gather that information either explicitly from
1021 the user or implicitly via the operating system of the user's
1022 device. Furthermore, because most languages are typically
1023 represented by a single script or a small set of scripts, and
1024 because and most scripts are typically contained in one or more
1025 blocks of characters, the software SHOULD warn the user when
1026 presenting a string that mixes characters from more than one
1027 script or block, or that uses characters outside the normal range
1028 of the user's preferred language(s). (Such a recommendation is
1029 not intended to discourage communication across different
1030 communities of language users; instead, it recognizes the
1031 existence of such communities and encourages due caution when
1032 presenting unfamiliar scripts or characters to human users.)
1034 10.4. Security of the SecretClass
1036 One goal of passwords and passphrases is to maximize the amount of
1037 entropy, for example by allowing a wide range of code points and by
1038 ensuring that secrets are not prepared in such a way that code points
1039 are compared aggressively. Therefore, it is NOT RECOMMENDED for
1040 application protocols to subclass the SecretClass in a way that
1041 removes entire categories (e.g., by disallowing symbols or
1042 punctuation). Furthermore, it is NOT RECOMMENDED for application
1043 protocols to map uppercase and titlecase code points to their
1044 lowercase equivalents; instead, it is RECOMMENDED to preserve the
1045 case of all code points contained in string that conform to or
1046 subclass the SecretClass.
1048 That said, software implementers need to be aware that there exist
1049 tradeoffs between entropy and usability. For example, allowing a
1050 user to establish a password containing "uncommon" code points might
1051 make it difficult for the user to access an application when using an
1052 unfamiliar or constrained input device.
1054 Some application protocols use passwords and passphrases directly,
1055 whereas others reuse technologies that themselves process passwords
1056 (one example is the Simple Authentication and Security Layer
1057 [RFC4422]). Moreover, passwords are often carried by a sequence of
1058 protocols with backends authentication systems or data storage
1059 systems such as RADIUS [RFC2865] and LDAP [RFC4510]. Developers of
1060 application protocols are encouraged to look into reusing these
1061 profiles instead of defining new ones, so that end-user expectations
1062 about passwords are consistent no matter which application protocol
1063 is used.
1065 11. Acknowledgements
1067 The authors would like to acknowledge the comments and contributions
1068 of the following individuals: David Black, Mark Davis, Alan DeKok,
1069 Martin Duerst, Patrik Faltstrom, Ted Hardie, Joe Hildebrand, Paul
1070 Hoffman, Jeffrey Hutzelman, Simon Josefsson, John Klensin, Alexey
1071 Melnikov, Pete Resnick, Andrew Sullivan, and Dave Thaler.
1073 Some algorithms and textual descriptions have been borrowed from
1074 [RFC5892]. Some text regarding security has been borrowed from
1075 [RFC5890] and [XMPP-ADDR].
1077 12. Codepoints 0x0000 - 0x10FFFF
1079 To follow.
1081 12.1. Codepoints in Unicode Character Database (UCD) format
1083 To follow.
1085 13. References
1087 13.1. Normative References
1089 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1090 Requirement Levels", BCP 14, RFC 2119, March 1997.
1092 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
1093 Interchange", RFC 5198, March 2008.
1095 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
1096 6.0", 2010,
1097 .
1099 13.2. Informative References
1101 [I18N-TERMS]
1102 Hoffman, P. and J. Klensin, "Terminology Used in
1103 Internationalization in the IETF",
1104 draft-ietf-appsawg-rfc3536bis-06 (work in progress),
1105 July 2011.
1107 [IDENTIFIER]
1108 Thaler, D., "Issues in Identifier Comparison for Security
1109 Purposes", draft-iab-identifier-comparison-00 (work in
1110 progress), July 2011.
1112 [PROBLEM] Blanchet, M. and A. Sullivan, "Stringprep Revision Problem
1113 Statement", draft-ietf-precis-problem-statement-03 (work
1114 in progress), July 2011.
1116 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1117 "Remote Authentication Dial In User Service (RADIUS)",
1118 RFC 2865, June 2000.
1120 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
1121 Internationalized Strings ("stringprep")", RFC 3454,
1122 December 2002.
1124 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
1125 "Internationalizing Domain Names in Applications (IDNA)",
1126 RFC 3490, March 2003.
1128 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
1129 Security Layer (SASL)", RFC 4422, June 2006.
1131 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
1132 (LDAP): Technical Specification Road Map", RFC 4510,
1133 June 2006.
1135 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
1136 Recommendations for Internationalized Domain Names
1137 (IDNs)", RFC 4690, September 2006.
1139 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1140 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1141 May 2008.
1143 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1144 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1146 [RFC5890] Klensin, J., "Internationalized Domain Names for
1147 Applications (IDNA): Definitions and Document Framework",
1148 RFC 5890, August 2010.
1150 [RFC5891] Klensin, J., "Internationalized Domain Names in
1151 Applications (IDNA): Protocol", RFC 5891, August 2010.
1153 [RFC5892] Faltstrom, P., "The Unicode Code Points and
1154 Internationalized Domain Names for Applications (IDNA)",
1155 RFC 5892, August 2010.
1157 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for
1158 Internationalized Domain Names for Applications (IDNA)",
1159 RFC 5893, August 2010.
1161 [RFC5894] Klensin, J., "Internationalized Domain Names for
1162 Applications (IDNA): Background, Explanation, and
1163 Rationale", RFC 5894, August 2010.
1165 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
1166 Internationalized Domain Names in Applications (IDNA)
1167 2008", RFC 5895, September 2010.
1169 [UAX15] The Unicode Consortium, "Unicode Standard Annex #15:
1170 Unicode Normalization Forms", September 2010,
1171 .
1173 [UAX9] The Unicode Consortium, "Unicode Standard Annex #9:
1174 Unicode Bidirectional Algorithm", September 2010,
1175 .
1177 [UTR36] The Unicode Consortium, "Unicode Technical Report #36:
1178 Unicode Security Considerations", August 2010,
1179 .
1181 [UTR39] The Unicode Consortium, "Unicode Technical Report #39:
1182 Unicode Security Mechanisms", August 2010,
1183 .
1185 [XMPP-ADDR]
1186 Saint-Andre, P., "Extensible Messaging and Presence
1187 Protocol (XMPP): Address Format",
1188 draft-saintandre-xmpp-6122bis-01 (work in progress),
1189 July 2011.
1191 URIs
1193 [1]
1195 [2]
1197 Authors' Addresses
1199 Marc Blanchet
1200 Viagenie
1201 2600 boul. Laurier, suite 625
1202 Quebec, QC G1V 4W1
1203 Canada
1205 Email: Marc.Blanchet@viagenie.ca
1206 URI: http://www.viagenie.ca/
1208 Peter Saint-Andre
1209 Cisco
1210 1899 Wyknoop Street, Suite 600
1211 Denver, CO 80202
1212 USA
1214 Phone: +1-303-308-3282
1215 Email: psaintan@cisco.com