idnits 2.17.1 draft-ietf-precis-7564bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2017) is 2587 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1894 -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Obsolete informational reference (is this intentional?): RFC 7564 (ref. 'Err4568') (Obsoleted by RFC 8264) == Outdated reference: A later version (-05) exists of draft-klensin-idna-5892upd-unicode70-04 -- 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 3491 (Obsoleted by 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) -- Duplicate reference: RFC7564, mentioned in 'RFC7564', was also mentioned in 'Err4568'. -- Obsolete informational reference (is this intentional?): RFC 7564 (Obsoleted by RFC 8264) -- Obsolete informational reference (is this intentional?): RFC 7613 (Obsoleted by RFC 8265) -- Obsolete informational reference (is this intentional?): RFC 7700 (Obsoleted by RFC 8266) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Filament 4 Obsoletes: 7564 (if approved) M. Blanchet 5 Intended status: Standards Track Viagenie 6 Expires: September 28, 2017 March 27, 2017 8 PRECIS Framework: Preparation, Enforcement, and Comparison of 9 Internationalized Strings in Application Protocols 10 draft-ietf-precis-7564bis-06 12 Abstract 14 Application protocols using Unicode code points in protocol strings 15 need to properly handle such strings in order to enforce 16 internationalization rules for strings placed in various protocol 17 slots (such as addresses and identifiers) and to perform valid 18 comparison operations (e.g., for purposes of authentication or 19 authorization). This document defines a framework enabling 20 application protocols to perform the preparation, enforcement, and 21 comparison of internationalized strings ("PRECIS") in a way that 22 depends on the properties of Unicode code points and thus is more 23 agile with respect to versions of Unicode. As a result, this 24 framework provides a more sustainable approach to the handling of 25 internationalized strings than the previous framework, known as 26 Stringprep (RFC 3454). This document obsoletes RFC 7564. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 28, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Preparation, Enforcement, and Comparison . . . . . . . . . . 7 65 4. String Classes . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. IdentifierClass . . . . . . . . . . . . . . . . . . . . . 9 68 4.2.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.2.2. Contextual Rule Required . . . . . . . . . . . . . . 10 70 4.2.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 10 71 4.2.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 11 72 4.2.5. Examples . . . . . . . . . . . . . . . . . . . . . . 11 73 4.3. FreeformClass . . . . . . . . . . . . . . . . . . . . . . 11 74 4.3.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.3.2. Contextual Rule Required . . . . . . . . . . . . . . 12 76 4.3.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 12 77 4.3.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 12 78 4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12 79 5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1. Profiles Must Not Be Multiplied beyond Necessity . . . . 13 81 5.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 5.2.1. Width Mapping Rule . . . . . . . . . . . . . . . . . 14 83 5.2.2. Additional Mapping Rule . . . . . . . . . . . . . . . 14 84 5.2.3. Case Mapping Rule . . . . . . . . . . . . . . . . . . 15 85 5.2.4. Normalization Rule . . . . . . . . . . . . . . . . . 15 86 5.2.5. Directionality Rule . . . . . . . . . . . . . . . . . 16 87 5.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 17 88 6. Applications . . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.1. How to Use PRECIS in Applications . . . . . . . . . . . . 17 90 6.2. Further Excluded Characters . . . . . . . . . . . . . . . 19 91 6.3. Building Application-Layer Constructs . . . . . . . . . . 19 92 7. Order of Operations . . . . . . . . . . . . . . . . . . . . . 20 93 8. Code Point Properties . . . . . . . . . . . . . . . . . . . . 20 94 9. Category Definitions Used to Calculate Derived Property . . . 23 95 9.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . 24 96 9.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . 24 97 9.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 24 98 9.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 24 99 9.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 9.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . 24 101 9.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . 24 102 9.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 25 103 9.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 25 104 9.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 25 105 9.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 25 106 9.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 25 107 9.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 25 108 9.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 25 109 9.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 26 110 9.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 26 111 9.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 26 112 9.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 26 113 10. Guidelines for Designated Experts . . . . . . . . . . . . . . 26 114 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 115 11.1. PRECIS Derived Property Value Registry . . . . . . . . . 27 116 11.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 28 117 11.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 28 118 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 119 12.1. General Issues . . . . . . . . . . . . . . . . . . . . . 30 120 12.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 31 121 12.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 31 122 12.4. Local Character Set Issues . . . . . . . . . . . . . . . 31 123 12.5. Visually Similar Characters . . . . . . . . . . . . . . 32 124 12.6. Security of Passwords . . . . . . . . . . . . . . . . . 34 125 13. Interoperability Considerations . . . . . . . . . . . . . . . 34 126 13.1. Coded Character Sets . . . . . . . . . . . . . . . . . . 34 127 13.2. Dependency on Unicode . . . . . . . . . . . . . . . . . 35 128 13.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 35 129 13.4. Unicode Versions . . . . . . . . . . . . . . . . . . . . 35 130 13.5. Potential Changes to Handling of Certain Unicode Code 131 Points . . . . . . . . . . . . . . . . . . . . . . . . . 36 132 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 133 14.1. Normative References . . . . . . . . . . . . . . . . . . 36 134 14.2. Informative References . . . . . . . . . . . . . . . . . 37 135 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 41 136 Appendix A. Changes from RFC 7564 . . . . . . . . . . . . . . . 42 137 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42 139 1. Introduction 141 Application protocols using Unicode code points [Unicode] in protocol 142 strings need to properly handle such strings in order to enforce 143 internationalization rules for strings placed in various protocol 144 slots (such as addresses and identifiers) and to perform valid 145 comparison operations (e.g., for purposes of authentication or 146 authorization). This document defines a framework enabling 147 application protocols to perform the preparation, enforcement, and 148 comparison of internationalized strings ("PRECIS") in a way that 149 depends on the properties of Unicode code points and thus is more 150 agile with respect to versions of Unicode. 152 As described in the PRECIS problem statement [RFC6885], many IETF 153 protocols have used the Stringprep framework [RFC3454] as the basis 154 for preparing, enforcing, and comparing protocol strings that contain 155 Unicode code points, especially code points outside the ASCII range 156 [RFC20]. The Stringprep framework was developed during work on the 157 original technology for internationalized domain names (IDNs), here 158 called "IDNA2003" [RFC3490], and Nameprep [RFC3491] was the 159 Stringprep profile for IDNs. At the time, Stringprep was designed as 160 a general framework so that other application protocols could define 161 their own Stringprep profiles. Indeed, a number of application 162 protocols defined such profiles. 164 After the publication of [RFC3454] in 2002, several significant 165 issues arose with the use of Stringprep in the IDN case, as 166 documented in the IAB's recommendations regarding IDNs [RFC4690] 167 (most significantly, Stringprep was tied to Unicode version 3.2). 168 Therefore, the newer IDNA specifications, here called "IDNA2008" 169 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894]), no longer 170 use Stringprep and Nameprep. This migration away from Stringprep for 171 IDNs prompted other "customers" of Stringprep to consider new 172 approaches to the preparation, enforcement, and comparison of 173 internationalized strings, as described in [RFC6885]. 175 This document defines a framework for a post-Stringprep approach to 176 the preparation, enforcement, and comparison of internationalized 177 strings in application protocols, based on several principles: 179 1. Define a small set of string classes that specify the Unicode 180 code points appropriate for common application protocol 181 constructs. 183 2. Define each PRECIS string class in terms of Unicode code points 184 and their properties so that an algorithm can be used to 185 determine whether each code point or character category is 186 (a) valid, (b) allowed in certain contexts, (c) disallowed, or 187 (d) unassigned. 189 3. Use an "inclusion model" such that a string class consists only 190 of code points that are explicitly allowed, with the result that 191 any code point not explicitly allowed is forbidden. 193 4. Enable application protocols to define profiles of the PRECIS 194 string classes if necessary (addressing matters such as width 195 mapping, case mapping, Unicode normalization, and directionality) 196 but strongly discourage the multiplication of profiles beyond 197 necessity in order to avoid violations of the "Principle of Least 198 Astonishment". 200 It is expected that this framework will yield the following benefits: 202 o Application protocols will be more agile with regard to Unicode 203 versions (recognizing that complete agility cannot be realized in 204 practice). 206 o Implementers will be able to share code point tables and software 207 code across application protocols, most likely by means of 208 software libraries. 210 o End users will be able to acquire more accurate expectations about 211 the code points that are acceptable in various contexts. Given 212 this more uniform set of string classes, it is also expected that 213 copy/paste operations between software implementing different 214 application protocols will be more predictable and coherent. 216 Whereas the string classes define the "baseline" code points for a 217 range of applications, profiling enables application protocols to 218 apply the string classes in ways that are appropriate for common 219 constructs such as usernames [RFC7613], opaque strings such as 220 passwords [RFC7613], and nicknames [RFC7700]. Profiles are 221 responsible for defining the handling of right-to-left code points as 222 well as various mapping operations of the kind also discussed for 223 IDNs in [RFC5895], such as case preservation or lowercasing, Unicode 224 normalization, mapping of certain code points to other code points or 225 to nothing, and mapping of fullwidth and halfwidth code points. 227 When an application applies a profile of a PRECIS string class, it 228 transforms an input string (which might or might not be conforming) 229 into an output string that definitively conforms to the profile. In 230 particular, this document focuses on the resulting ability to achieve 231 the following objectives: 233 a. Enforcing all the rules of a profile for a single output string 234 (e.g., to determine if a string can be included in a protocol 235 slot, communicated to another entity within a protocol, stored in 236 a retrieval system, etc.) to check whether the output string 237 conforms to the rules of the profile. 239 b. Comparing two output strings to determine if they are equivalent, 240 typically through octet-for-octet matching to test for 241 "bit-string identity" (e.g., to make an access decision for 242 purposes of authentication or authorization as further described 243 in [RFC6943]). 245 The opportunity to define profiles naturally introduces the 246 possibility of a proliferation of profiles, thus potentially 247 mitigating the benefits of common code and violating user 248 expectations. See Section 5 for a discussion of this important 249 topic. 251 In addition, it is extremely important for protocol designers and 252 application developers to understand that the transformation of an 253 input string to an output string is rarely reversible. As one 254 relatively simple example, case mapping would transform an input 255 string of "StPeter" to "stpeter", and information about the 256 capitalization of the first and third characters would be lost. 257 Similar considerations apply to other forms of mapping and 258 normalization. 260 Although this framework is similar to IDNA2008 and includes by 261 reference some of the character categories defined in [RFC5892], it 262 defines additional character categories to meet the needs of common 263 application protocols other than DNS. 265 The character categories and calculation rules defined under 266 Sections 8 and 9 are normative and apply to all Unicode code points. 267 The code point table that results from applying the character 268 categories and calculation rules to the latest version of Unicode can 269 be found in an IANA registry. 271 2. Terminology 273 Many important terms used in this document are defined in [RFC5890], 274 [RFC6365], [RFC6885], and [Unicode]. The terms "left-to-right" (LTR) 275 and "right-to-left" (RTL) are defined in Unicode Standard Annex #9 276 [UAX9]. 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 280 "OPTIONAL" in this document are to be interpreted as described in 281 [RFC2119]. 283 3. Preparation, Enforcement, and Comparison 285 This document distinguishes between three different actions that an 286 entity can take with regard to a string: 288 o Enforcement entails applying all of the rules specified for a 289 particular string class or profile thereof to an individual 290 string, for the purpose of checking whether the string conforms to 291 all of the rules and thus determining if the string can be used in 292 a given protocol slot. 294 o Comparison entails applying all of the rules specified for a 295 particular string class or profile thereof to two separate 296 strings, for the purpose of determining if the two strings are 297 equivalent. 299 o Preparation primarily entails ensuring that the code points in an 300 individual string are allowed by the underlying PRECIS string 301 class, and sometimes also entails applying one or more of the 302 rules specified for a particular string class or profile thereof. 303 Preparation can be appropriate for constrained devices that can to 304 some extent restrict the code points in a string to a limited 305 repertoire of characters but that do not have the processing power 306 or onboard memory to perform operations such as Unicode 307 normalization. However, preparation does not ensure that an input 308 string conforms to all of the rules for a string class or profile 309 thereof. 311 Note: The term "preparation" as used in this specification and 312 related documents has a much more limited scope than it did in 313 Stringprep; it essentially refers to a kind of preprocessing of 314 an input string, not the actual operations that apply 315 internationalization rules to produce an output string (here 316 termed "enforcement") or to compare two output strings (here 317 termed "comparison"). 319 In most cases, authoritative entities such as servers are responsible 320 for enforcement, whereas subsidiary entities such as clients are 321 responsible only for preparation. The rationale for this distinction 322 is that clients might not have the facilities (in terms of device 323 memory and processing power) to enforce all the rules regarding 324 internationalized strings (such as width mapping and Unicode 325 normalization), although they can more easily limit the repertoire of 326 characters they offer to an end user. By contrast, it is assumed 327 that a server would have more capacity to enforce the rules, and in 328 any case acts as an authority regarding allowable strings in protocol 329 slots such as addresses and endpoint identifiers. In addition, a 330 client cannot necessarily be trusted to properly generate such 331 strings, especially for security-sensitive contexts such as 332 authentication and authorization. 334 4. String Classes 336 4.1. Overview 338 Starting in 2010, various "customers" of Stringprep began to discuss 339 the need to define a post-Stringprep approach to the preparation and 340 comparison of internationalized strings other than IDNs. This 341 community analyzed the existing Stringprep profiles and also weighed 342 the costs and benefits of defining a relatively small set of Unicode 343 code points that would minimize the potential for user confusion 344 caused by visually similar code points (and thus be relatively 345 "safe") vs. defining a much larger set of Unicode code points that 346 would maximize the potential for user creativity (and thus be 347 relatively "expressive"). As a result, the community concluded that 348 most existing uses could be addressed by two string classes: 350 IdentifierClass: a sequence of letters, numbers, and some symbols 351 that is used to identify or address a network entity such as a 352 user account, a venue (e.g., a chatroom), an information source 353 (e.g., a data feed), or a collection of data (e.g., a file); the 354 intent is that this class will minimize user confusion in a wide 355 variety of application protocols, with the result that safety has 356 been prioritized over expressiveness for this class. 358 FreeformClass: a sequence of letters, numbers, symbols, spaces, and 359 other code points that is used for free-form strings, including 360 passwords as well as display elements such as human-friendly 361 nicknames for devices or for participants in a chatroom; the 362 intent is that this class will allow nearly any Unicode code 363 point, with the result that expressiveness has been prioritized 364 over safety for this class. Note well that protocol designers, 365 application developers, service providers, and end users might not 366 understand or be able to enter all of the code points that can be 367 included in the FreeformClass -- see Section 12.3 for details. 369 Future specifications might define additional PRECIS string classes, 370 such as a class that falls somewhere between the IdentifierClass and 371 the FreeformClass. At this time, it is not clear how useful such a 372 class would be. In any case, because application developers are able 373 to define profiles of PRECIS string classes, a protocol needing a 374 construct between the IdentifierClass and the FreeformClass could 375 define a restricted profile of the FreeformClass if needed. 377 The following subsections discuss the IdentifierClass and 378 FreeformClass in more detail, with reference to the dimensions 379 described in Section 5 of [RFC6885]. Each string class is defined by 380 the following behavioral rules: 382 Valid: Defines which code points are treated as valid for the 383 string. 385 Contextual Rule Required: Defines which code points are treated as 386 allowed only if the requirements of a contextual rule are met 387 (i.e., either CONTEXTJ or CONTEXTO). 389 Disallowed: Defines which code points need to be excluded from the 390 string. 392 Unassigned: Defines application behavior in the presence of code 393 points that are unknown (i.e., not yet designated) for the version 394 of Unicode used by the application. 396 This document defines the valid, contextual rule required, 397 disallowed, and unassigned rules for the IdentifierClass and 398 FreeformClass. As described under Section 5, profiles of these 399 string classes are responsible for defining the width mapping, 400 additional mappings, case mapping, normalization, and directionality 401 rules. 403 4.2. IdentifierClass 405 Most application technologies need strings that can be used to refer 406 to, include, or communicate protocol strings like usernames, 407 filenames, data feed identifiers, and chatroom names. We group such 408 strings into a class called "IdentifierClass" having the following 409 features. 411 4.2.1. Valid 413 o Code points traditionally used as letters and numbers in writing 414 systems, i.e., the LetterDigits ("A") category first defined in 415 [RFC5892] and listed here under Section 9.1. 417 o Code points in the range U+0021 through U+007E, i.e., the 418 (printable) ASCII7 ("K") category defined under Section 9.11. 419 These code points are "grandfathered" into PRECIS and thus are 420 valid even if they would otherwise be disallowed according to the 421 property-based rules specified in the next section. 423 Note: Although the PRECIS IdentifierClass reuses the LetterDigits 424 category from IDNA2008, the range of code points allowed in the 425 IdentifierClass is wider than the range of code points allowed in 426 IDNA2008. The main reason is that IDNA2008 applies the Unstable 427 category before the LetterDigits category, thus disallowing 428 uppercase code points, whereas the IdentifierClass does not apply 429 the Unstable category. 431 4.2.2. Contextual Rule Required 433 o A number of code points from the Exceptions ("F") category defined 434 under Section 9.6 (see Section 9.6 for a full list). 436 o Joining code points, i.e., the JoinControl ("H") category defined 437 under Section 9.8. 439 4.2.3. Disallowed 441 o Old Hangul Jamo code points, i.e., the OldHangulJamo ("I") 442 category defined under Section 9.9. 444 o Control code points, i.e., the Controls ("L") category defined 445 under Section 9.12. 447 o Ignorable code points, i.e., the PrecisIgnorableProperties ("M") 448 category defined under Section 9.13. 450 o Space code points, i.e., the Spaces ("N") category defined under 451 Section 9.14. 453 o Symbol code points, i.e., the Symbols ("O") category defined under 454 Section 9.15. 456 o Punctuation code points, i.e., the Punctuation ("P") category 457 defined under Section 9.16. 459 o Any code point that is decomposed and recomposed into something 460 other than itself under Unicode normalization form KC, i.e., the 461 HasCompat ("Q") category defined under Section 9.17. These code 462 points are disallowed even if they would otherwise be valid 463 according to the property-based rules specified in the previous 464 section. 466 o Letters and digits other than the "traditional" letters and digits 467 allowed in IDNs, i.e., the OtherLetterDigits ("R") category 468 defined under Section 9.18. 470 4.2.4. Unassigned 472 Any code points that are not yet designated in the Unicode coded 473 character set are considered unassigned for purposes of the 474 IdentifierClass, and such code points are to be treated as 475 disallowed. See Section 9.10. 477 4.2.5. Examples 479 As described in the Introduction to this document, the string classes 480 do not handle all issues related to string preparation and comparison 481 (such as case mapping); instead, such issues are handled at the level 482 of profiles. Examples for profiles of the IdentifierClass can be 483 found in [RFC7613] (the UsernameCaseMapped and UsernameCasePreserved 484 profiles). 486 4.3. FreeformClass 488 Some application technologies need strings that can be used in a 489 free-form way, e.g., as a password in an authentication exchange (see 490 [RFC7613]) or a nickname in a chatroom (see [RFC7700]). We group 491 such things into a class called "FreeformClass" having the following 492 features. 494 Security Warning: As mentioned, the FreeformClass prioritizes 495 expressiveness over safety; Section 12.3 describes some of the 496 security hazards involved with using or profiling the 497 FreeformClass. 499 Security Warning: Consult Section 12.6 for relevant security 500 considerations when strings conforming to the FreeformClass, or a 501 profile thereof, are used as passwords. 503 4.3.1. Valid 505 o Traditional letters and numbers, i.e., the LetterDigits ("A") 506 category first defined in [RFC5892] and listed here under 507 Section 9.1. 509 o Letters and digits other than the "traditional" letters and digits 510 allowed in IDNs, i.e., the OtherLetterDigits ("R") category 511 defined under Section 9.18. 513 o Code points in the range U+0021 through U+007E, i.e., the 514 (printable) ASCII7 ("K") category defined under Section 9.11. 516 o Any code point that is decomposed and recomposed into something 517 other than itself under Unicode normalization form KC, i.e., the 518 HasCompat ("Q") category defined under Section 9.17. 520 o Space code points, i.e., the Spaces ("N") category defined under 521 Section 9.14. 523 o Symbol code points, i.e., the Symbols ("O") category defined under 524 Section 9.15. 526 o Punctuation code points, i.e., the Punctuation ("P") category 527 defined under Section 9.16. 529 4.3.2. Contextual Rule Required 531 o A number of code points from the Exceptions ("F") category defined 532 under Section 9.6 (see Section 9.6 for a full list). 534 o Joining code points, i.e., the JoinControl ("H") category defined 535 under Section 9.8. 537 4.3.3. Disallowed 539 o Old Hangul Jamo code points, i.e., the OldHangulJamo ("I") 540 category defined under Section 9.9. 542 o Control code points, i.e., the Controls ("L") category defined 543 under Section 9.12. 545 o Ignorable code points, i.e., the PrecisIgnorableProperties ("M") 546 category defined under Section 9.13. 548 4.3.4. Unassigned 550 Any code points that are not yet designated in the Unicode coded 551 character set are considered unassigned for purposes of the 552 FreeformClass, and such code points are to be treated as disallowed. 554 4.3.5. Examples 556 As described in the Introduction to this document, the string classes 557 do not handle all issues related to string preparation and comparison 558 (such as case mapping); instead, such issues are handled at the level 559 of profiles. Examples for profiles of the FreeformClass can be found 560 in [RFC7613] (the OpaqueString profile) and [RFC7700] (the Nickname 561 profile). 563 5. Profiles 565 This framework document defines the valid, contextual-rule-required, 566 disallowed, and unassigned rules for the IdentifierClass and the 567 FreeformClass. A profile of a PRECIS string class MUST define the 568 width mapping, additional mappings (if any), case mapping, 569 normalization, and directionality rules. A profile MAY also restrict 570 the allowable code points above and beyond the definition of the 571 relevant PRECIS string class (but MUST NOT add as valid any code 572 points that are disallowed by the relevant PRECIS string class). 573 These matters are discussed in the following subsections. 575 Profiles of the PRECIS string classes are registered with the IANA as 576 described under Section 11.3. Profile names use the following 577 convention: they are of the form "Profilename of BaseClass", where 578 the "Profilename" string is a differentiator and "BaseClass" is the 579 name of the PRECIS string class being profiled; for example, the 580 profile of the FreeformClass used for opaque strings such as 581 passwords is the OpaqueString profile [RFC7613]. 583 5.1. Profiles Must Not Be Multiplied beyond Necessity 585 The risk of profile proliferation is significant because having too 586 many profiles will result in different behavior across various 587 applications, thus violating what is known in user interface design 588 as the "Principle of Least Astonishment". 590 Indeed, we already have too many profiles. Ideally we would have at 591 most two or three profiles. Unfortunately, numerous application 592 protocols exist with their own quirks regarding protocol strings. 593 Domain names, email addresses, instant messaging addresses, chatroom 594 nicknames, filenames, authentication identifiers, passwords, and 595 other strings are already out there in the wild and need to be 596 supported in existing application protocols such as DNS, SMTP, the 597 Extensible Messaging and Presence Protocol (XMPP), Internet Relay 598 Chat (IRC), NFS, the Internet Small Computer System Interface 599 (iSCSI), the Extensible Authentication Protocol (EAP), and the Simple 600 Authentication and Security Layer (SASL), among others. 602 Nevertheless, profiles must not be multiplied beyond necessity. 604 To help prevent profile proliferation, this document recommends 605 sensible defaults for the various options offered to profile creators 606 (such as width mapping and Unicode normalization). In addition, the 607 guidelines for designated experts provided under Section 10 are meant 608 to encourage a high level of due diligence regarding new profiles. 610 5.2. Rules 612 5.2.1. Width Mapping Rule 614 The width mapping rule of a profile specifies whether width mapping 615 is performed on a string, and how the mapping is done. Typically, 616 such mapping consists of mapping fullwidth and halfwidth code points, 617 i.e., code points with a Decomposition Type of Wide or Narrow, to 618 their decomposition mappings; as an example, FULLWIDTH DIGIT ZERO 619 (U+FF10) would be mapped to DIGIT ZERO (U+0030). 621 The normalization form specified by a profile (see below) has an 622 impact on the need for width mapping. Because width mapping is 623 performed as a part of compatibility decomposition, a profile 624 employing either normalization form KD (NFKD) or normalization form 625 KC (NFKC) does not need to specify width mapping. However, if 626 Unicode normalization form C (NFC) is used (as is recommended) then 627 the profile needs to specify whether to apply width mapping; in this 628 case, width mapping is in general RECOMMENDED because allowing 629 fullwidth and halfwidth code points to remain unmapped to their 630 compatibility variants would violate the "Principle of Least 631 Astonishment". For more information about the concept of width in 632 East Asian scripts within Unicode, see Unicode Standard Annex #11 633 [UAX11]. 635 Note: Because the East Asian width property is not guaranteed to 636 be stable by the Unicode Standard (see [1] for details), the 637 results of applying a given width mapping rule might not be 638 consistent across different versions of Unicode. 640 5.2.2. Additional Mapping Rule 642 The additional mapping rule of a profile specifies whether additional 643 mappings are performed on a string, such as: 645 Mapping of delimiter code points (such as '@', ':', '/', '+', and 646 '-') 648 Mapping of special code points (e.g., non-ASCII space code points 649 to ASCII space or control code points to nothing). 651 The PRECIS mappings document [RFC7790] describes such mappings in 652 more detail. 654 5.2.3. Case Mapping Rule 656 The case mapping rule of a profile specifies whether case mapping 657 (instead of case preservation) is performed on a string, and how the 658 mapping is applied (e.g., mapping uppercase and titlecase code points 659 to their lowercase equivalents). 661 If case mapping is desired (instead of case preservation), it is 662 RECOMMENDED to use the Unicode toLowerCase() operation defined in the 663 Unicode Standard [Unicode]. In contrast to the Unicode toCaseFold() 664 operation, the toLowerCase() operation is less likely to violate the 665 "Principle of Least Astonishment", especially when an application 666 merely wishes to convert uppercase and titlecase code points to the 667 lowercase equivalents while preserving lowercase code points. 668 Although the toCaseFold() operation can be appropriate when an 669 application needs to compare two strings (such as in search 670 operations), in general few application developers and even fewer 671 users understand its implications, so toLowerCase() is almost always 672 the safer choice. 674 Note: Neither toLowerCase() nor toCaseFold() is designed to handle 675 various language-specific issues (such as so-called "dotless i" in 676 several Turkic languages). The reader is referred to the PRECIS 677 mappings document [RFC7790], which describes these issues in 678 greater detail. 680 In order to maximize entropy and minimize the potential for false 681 positives, it is NOT RECOMMENDED for application protocols to map 682 uppercase and titlecase code points to their lowercase equivalents 683 when strings conforming to the FreeformClass, or a profile thereof, 684 are used in passwords; instead, it is RECOMMENDED to preserve the 685 case of all code points contained in such strings and then perform 686 case-sensitive comparison. See also the related discussion in 687 Section 12.6 and in [RFC7613]. 689 5.2.4. Normalization Rule 691 The normalization rule of a profile specifies which Unicode 692 normalization form (D, KD, C, or KC) is to be applied (see Unicode 693 Standard Annex #15 [UAX15] for background information). 695 In accordance with [RFC5198], normalization form C (NFC) is 696 RECOMMENDED. 698 Protocol designers and application developers need to understand that 699 use certain Unicode normalization forms, especially NFKC and NFKD, 700 can result in significant loss of information in various 701 circumstances, and that these circumstances can vary depending on the 702 language and script of the strings to which the normalization forms 703 are applied. Extreme care should be taken when specifying the use of 704 these normalization forms. 706 5.2.5. Directionality Rule 708 The directionality rule of a profile specifies how to treat strings 709 containing what are often called "right-to-left" (RTL) code points 710 (see Unicode Standard Annex #9 [UAX9]). RTL code points come from 711 scripts that are normally written from right to left and are 712 considered by Unicode to, themselves, have right-to-left 713 directionality. Some strings containing RTL code points also contain 714 "left-to-right" (LTR) code points, such as ASCII numerals, as well as 715 code points without directional properties. Consequently, such 716 strings are known as "bidirectional strings". 718 Presenting bidirectional strings in different layout systems (e.g., a 719 user interface that is configured to handle primarily an RTL script 720 vs. an interface that is configured to handle primarily an LTR 721 script) can yield display results that, while predictable to those 722 who understand the display rules, are counter-intuitive to casual 723 users. In particular, the same bidirectional string (in PRECIS 724 terms) might not be presented in the same way to users of those 725 different layout systems, even though the presentation is consistent 726 within any particular layout system. In some applications, these 727 presentation differences might be considered problematic and thus the 728 application designers might wish to restrict the use of bidirectional 729 strings by specifying a directionality rule. In other applications, 730 these presentation differences might not be considered problematic 731 (this especially tends to be true of more "free-form" strings) and 732 thus no directionality rule is needed. 734 The PRECIS framework does not directly address how to deal with 735 bidirectional strings across all string classes and profiles, and 736 does not define any new directionality rules, because at present 737 there is no widely accepted and implemented solution for the safe 738 display of arbitrary bidirectional strings beyond the Unicode 739 bidirectional algorithm [UAX9]. Although rules for management and 740 display of bidirectional strings have been defined for domain name 741 labels and similar identifiers through the "Bidi Rule" specified in 742 the IDNA2008 specification on right-to-left scripts [RFC5893], those 743 rules are quite restrictive and are not necessarily applicable to all 744 bidirectional strings. 746 The authors of a PRECIS profile might believe that they need to 747 define a new directionality rule of their own. Because of the 748 complexity of the issues involved, such a belief is almost always 749 misguided, even if the authors have done a great deal of careful 750 research into the challenges of displaying bidirectional strings. 751 This document strongly suggests that profile authors who are thinking 752 about defining a new directionality rule think again, and instead 753 consider using the "Bidi Rule" [RFC5893] (for profiles based on the 754 IdentifierClass) or following the Unicode bidirectional algorithm 755 [UAX9] (for profiles based on the FreeformClass or in situations 756 where the IdentifierClass is not appropriate). 758 5.3. A Note about Spaces 760 With regard to the IdentifierClass, the consensus of the PRECIS 761 Working Group was that spaces are problematic for many reasons, 762 including the following: 764 o Many Unicode code points are confusable with ASCII space. 766 o Even if non-ASCII space code points are mapped to ASCII space 767 (U+0020), space code points are often not rendered in user 768 interfaces, leading to the possibility that a human user might 769 consider a string containing spaces to be equivalent to the same 770 string without spaces. 772 o In some locales, some devices are known to generate a code point 773 other than ASCII space (such as ZERO WIDTH JOINER, U+200D) when a 774 user performs an action like hitting the space bar on a keyboard. 776 One consequence of disallowing space code points in the 777 IdentifierClass might be to effectively discourage their use within 778 identifiers created in newer application protocols; given the 779 challenges involved with properly handling space code points 780 (especially non-ASCII space code points) in identifiers and other 781 protocol strings, the PRECIS Working Group considered this to be a 782 feature, not a bug. 784 However, the FreeformClass does allow spaces, which enables 785 application protocols to define profiles of the FreeformClass that 786 are more flexible than any profiles of the IdentifierClass. In 787 addition, as explained in Section 6.3, application protocols can also 788 define application-layer constructs containing spaces. 790 6. Applications 792 6.1. How to Use PRECIS in Applications 794 Although PRECIS has been designed with applications in mind, 795 internationalization is not suddenly made easy through the use of 796 PRECIS. Indeed, because it is extremely difficult for protocol 797 designers and application developers to do the right thing for all 798 users when supporting internationalized strings, often the safest 799 option is to support only the ASCII range [RFC20] in various protocol 800 slots. This state of affairs is unfortunate but is the direct result 801 of the complexities involved with human languages (e.g., the vast 802 number of code points, scripts, user communities, and rules with 803 their inevitable exceptions), which kinds of strings application 804 developers and their users wish to support, the wide range of devices 805 that users employ to access services enabled by various Internet 806 protocols, and so on. 808 Despite these significant challenges, application and protocol 809 developers sometimes persevere in attempting to support 810 internationalized strings in their systems. These developers need to 811 think carefully about how they will use the PRECIS string classes, or 812 profiles thereof, in their applications. This section provides some 813 guidelines to application developers (and to expert reviewers of 814 application protocol specifications). 816 o Don't define your own profile unless absolutely necessary (see 817 Section 5.1). Existing profiles have been designed for wide 818 reuse. It is highly likely that an existing profile will meet 819 your needs, especially given the ability to specify further 820 excluded code points (Section 6.2) and to build application-layer 821 constructs (see Section 6.3). 823 o Do specify: 825 * Exactly which entities are responsible for preparation, 826 enforcement, and comparison of internationalized strings (e.g., 827 servers or clients). 829 * Exactly when those entities need to complete their tasks (e.g., 830 a server might need to enforce the rules of a profile before 831 allowing a client to gain network access). 833 * Exactly which protocol slots need to be checked against which 834 profiles (e.g., checking the address of a message's intended 835 recipient against the UsernameCaseMapped profile [RFC7613] of 836 the IdentifierClass, or checking the password of a user against 837 the OpaqueString profile [RFC7613] of the FreeformClass). 839 See [RFC7613] and [RFC7622] for definitions of these matters for 840 several applications. 842 6.2. Further Excluded Characters 844 An application protocol that uses a profile MAY specify particular 845 code points that are not allowed in relevant slots within that 846 application protocol, above and beyond those excluded by the string 847 class or profile. 849 That is, an application protocol MAY do either of the following: 851 1. Exclude specific code points that are allowed by the relevant 852 string class. 854 2. Exclude code points matching certain Unicode properties (e.g., 855 math symbols) that are included in the relevant PRECIS string 856 class. 858 As a result of such exclusions, code points that are defined as valid 859 for the PRECIS string class or profile will be defined as disallowed 860 for the relevant protocol slot. 862 Typically, such exclusions are defined for the purpose of backward 863 compatibility with legacy formats within an application protocol. 864 These are defined for application protocols, not profiles, in order 865 to prevent multiplication of profiles beyond necessity (see 866 Section 5.1). 868 6.3. Building Application-Layer Constructs 870 Sometimes, an application-layer construct does not map in a 871 straightforward manner to one of the base string classes or a profile 872 thereof. Consider, for example, the "simple user name" construct in 873 the Simple Authentication and Security Layer (SASL) [RFC4422]. 874 Depending on the deployment, a simple user name might take the form 875 of a user's full name (e.g., the user's personal name followed by a 876 space and then the user's family name). Such a simple user name 877 cannot be defined as an instance of the IdentifierClass or a profile 878 thereof, because space code points are not allowed in the 879 IdentifierClass; however, it could be defined using a space-separated 880 sequence of IdentifierClass instances, as in the following ABNF 881 [RFC5234] from [RFC7613]: 883 username = userpart *(1*SP userpart) 884 userpart = 1*(idpoint) 885 ; 886 ; an "idpoint" is a Unicode code point that 887 ; can be contained in a string conforming to 888 ; the PRECIS IdentifierClass 889 ; 891 Similar techniques could be used to define many application-layer 892 constructs, say of the form "user@domain" or "/path/to/file". 894 7. Order of Operations 896 To ensure proper comparison, the rules specified for a particular 897 string class or profile MUST be applied in the following order: 899 1. Width Mapping Rule 901 2. Additional Mapping Rule 903 3. Case Mapping Rule 905 4. Normalization Rule 907 5. Directionality Rule 909 6. Behavioral rules for determining whether a code point is valid, 910 allowed under a contextual rule, disallowed, or unassigned 912 As already described, the width mapping, additional mapping, case 913 mapping, normalization, and directionality rules are specified for 914 each profile, whereas the behavioral rules are specified for each 915 string class. Some of the logic behind this order is provided under 916 Section 5.2.1 (see also the PRECIS mappings document [RFC7790]). In 917 addition, this order is consistent with IDNA2008, and with both 918 IDNA2003 and Stringprep before then, for the purpose of enabling code 919 reuse and of ensuring as much continuity as possible with the 920 Stringprep profiles that are obsoleted by several PRECIS profiles. 922 Because of the order of operations specified here, applying the rules 923 for any given PRECIS profile is not necessarily an idempotent 924 procedure (e.g., under certain circumstances, such as when Unicode 925 normalization form KC is used, performing Unicode normalization after 926 case mapping can still yield uppercase characters for certain code 927 points); therefore, implementations might need to apply the rules 928 more than once to an internationalized string. 930 8. Code Point Properties 932 In order to implement the string classes described above, this 933 document does the following: 935 1. Reviews and classifies the collections of code points in the 936 Unicode coded character set by examining various code point 937 properties. 939 2. Defines an algorithm for determining a derived property value, 940 which can vary depending on the string class being used by the 941 relevant application protocol. 943 This document is not intended to specify precisely how derived 944 property values are to be applied in protocol strings. That 945 information is the responsibility of the protocol specification that 946 uses or profiles a PRECIS string class from this document. The value 947 of the property is to be interpreted as follows. 949 PROTOCOL VALID Those code points that are allowed to be used in any 950 PRECIS string class (currently, IdentifierClass and 951 FreeformClass). The abbreviated term "PVALID" is used to refer to 952 this value in the remainder of this document. 954 SPECIFIC CLASS PROTOCOL VALID Those code points that are allowed to 955 be used in specific string classes. In the remainder of this 956 document, the abbreviated term *_PVAL is used, where * = (ID | 957 FREE), i.e., either "FREE_PVAL" or "ID_PVAL". In practice, the 958 derived property ID_PVAL is not used in this specification, 959 because every ID_PVAL code point is PVALID. 961 CONTEXTUAL RULE REQUIRED Some characteristics of the code point, 962 such as its being invisible in certain contexts or problematic in 963 others, require that it not be used in a string unless specific 964 other code points or properties are present in the string. As in 965 IDNA2008, there are two subdivisions of CONTEXTUAL RULE REQUIRED 966 -- the first for Join_controls (called "CONTEXTJ") and the second 967 for other code points (called "CONTEXTO"). A string MUST NOT 968 contain any characters whose validity is context-dependent, unless 969 the validity is positively confirmed by a contextual rule. To 970 check this, each code point identified as CONTEXTJ or CONTEXTO in 971 the PRECIS Derived Property Value registry MUST have a non-null 972 rule. If such a code point is missing a rule, the string is 973 invalid. If the rule exists but the result of applying the rule 974 is negative or inconclusive, the proposed string is invalid. The 975 most notable of the CONTEXTUAL RULE REQUIRED code points are the 976 Join Control code points U+200D ZERO WIDTH JOINER and U+200C ZERO 977 WIDTH NON-JOINER, which have a derived property value of CONTEXTJ. 978 See Appendix A of [RFC5892] for more information. 980 DISALLOWED Those code points that are not permitted in any PRECIS 981 string class. 983 SPECIFIC CLASS DISALLOWED Those code points that are not to be 984 included in one of the string classes but that might be permitted 985 in others. In the remainder of this document, the abbreviated 986 term *_DIS is used, where * = (ID | FREE), i.e., either "FREE_DIS" 987 or "ID_DIS". In practice, the derived property FREE_DIS is not 988 used in this specification, because every FREE_DIS code point is 989 DISALLOWED. 991 UNASSIGNED Those code points that are not designated (i.e., are 992 unassigned) in the Unicode Standard. 994 The algorithm to calculate the value of the derived property is as 995 follows (implementations MUST NOT modify the order of operations 996 within this algorithm, because doing so would cause inconsistent 997 results across implementations): 999 If .cp. .in. Exceptions Then Exceptions(cp); 1000 Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp); 1001 Else If .cp. .in. Unassigned Then UNASSIGNED; 1002 Else If .cp. .in. ASCII7 Then PVALID; 1003 Else If .cp. .in. JoinControl Then CONTEXTJ; 1004 Else If .cp. .in. OldHangulJamo Then DISALLOWED; 1005 Else If .cp. .in. PrecisIgnorableProperties Then DISALLOWED; 1006 Else If .cp. .in. Controls Then DISALLOWED; 1007 Else If .cp. .in. HasCompat Then ID_DIS or FREE_PVAL; 1008 Else If .cp. .in. LetterDigits Then PVALID; 1009 Else If .cp. .in. OtherLetterDigits Then ID_DIS or FREE_PVAL; 1010 Else If .cp. .in. Spaces Then ID_DIS or FREE_PVAL; 1011 Else If .cp. .in. Symbols Then ID_DIS or FREE_PVAL; 1012 Else If .cp. .in. Punctuation Then ID_DIS or FREE_PVAL; 1013 Else DISALLOWED; 1015 The value of the derived property calculated can depend on the string 1016 class; for example, if an identifier used in an application protocol 1017 is defined as profiling the PRECIS IdentifierClass then a space 1018 character such as U+0020 would be assigned to ID_DIS, whereas if an 1019 identifier is defined as profiling the PRECIS FreeformClass then the 1020 character would be assigned to FREE_PVAL. For the sake of brevity, 1021 the designation "FREE_PVAL" is used herein, instead of the longer 1022 designation "ID_DIS or FREE_PVAL". In practice, the derived 1023 properties ID_PVAL and FREE_DIS are not used in this specification, 1024 because every ID_PVAL code point is PVALID and every FREE_DIS code 1025 point is DISALLOWED. 1027 Use of the name of a rule (such as "Exceptions") implies the set of 1028 code points that the rule defines, whereas the same name as a 1029 function call (such as "Exceptions(cp)") implies the value that the 1030 code point has in the Exceptions table. 1032 The mechanisms described here allow determination of the value of the 1033 property for future versions of Unicode (including code points added 1034 after Unicode 5.2 or 7.0 depending on the category, because some 1035 categories mentioned in this document are simply pointers to IDNA2008 1036 and therefore were defined at the time of Unicode 5.2). Changes in 1037 Unicode properties that do not affect the outcome of this process 1038 therefore do not affect this framework. For example, a code point 1039 can have its Unicode General_Category value change from So to Sm, or 1040 from Lo to Ll, without affecting the algorithm results. Moreover, 1041 even if such changes were to result, the BackwardCompatible list 1042 (Section 9.7) can be adjusted to ensure the stability of the results. 1044 9. Category Definitions Used to Calculate Derived Property 1046 The derived property obtains its value based on a two-step procedure: 1048 1. Code points are placed in one or more character categories either 1049 (1) based on core properties defined by the Unicode Standard or 1050 (2) by treating the code point as an exception and addressing the 1051 code point based on its code point value. These categories are 1052 not mutually exclusive. 1054 2. Set operations are used with these categories to determine the 1055 values for a property specific to a given string class. These 1056 operations are specified under Section 8. 1058 Note: Unicode property names and property value names might have 1059 short abbreviations, such as "gc" for the General_Category 1060 property and "Ll" for the Lowercase_Letter property value of the 1061 gc property. 1063 In the following specification of character categories, the operation 1064 that returns the value of a particular Unicode code point property 1065 for a code point is designated by using the formal name of that 1066 property (from the Unicode PropertyAliases.txt file [PropertyAliases] 1067 followed by "(cp)" for "code point". For example, the value of the 1068 General_Category property for a code point is indicated by 1069 General_Category(cp). 1071 The first ten categories (A-J) shown below were previously defined 1072 for IDNA2008 and are referenced from [RFC5892] to ease the 1073 understanding of how PRECIS handles various code points. Some of 1074 these categories are reused in PRECIS, and some of them are not; 1075 however, the lettering of categories is retained to prevent overlap 1076 and to ease implementation of both IDNA2008 and PRECIS in a single 1077 software application. The next eight categories (K-R) are specific 1078 to PRECIS. 1080 9.1. LetterDigits (A) 1082 This category is defined in Section 2.1 of [RFC5892] and is included 1083 by reference for use in PRECIS. 1085 9.2. Unstable (B) 1087 This category is defined in Section 2.2 of [RFC5892]. However, it is 1088 not used in PRECIS. 1090 9.3. IgnorableProperties (C) 1092 This category is defined in Section 2.3 of [RFC5892]. However, it is 1093 not used in PRECIS. 1095 Note: See the PrecisIgnorableProperties ("M") category below for a 1096 more inclusive category used in PRECIS identifiers. 1098 9.4. IgnorableBlocks (D) 1100 This category is defined in Section 2.4 of [RFC5892]. However, it is 1101 not used in PRECIS. 1103 9.5. LDH (E) 1105 This category is defined in Section 2.5 of [RFC5892]. However, it is 1106 not used in PRECIS. 1108 Note: See the ASCII7 ("K") category below for a more inclusive 1109 category used in PRECIS identifiers. 1111 9.6. Exceptions (F) 1113 This category is defined in Section 2.6 of [RFC5892] and is included 1114 by reference for use in PRECIS. 1116 9.7. BackwardCompatible (G) 1118 This category is defined in Section 2.7 of [RFC5892] and is included 1119 by reference for use in PRECIS. 1121 Note: Management of this category is handled via the processes 1122 specified in [RFC5892]. At the time of this writing (and also at the 1123 time that RFC 5892 was published), this category consisted of the 1124 empty set; however, that is subject to change as described in 1125 RFC 5892. 1127 9.8. JoinControl (H) 1129 This category is defined in Section 2.8 of [RFC5892] and is included 1130 by reference for use in PRECIS. 1132 9.9. OldHangulJamo (I) 1134 This category is defined in Section 2.9 of [RFC5892] and is included 1135 by reference for use in PRECIS. 1137 9.10. Unassigned (J) 1139 This category is defined in Section 2.10 of [RFC5892] and is included 1140 by reference for use in PRECIS. 1142 9.11. ASCII7 (K) 1144 This PRECIS-specific category consists of all printable, non-space 1145 code points from the 7-bit ASCII range. By applying this category, 1146 the algorithm specified under Section 8 exempts these code points 1147 from other rules that might be applied during PRECIS processing, on 1148 the assumption that these code points are in such wide use that 1149 disallowing them would be counter-productive. 1151 K: cp is in {0021..007E} 1153 9.12. Controls (L) 1155 This PRECIS-specific category consists of all control code points. 1157 L: Control(cp) = True 1159 9.13. PrecisIgnorableProperties (M) 1161 This PRECIS-specific category is used to group code points that are 1162 discouraged from use in PRECIS string classes. 1164 M: Default_Ignorable_Code_Point(cp) = True or 1165 Noncharacter_Code_Point(cp) = True 1167 The definition for Default_Ignorable_Code_Point can be found in the 1168 DerivedCoreProperties.txt file [DerivedCoreProperties]. 1170 9.14. Spaces (N) 1172 This PRECIS-specific category is used to group code points that are 1173 space code points. 1175 N: General_Category(cp) is in {Zs} 1177 9.15. Symbols (O) 1179 This PRECIS-specific category is used to group code points that are 1180 symbols. 1182 O: General_Category(cp) is in {Sm, Sc, Sk, So} 1184 9.16. Punctuation (P) 1186 This PRECIS-specific category is used to group code points that are 1187 punctuation code points. 1189 P: General_Category(cp) is in {Pc, Pd, Ps, Pe, Pi, Pf, Po} 1191 9.17. HasCompat (Q) 1193 This PRECIS-specific category is used to group any code point that is 1194 decomposed and recomposed into something other than itself under 1195 Unicode normalization form KC. 1197 Q: toNFKC(cp) != cp 1199 Typically this category is true of code points that are 1200 "compatibility decomposable characters" as defined in the Unicode 1201 Standard. 1203 The toNFKC() operation returns the code point in normalization form 1204 KC. For more information, see Section 5 of Unicode Standard Annex 1205 #15 [UAX15]. 1207 9.18. OtherLetterDigits (R) 1209 This PRECIS-specific category is used to group code points that are 1210 letters and digits other than the "traditional" letters and digits 1211 grouped under the LetterDigits (A) class (see Section 9.1). 1213 R: General_Category(cp) is in {Lt, Nl, No, Me} 1215 10. Guidelines for Designated Experts 1217 Experience with internationalization in application protocols has 1218 shown that protocol designers and application developers usually do 1219 not understand the subtleties and tradeoffs involved with 1220 internationalization and that they need considerable guidance in 1221 making reasonable decisions with regard to the options before them. 1223 Therefore: 1225 o Protocol designers are strongly encouraged to question the 1226 assumption that they need to define new profiles, because existing 1227 profiles are designed for wide reuse (see Section 5 for further 1228 discussion). 1230 o Those who persist in defining new profiles are strongly encouraged 1231 to clearly explain a strong justification for doing so, and to 1232 publish a stable specification that provides all of the 1233 information described under Section 11.3. 1235 o The designated experts for profile registration requests ought to 1236 seek answers to all of the questions provided under Section 11.3 1237 and to encourage applicants to provide a stable specification 1238 documenting the profile (even though the registration policy for 1239 PRECIS profiles is Expert Review and a stable specification is not 1240 strictly required). 1242 o Developers of applications that use PRECIS are strongly encouraged 1243 to apply the guidelines provided under Section 6 and to seek out 1244 the advice of the designated experts or other knowledgeable 1245 individuals in doing so. 1247 o All parties are strongly encouraged to help prevent the 1248 multiplication of profiles beyond necessity, as described under 1249 Section 5.1, and to use PRECIS in ways that will minimize user 1250 confusion and insecure application behavior. 1252 Internationalization can be difficult and contentious; designated 1253 experts, profile registrants, and application developers are strongly 1254 encouraged to work together in a spirit of good faith and mutual 1255 understanding to achieve rough consensus on profile registration 1256 requests and the use of PRECIS in particular applications. They are 1257 also encouraged to bring additional expertise into the discussion if 1258 that would be helpful in adding perspective or otherwise resolving 1259 issues. 1261 11. IANA Considerations 1263 11.1. PRECIS Derived Property Value Registry 1265 IANA has created and now maintains the "PRECIS Derived Property 1266 Value" registry that records the derived properties for the versions 1267 of Unicode that are released after (and including) version 7.0. The 1268 derived property value is to be calculated in cooperation with a 1269 designated expert [RFC5226] according to the rules specified under 1270 Sections 8 and 9. 1272 The IESG is to be notified if backward-incompatible changes to the 1273 table of derived properties are discovered or if other problems arise 1274 during the process of creating the table of derived property values 1275 or during expert review. Changes to the rules defined under 1276 Sections 8 and 9 require IETF Review. 1278 11.2. PRECIS Base Classes Registry 1280 IANA has created the "PRECIS Base Classes" registry. In accordance 1281 with [RFC5226], the registration policy is "RFC Required". 1283 The registration template is as follows: 1285 Base Class: [the name of the PRECIS string class] 1287 Description: [a brief description of the PRECIS string class and its 1288 intended use, e.g., "A sequence of letters, numbers, and symbols 1289 that is used to identify or address a network entity."] 1291 Specification: [the RFC number] 1293 The initial registrations are as follows: 1295 Base Class: FreeformClass. 1296 Description: A sequence of letters, numbers, symbols, spaces, and 1297 other code points that is used for free-form strings. 1298 Specification: Section 4.3 of RFC 7564. 1300 Base Class: IdentifierClass. 1301 Description: A sequence of letters, numbers, and symbols that is 1302 used to identify or address a network entity. 1303 Specification: Section 4.2 of RFC 7564. 1305 11.3. PRECIS Profiles Registry 1307 IANA has created the "PRECIS Profiles" registry to identify profiles 1308 that use the PRECIS string classes. In accordance with [RFC5226], 1309 the registration policy is "Expert Review". This policy was chosen 1310 in order to ease the burden of registration while ensuring that 1311 "customers" of PRECIS receive appropriate guidance regarding the 1312 sometimes complex and subtle internationalization issues related to 1313 profiles of PRECIS string classes. 1315 The registration template is as follows: 1317 Name: [the name of the profile] 1319 Base Class: [which PRECIS string class is being profiled] 1320 Applicability: [the specific protocol elements to which this profile 1321 applies, e.g., "Localparts in XMPP addresses."] 1323 Replaces: [the Stringprep profile that this PRECIS profile replaces, 1324 if any] 1326 Width Mapping Rule: [the behavioral rule for handling of width, 1327 e.g., "Map fullwidth and halfwidth code points to their 1328 compatibility variants."] 1330 Additional Mapping Rule: [any additional mappings that are required 1331 or recommended, e.g., "Map non-ASCII space code points to ASCII 1332 space."] 1334 Case Mapping Rule: [the behavioral rule for handling of case, e.g., 1335 "apply the Unicode toLowerCase() operation"] 1337 Normalization Rule: [which Unicode normalization form is applied, 1338 e.g., "NFC"] 1340 Directionality Rule: [the behavioral rule for handling of right-to- 1341 left code points, e.g., "The 'Bidi Rule' defined in RFC 5893 1342 applies."] 1344 Enforcement: [which entities enforce the rules, and when that 1345 enforcement occurs during protocol operations] 1347 Specification: [a pointer to relevant documentation, such as an RFC 1348 or Internet-Draft] 1350 In order to request a review, the registrant shall send a completed 1351 template to the precis@ietf.org list or its designated successor. 1353 Factors to focus on while defining profiles and reviewing profile 1354 registrations include the following: 1356 o Would an existing PRECIS string class or profile solve the 1357 problem? If not, why not? (See Section 5.1 for related 1358 considerations.) 1360 o Is the problem being addressed by this profile well defined? 1362 o Does the specification define what kinds of applications are 1363 involved and the protocol elements to which this profile applies? 1365 o Is the profile clearly defined? 1366 o Is the profile based on an appropriate dividing line between user 1367 interface (culture, context, intent, locale, device limitations, 1368 etc.) and the use of conformant strings in protocol elements? 1370 o Are the width mapping, case mapping, additional mappings, 1371 normalization, and directionality rules appropriate for the 1372 intended use? 1374 o Does the profile explain which entities enforce the rules, and 1375 when such enforcement occurs during protocol operations? 1377 o Does the profile reduce the degree to which human users could be 1378 surprised or confused by application behavior (the "Principle of 1379 Least Astonishment")? 1381 o Does the profile introduce any new security concerns such as those 1382 described under Section 12 of this document (e.g., false positives 1383 for authentication or authorization)? 1385 12. Security Considerations 1387 12.1. General Issues 1389 If input strings that appear "the same" to users are programmatically 1390 considered to be distinct in different systems, or if input strings 1391 that appear distinct to users are programmatically considered to be 1392 "the same" in different systems, then users can be confused. Such 1393 confusion can have security implications, such as the false positives 1394 and false negatives discussed in [RFC6943]. One starting goal of 1395 work on the PRECIS framework was to limit the number of times that 1396 users are confused (consistent with the "Principle of Least 1397 Astonishment"). Unfortunately, this goal has been difficult to 1398 achieve given the large number of application protocols already in 1399 existence. Despite these difficulties, profiles should not be 1400 multiplied beyond necessity (see Section 5.1). In particular, 1401 application protocol designers should think long and hard before 1402 defining a new profile instead of using one that has already been 1403 defined, and if they decide to define a new profile then they should 1404 clearly explain their reasons for doing so. 1406 The security of applications that use this framework can depend in 1407 part on the proper preparation, enforcement, and comparison of 1408 internationalized strings. For example, such strings can be used to 1409 make authentication and authorization decisions, and the security of 1410 an application could be compromised if an entity providing a given 1411 string is connected to the wrong account or online resource based on 1412 different interpretations of the string (again, see [RFC6943]). 1414 Specifications of application protocols that use this framework are 1415 strongly encouraged to describe how internationalized strings are 1416 used in the protocol, including the security implications of any 1417 false positives and false negatives that might result from various 1418 enforcement and comparison operations. For some helpful guidelines, 1419 refer to [RFC6943], [RFC5890], [UTR36], and [UTS39]. 1421 12.2. Use of the IdentifierClass 1423 Strings that conform to the IdentifierClass and any profile thereof 1424 are intended to be relatively safe for use in a broad range of 1425 applications, primarily because they include only letters, digits, 1426 and "grandfathered" non-space code points from the ASCII range; thus, 1427 they exclude spaces, code points with compatibility equivalents, and 1428 almost all symbols and punctuation marks. However, because such 1429 strings can still include so-called confusable code points (see 1430 Section 12.5), protocol designers and implementers are encouraged to 1431 pay close attention to the security considerations described 1432 elsewhere in this document. 1434 12.3. Use of the FreeformClass 1436 Strings that conform to the FreeformClass and many profiles thereof 1437 can include virtually any Unicode code point. This makes the 1438 FreeformClass quite expressive, but also problematic from the 1439 perspective of possible user confusion. Protocol designers are 1440 hereby warned that the FreeformClass contains code points they might 1441 not understand, and are encouraged to profile the IdentifierClass 1442 wherever feasible; however, if an application protocol requires more 1443 code points than are allowed by the IdentifierClass, protocol 1444 designers are encouraged to define a profile of the FreeformClass 1445 that restricts the allowable code points as tightly as possible. 1446 (The PRECIS Working Group considered the option of allowing 1447 "superclasses" as well as profiles of PRECIS string classes, but 1448 decided against allowing superclasses to reduce the likelihood of 1449 security and interoperability problems.) 1451 12.4. Local Character Set Issues 1453 When systems use local character sets other than ASCII and Unicode, 1454 this specification leaves the problem of converting between the local 1455 character set and Unicode up to the application or local system. If 1456 different applications (or different versions of one application) 1457 implement different rules for conversions among coded character sets, 1458 they could interpret the same name differently and contact different 1459 application servers or other network entities. This problem is not 1460 solved by security protocols, such as Transport Layer Security (TLS) 1462 [RFC5246] and the Simple Authentication and Security Layer (SASL) 1463 [RFC4422], that do not take local character sets into account. 1465 12.5. Visually Similar Characters 1467 Some code points are visually similar and thus can cause confusion 1468 among humans. Such characters are often called "confusable 1469 characters" or "confusables". 1471 The problem of confusable characters is not necessarily caused by the 1472 use of Unicode code points outside the ASCII range. For example, in 1473 some presentations and to some individuals the string "ju1iet" 1474 (spelled with DIGIT ONE, U+0031, as the third character) might appear 1475 to be the same as "juliet" (spelled with LATIN SMALL LETTER L, 1476 U+006C), especially on casual visual inspection. This phenomenon is 1477 sometimes called "typejacking". 1479 However, the problem is made more serious by introducing the full 1480 range of Unicode code points into protocol strings. For example, the 1481 code points U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the 1482 Cherokee block look similar to the ASCII code points representing 1483 "STPETER" as they might appear when presented using a "creative" font 1484 family. 1486 In some examples of confusable characters, it is unlikely that the 1487 average human could tell the difference between the real string and 1488 the fake string. (Indeed, there is no programmatic way to 1489 distinguish with full certainty which is the fake string and which is 1490 the real string; in some contexts, the string formed of Cherokee code 1491 points might be the real string and the string formed of ASCII code 1492 points might be the fake string.) Because PRECIS-compliant strings 1493 can contain almost any properly encoded Unicode code point, it can be 1494 relatively easy to fake or mimic some strings in systems that use the 1495 PRECIS framework. The fact that some strings are easily confused 1496 introduces security vulnerabilities of the kind that have also 1497 plagued the World Wide Web, specifically the phenomenon known as 1498 phishing. 1500 Despite the fact that some specific suggestions about identification 1501 and handling of confusable characters appear in the Unicode Security 1502 Considerations [UTR36] and the Unicode Security Mechanisms [UTS39], 1503 it is also true (as noted in [RFC5890]) that "there are no 1504 comprehensive technical solutions to the problems of confusable 1505 characters." Because it is impossible to map visually similar 1506 characters without a great deal of context (such as knowing the font 1507 families used), the PRECIS framework does nothing to map similar- 1508 looking characters together, nor does it prohibit some characters 1509 because they look like others. 1511 Nevertheless, specifications for application protocols that use this 1512 framework are strongly encouraged to describe how confusable 1513 characters can be abused to compromise the security of systems that 1514 use the protocol in question, along with any protocol-specific 1515 suggestions for overcoming those threats. In particular, software 1516 implementations and service deployments that use PRECIS-based 1517 technologies are strongly encouraged to define and implement 1518 consistent policies regarding the registration, storage, and 1519 presentation of visually similar characters. The following 1520 recommendations are appropriate: 1522 1. An application service SHOULD define a policy that specifies the 1523 scripts or blocks of code points that the service will allow to 1524 be registered (e.g., in an account name) or stored (e.g., in a 1525 filename). Such a policy SHOULD be informed by the languages and 1526 scripts that are used to write registered account names; in 1527 particular, to reduce confusion, the service SHOULD forbid 1528 registration or storage of strings that contain code points from 1529 more than one script and SHOULD restrict registrations to code 1530 points drawn from a very small number of scripts (e.g., scripts 1531 that are well understood by the administrators of the service, to 1532 improve manageability). 1534 2. User-oriented application software SHOULD define a policy that 1535 specifies how internationalized strings will be presented to a 1536 human user. Because every human user of such software has a 1537 preferred language or a small set of preferred languages, the 1538 software SHOULD gather that information either explicitly from 1539 the user or implicitly via the operating system of the user's 1540 device. Furthermore, because most languages are typically 1541 represented by a single script or a small set of scripts, and 1542 because most scripts are typically contained in one or more 1543 blocks of code points, the software SHOULD warn the user when 1544 presenting a string that mixes code points from more than one 1545 script or block, or that uses code points outside the normal 1546 range of the user's preferred language(s). (Such a 1547 recommendation is not intended to discourage communication across 1548 different communities of language users; instead, it recognizes 1549 the existence of such communities and encourages due caution when 1550 presenting unfamiliar scripts or code points to human users.) 1552 The challenges inherent in supporting the full range of Unicode code 1553 points have in the past led some to hope for a way to 1554 programmatically negotiate more restrictive ranges based on locale, 1555 script, or other relevant factors; to tag the locale associated with 1556 a particular string; etc. As a general-purpose internationalization 1557 technology, the PRECIS framework does not include such mechanisms. 1559 12.6. Security of Passwords 1561 Two goals of passwords are to maximize the amount of entropy and to 1562 minimize the potential for false positives. These goals can be 1563 achieved in part by allowing a wide range of code points and by 1564 ensuring that passwords are handled in such a way that code points 1565 are not compared aggressively. Therefore, it is NOT RECOMMENDED for 1566 application protocols to profile the FreeformClass for use in 1567 passwords in a way that removes entire categories (e.g., by 1568 disallowing symbols or punctuation). Furthermore, it is NOT 1569 RECOMMENDED for application protocols to map uppercase and titlecase 1570 code points to their lowercase equivalents in such strings; instead, 1571 it is RECOMMENDED to preserve the case of all code points contained 1572 in such strings and to compare them in a case-sensitive manner. 1574 That said, software implementers need to be aware that there exist 1575 tradeoffs between entropy and usability. For example, allowing a 1576 user to establish a password containing "uncommon" code points might 1577 make it difficult for the user to access a service when using an 1578 unfamiliar or constrained input device. 1580 Some application protocols use passwords directly, whereas others 1581 reuse technologies that themselves process passwords (one example of 1582 such a technology is the Simple Authentication and Security Layer 1583 [RFC4422]). Moreover, passwords are often carried by a sequence of 1584 protocols with backend authentication systems or data storage systems 1585 such as RADIUS [RFC2865] and the Lightweight Directory Access 1586 Protocol (LDAP) [RFC4510]. Developers of application protocols are 1587 encouraged to look into reusing these profiles instead of defining 1588 new ones, so that end-user expectations about passwords are 1589 consistent no matter which application protocol is used. 1591 In protocols that provide passwords as input to a cryptographic 1592 algorithm such as a hash function, the client will need to perform 1593 proper preparation of the password before applying the algorithm, 1594 because the password is not available to the server in plaintext 1595 form. 1597 Further discussion of password handling can be found in [RFC7613]. 1599 13. Interoperability Considerations 1601 13.1. Coded Character Sets 1603 It is known that some existing applications and systems do not 1604 support the full Unicode coded character set, or even any characters 1605 outside the ASCII repertoire [RFC20]. If two (or more) applications 1606 or systems need to interoperate when exchanging data (e.g., for the 1607 purpose of authenticating the combination of a username and 1608 password), naturally they will need to have in common at least one 1609 coded character set and the repertoire of characters being exchanged 1610 (see [RFC6365] for definitions of these terms). Establishing such a 1611 baseline is a matter for the application or system that uses PRECIS, 1612 not for the PRECIS framework. 1614 13.2. Dependency on Unicode 1616 The only coded character set supported by PRECIS is Unicode. If an 1617 application or system does not support Unicode or uses a different 1618 coded character set [RFC6365], then the PRECIS rules cannot be 1619 applied to that application or system. 1621 13.3. Encoding 1623 Although strings that are consumed in PRECIS-based application 1624 protocols are often encoded using UTF-8 [RFC3629], the exact encoding 1625 is a matter for the application protocol that uses PRECIS, not for 1626 the PRECIS framework or for specifications that define PRECIS string 1627 classes or profiles thereof. 1629 13.4. Unicode Versions 1631 It is extremely important for protocol designers and application 1632 developers to undersatnd that various changes can occur across 1633 versions of the Unicode Standard, and such changes can result in 1634 instability of PRECIS categories. The following are merely a few 1635 examples: 1637 o As described in [RFC6452], between Unicode 5.2 (current at the 1638 time IDNA2008 was originally published) and Unicode 6.0, three 1639 code points underwent changes in their GeneralCategory, resulting 1640 in modified handling depending on which version of Unicode is 1641 available on the underlying system. 1643 o The HasCompat() categorization of a given input string could 1644 change if, for example, the string includes a precomposed 1645 character that was added in a recent version of Unicode. 1647 o The East Asian width property, which is used in many PRECIS width- 1648 mapping rules, is not guaranteed to be stable across Unicode 1649 versions. 1651 Other such differences might arise between the version of Unicode 1652 current at the time of this writing (7.0) and future versions. 1654 13.5. Potential Changes to Handling of Certain Unicode Code Points 1656 As part of the review of Unicode 7.0 for IDNA, a question was raised 1657 about a newly added code point that led to a re-analysis of the 1658 normalization rules used by IDNA and inherited by this document 1659 (Section 5.2.4). Some of the general issues are described in 1660 [IAB-Statement] and pursued in more detail in [IDNA-Unicode]. 1662 At the time of writing, these issues have yet to be settled. 1663 However, implementers need to be aware that this specification is 1664 likely to be updated in the future to address these issues. The 1665 potential changes include the following: 1667 o The range of code points in the LetterDigits category 1668 (Sections 4.2.1 and 9.1) might be narrowed. 1670 o Some code points with special properties that are now allowed 1671 might be excluded. 1673 o More "Additional Mapping Rules" (Section 5.2.2) might be defined. 1675 o Alternative normalization methods might be added. 1677 Until these issues are sorted out, it is reasonable for the IANA to 1678 apply the same precautionary principle described in [IAB-Statement] 1679 to the PRECIS Derived Property Value Registry as is applied to the 1680 Internationalized Domain Names for Applications (IDNA) Parameters 1681 registry: that is, to not make further updates to the registry. 1683 Nevertheless, implementations and deployments are unlikely to 1684 encounter significant problems as a consequence of these issues or 1685 potential changes if they follow the advice given in this 1686 specification to use the more restrictive IdentifierClass whenever 1687 possible or, if using the FreeformClass, to allow only a restricted 1688 set of code points, particularly avoiding code points whose 1689 implications they do not understand. 1691 14. References 1693 14.1. Normative References 1695 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, 1696 RFC 20, DOI 10.17487/RFC0020, October 1969, 1697 . 1699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1700 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1701 RFC2119, March 1997, 1702 . 1704 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1705 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 1706 . 1708 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1709 Internationalization in the IETF", BCP 166, RFC 6365, DOI 1710 10.17487/RFC6365, September 2011, 1711 . 1713 [Unicode] The Unicode Consortium, "The Unicode Standard", 1714 . 1716 14.2. Informative References 1718 [DerivedCoreProperties] 1719 The Unicode Consortium, "DerivedCoreProperties-7.0.0.txt", 1720 Unicode Character Database, February 2014, 1721 . 1724 [Err4568] RFC Errata, "Erratum ID 4568", RFC 7564, 1725 . 1727 [IAB-Statement] 1728 Internet Architecture Board, "IAB Statement on Identifiers 1729 and Unicode 7.0.0", February 2015, . 1733 [IDNA-Unicode] 1734 Klensin, J. and P. Faltstrom, "IDNA Update for Unicode 1735 7.0.0", Work in Progress, draft-klensin-idna-5892upd- 1736 unicode70-04, March 2015. 1738 [PropertyAliases] 1739 The Unicode Consortium, "PropertyAliases-7.0.0.txt", 1740 Unicode Character Database, November 2013, 1741 . 1744 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1745 "Remote Authentication Dial In User Service (RADIUS)", RFC 1746 2865, DOI 10.17487/RFC2865, June 2000, 1747 . 1749 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1750 Internationalized Strings ("stringprep")", RFC 3454, DOI 1751 10.17487/RFC3454, December 2002, 1752 . 1754 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1755 "Internationalizing Domain Names in Applications (IDNA)", 1756 RFC 3490, DOI 10.17487/RFC3490, March 2003, 1757 . 1759 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 1760 Profile for Internationalized Domain Names (IDN)", RFC 1761 3491, DOI 10.17487/RFC3491, March 2003, 1762 . 1764 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1765 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1766 2003, . 1768 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 1769 Authentication and Security Layer (SASL)", RFC 4422, DOI 1770 10.17487/RFC4422, June 2006, 1771 . 1773 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 1774 (LDAP): Technical Specification Road Map", RFC 4510, DOI 1775 10.17487/RFC4510, June 2006, 1776 . 1778 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 1779 Recommendations for Internationalized Domain Names 1780 (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, 1781 . 1783 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1784 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1785 DOI 10.17487/RFC5226, May 2008, 1786 . 1788 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1789 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1790 RFC5234, January 2008, 1791 . 1793 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1794 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1795 RFC5246, August 2008, 1796 . 1798 [RFC5890] Klensin, J., "Internationalized Domain Names for 1799 Applications (IDNA): Definitions and Document Framework", 1800 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1801 . 1803 [RFC5891] Klensin, J., "Internationalized Domain Names in 1804 Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/ 1805 RFC5891, August 2010, 1806 . 1808 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 1809 Internationalized Domain Names for Applications (IDNA)", 1810 RFC 5892, DOI 10.17487/RFC5892, August 2010, 1811 . 1813 [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts 1814 for Internationalized Domain Names for Applications 1815 (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, 1816 . 1818 [RFC5894] Klensin, J., "Internationalized Domain Names for 1819 Applications (IDNA): Background, Explanation, and 1820 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 1821 . 1823 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1824 Internationalized Domain Names in Applications (IDNA) 1825 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 1826 . 1828 [RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code 1829 Points and Internationalized Domain Names for Applications 1830 (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452, 1831 November 2011, . 1833 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 1834 Problem Statement for the Preparation and Comparison of 1835 Internationalized Strings (PRECIS)", RFC 6885, DOI 1836 10.17487/RFC6885, March 2013, 1837 . 1839 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 1840 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 1841 2013, . 1843 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 1844 Preparation, Enforcement, and Comparison of 1845 Internationalized Strings in Application Protocols", RFC 1846 7564, DOI 10.17487/RFC7564, May 2015, 1847 . 1849 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 1850 Enforcement, and Comparison of Internationalized Strings 1851 Representing Usernames and Passwords", RFC 7613, DOI 1852 10.17487/RFC7613, August 2015, 1853 . 1855 [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence 1856 Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/ 1857 RFC7622, September 2015, 1858 . 1860 [RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison 1861 of Internationalized Strings Representing Nicknames", RFC 1862 7700, DOI 10.17487/RFC7700, December 2015, 1863 . 1865 [RFC7790] Yoneya, Y. and T. Nemoto, "Mapping Characters for Classes 1866 of the Preparation, Enforcement, and Comparison of 1867 Internationalized Strings (PRECIS)", RFC 7790, DOI 1868 10.17487/RFC7790, February 2016, 1869 . 1871 [UAX11] Unicode Standard Annex #11, "East Asian Width", edited by 1872 Ken Lunde. An integral part of The Unicode Standard, 1873 . 1875 [UAX15] Unicode Standard Annex #15, "Unicode Normalization Forms", 1876 edited by Mark Davis and Ken Whistler. An integral part of 1877 The Unicode Standard, . 1879 [UAX9] Unicode Standard Annex #9, "Unicode Bidirectional 1880 Algorithm", edited by Mark Davis, Aharon Lanin, and Andrew 1881 Glass. An integral part of The Unicode Standard, 1882 . 1884 [UTR36] Unicode Technical Report #36, "Unicode Security 1885 Considerations", by Mark Davis and Michel Suignard, 1886 . 1888 [UTS39] Unicode Technical Standard #39, "Unicode Security 1889 Mechanisms", edited by Mark Davis and Michel Suignard, 1890 . 1892 14.3. URIs 1894 [1] http://unicode.org/policies/stability_policy.html 1896 Appendix A. Changes from RFC 7564 1898 The following changes were made from [RFC7564]. 1900 o Recommended the Unicode toLowerCase() operation over the Unicode 1901 toCaseFold() operation in most PRECIS applications. 1903 o Clarified the meaning of "preparation" and described the 1904 motivation for including it in PRECIS. 1906 o Updated references. 1908 See [RFC7613] for a description of the differences from [RFC3454]. 1910 Appendix B. Acknowledgements 1912 Thanks to Martin Duerst, William Fisher, John Klensin, Christian 1913 Schudt, and Sam Whited for their feedback. Thanks to Sam Whited also 1914 for submitting [Err4568]. 1916 See [RFC7564] for acknowledgements related to the specification that 1917 this document supersedes. 1919 Some algorithms and textual descriptions have been borrowed from 1920 [RFC5892]. Some text regarding security has been borrowed from 1921 [RFC5890], [RFC7613], and [RFC7622]. 1923 Authors' Addresses 1925 Peter Saint-Andre 1926 Filament 1928 EMail: peter@filament.com 1929 URI: https://filament.com/ 1931 Marc Blanchet 1932 Viagenie 1933 246 Aberdeen 1934 Quebec, QC G1R 2E1 1935 Canada 1937 EMail: Marc.Blanchet@viagenie.ca 1938 URI: http://www.viagenie.ca/