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