idnits 2.17.1 draft-iab-rfc-nonascii-02.txt: -(174): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(195): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(358): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(404): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(405): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(406): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(407): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(413): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(414): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 32 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 237: '...me or code point MUST be included in t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 25, 2016) is 2920 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6630' is mentioned on line 221, but not defined == Missing Reference: 'GOST3410' is mentioned on line 410, but not defined == Unused Reference: 'RFC3550' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC6949' is defined on line 571, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-iab-xml2rfc-03 ** Obsolete normative reference: RFC 7564 (Obsoleted by RFC 8264) ** Obsolete normative reference: RFC 7613 (Obsoleted by RFC 8265) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board H. Flanagan, Ed. 3 Internet-Draft RFC Editor 4 Updates: 7322 (if approved) April 25, 2016 5 Intended status: Informational 6 Expires: October 27, 2016 8 The Use of Non-ASCII Characters in RFCs 9 draft-iab-rfc-nonascii-02 11 Abstract 13 In order to support the internationalization of protocols and a more 14 diverse Internet community, the RFC Series must evolve to allow for 15 the use of non-ASCII characters in RFCs. While English remains the 16 required language of the Series, the encoding of future RFCs will be 17 in UTF-8, allowing for a broader range of characters than typically 18 used in the English language. This document describes the RFC Editor 19 requirements and guidance regarding the use of non-ASCII characters 20 in RFCs. 22 This document updates RFC 7322. Please review the PDF version of 23 this draft. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 27, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 3 61 3. Rules for the Use of Non-ASCII Characters . . . . . . . . . . 4 62 3.1. General Usage Throughout a Document . . . . . . . . . . . 4 63 3.2. Person Names . . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Company Names . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Body of the Document . . . . . . . . . . . . . . . . . . 6 66 3.5. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.6. Code Components . . . . . . . . . . . . . . . . . . . . . 9 68 3.7. Bibliographic Text . . . . . . . . . . . . . . . . . . . 9 69 3.8. Keywords and Citation Tags . . . . . . . . . . . . . . . 10 70 3.9. Address Information . . . . . . . . . . . . . . . . . . . 10 71 4. Normalization Forms . . . . . . . . . . . . . . . . . . . . . 11 72 5. XML Markup . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 7. Internationalization Considerations . . . . . . . . . . . . . 11 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. Change log - to be removed by the RFC Editor . . . . . . . . 11 77 9.1. draft-iab-rfc-nonascii-01 to -02 . . . . . . . . . . . . 11 78 9.2. draft-iab-rfc-nonascii-00 to -01 . . . . . . . . . . . . 12 79 9.3. draft-flanagan-nonascii to draft-iab-rfc-nonascii-00 . . 12 80 9.4. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.5. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.6. -02 to -04 . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 Please review the PDF version of this draft. 91 For much of the history of the RFC Series, the character encoding 92 used for RFCs has been ASCII [RFC0020]. This was a sensible choice 93 at the time: the language of the Series has always been English, a 94 language that primarily uses ASCII-encoded characters (ignoring for a 95 moment words borrowed from more richly decorated alphabets); and, 96 ASCII is the "lowest common denominator" for character encoding, 97 making cross-platform viewing trivial. 99 There are limits to ASCII, however, that hinder its continued use as 100 the exclusive character encoding for the Series. The increasing need 101 for easily readable, internationalized content suggests it is time to 102 allow non-ASCII characters in RFCs where necessary. To support this 103 move away from ASCII, RFCs will switch to supporting UTF-8 as the 104 default character encoding and allow support for a broad range of 105 Unicode character support. [UnicodeCurrent] Note that the RFC 106 Editor may reject any codepoint that does not render adequately in 107 enough formats or on in enough rendering engines using the current 108 tooling. 110 Given the continuing goal of maximum readability across platforms, 111 the use of non-ASCII characters should be limited in a document to 112 only where necessary within the text. This document describes the 113 rules under which non-ASCII characters may be used in an RFC. These 114 rules will be applied as the necessary changes are made to submission 115 checking and editorial tools. 117 This document updates the RFC Style Guide [RFC7322]. 119 The details described in this document are expected to change based 120 on experience gained in implementing the RFC production center's 121 toolset. Revised documents will be published capturing those changes 122 as the toolset is completed. Other implementers must not expect 123 those changes to remain backwards-compatible with the details 124 described in this document. 126 2. Basic Requirements 128 Two fundamental requirements inform the guidance and examples 129 provided in this document. They are: 131 o Searches against RFC indexes and database tables need to return 132 expected results and support appropriate Unicode string matching 133 behaviors; 135 o RFCs must be able to display correctly across a wide range of 136 readers and browsers. People whose systems do not have the fonts 137 needed to display a particular RFC need to be able to read the 138 various publication formats and the XML correctly in order to 139 understand and implement the information described in the 140 document. 142 3. Rules for the Use of Non-ASCII Characters 144 This section describes the guidelines for the use of non-ASCII 145 characters in an RFC. If the RFC Editor identifies areas where the 146 use of non-ASCII characters negatively impacts the readability of the 147 text, they will request alternate text. 149 The RFC Editor may, in cases of entire words represented in non-ASCII 150 characters, ask for a set of reviewers to verify the meaning, 151 spelling, characters, and grammar of the text. 153 3.1. General Usage Throughout a Document 155 Where the use of non-ASCII characters is purely as part of an example 156 and not otherwise required for correct protocol operation, escaping 157 the non-ASCII character is not required. Note, however, that as the 158 language of the RFC Series is English, the use of non-ASCII 159 characters is based on the spelling of words commonly used in the 160 English language following the guidance in the Merriam-Webster 161 dictionary [MerrWeb]. 163 The RFC Editor will use the primary spelling listed in that 164 dictionary by default. 166 Example of non-ASCII characters that do not require escaping (the 167 example from Section 3.1.1.12 of RFC4475, with a hex dump replaced by 168 the actual character glyphs) [RFC4475]: 170 This particular response contains unreserved and non-ascii 171 UTF-8 characters. 172 This response is well formed. A parser must accept this message. 173 Message Details : unreason 174 SIP/2.0 200 = 2**3 * 5**2 но сто девяносто девять - простое 175 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 176 Call-ID: unreason.1234ksdfak3j2erwedfsASdf 177 CSeq: 35 INVITE 178 From: sip:user@example.com;tag=11141343 179 To: sip:user@example.edu;tag=2229 Content-Length: 154 180 Content-Type: application/sdp 182 3.2. Person Names 184 Person names may appear in several places within an RFC. When a 185 script outside the Unicode Latin blocks is used for a person name, an 186 author-provided, ASCII-only identifier will appear immediately after 187 the non-Latin characters, surrounded by parentheses. This will 188 improve general readability of the text. [UNICODE-CHART]. 190 Example for the header: 192 Internet Engineering Task Force (IETF) J. Tong 193 Request for Comments: 7380 C. Bi, Ed. 194 Category: Standards Track China Telecom 195 ISSN: 2070-1721 רוני אבן (R. Even) 196 吴钦 (Q. Wu), Ed. 197 R. Huang 198 Huawei 199 November 2014 201 Example for the Acknowledgements: 203 OLD: The following people contributed significant text to early 204 versions of this draft: Patrik Faltstrom, William Chan, and Fred 205 Baker. 207 PROPOSED/NEW: The following people contributed significant text to 208 early versions of this draft: Patrik Fältström, 陈智昌 209 (William Chan), and Fred Baker. 211 Example for References: 213 OLD: 215 [RFC6630] Cao, Z., Deng, H., Wu, Q., and G. Zorn, Ed., "EAP 216 Re-authentication Protocol Extensions for Authenticated 217 Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012. 219 NEW 221 [RFC6630] Cao, Z., Deng, H., 吴钦 (Wu, Q.), and G. Zorn, Ed., "EAP 222 Re-authentication Protocol Extensions for Authenticated 223 Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012. 225 3.3. Company Names 227 Company names may appear in several places within an RFC. In all 228 cases, valid Unicode is required. For names that include characters 229 outside of the Unicode Latin and Latin Extended script, an author- 230 provided, ASCII-only identifier is required to assist in search and 231 indexing of the document. 233 3.4. Body of the Document 235 When the mention of non-ASCII characters is required for correct 236 protocol operation and understanding, the characters' Unicode 237 character name or code point MUST be included in the text. 239 o Non-ASCII characters will require identifying the Unicode code 240 point. 242 o Use of the actual UTF-8 character (e.g., Δ) is encouraged so 243 that a reader can more easily see what the character is, if their 244 device can render the text. 246 o The use of the Unicode character names like "INCREMENT" in 247 addition to the use of Unicode code points is also encouraged. 248 When used, Unicode character names should be in all capital 249 letters. 251 Examples: 253 OLD [RFC7564]: 255 However, the problem is made more serious by introducing the full 256 range of Unicode code points into protocol strings. For example, 257 the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from 258 the Cherokee block look similar to the ASCII characters "STPETER" as 259 they might appear when presented using a "creative" font family. 261 NEW/ALLOWED: 263 However, the problem is made more serious by introducing the full 264 range of Unicode code points into protocol strings. For example, 265 the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 266 (ᏚᎢᎵᎬᎢᎬᏒ) from the Cherokee block look similar to the ASCII 267 characters "STPETER" as they might appear when presented using a 268 "creative" font family. 270 ALSO ACCEPTABLE: 272 However, the problem is made more serious by introducing the full 273 range of Unicode code points into protocol strings. For example, 274 the characters "ᏚᎢᎵᎬᎢᎬᏒ" (U+13DA U+13A2 U+13B5 U+13AC U+13A2 275 U+13AC U+13D2) from the Cherokee block look similar to the ASCII 276 characters "STPETER" as they might appear when presented using a 277 "creative" font family. 279 Example of proper identification of Unicode characters in an RFC: 281 Acceptable: 283 o Temperature changes in the Temperature Control Protocol are 284 indicated by the U+2206 character. 286 Preferred: 288 1. Temperature changes in the Temperature Control Protocol are 289 indicated by the U+2206 character ("Δ"). 291 2. Temperature changes in the Temperature Control Protocol are 292 indicated by the U+2206 character (INCREMENT). 294 3. Temperature changes in the Temperature Control Protocol are 295 indicated by the U+2206 character ("Δ", INCREMENT). 297 4. Temperature changes in the Temperature Control Protocol are 298 indicated by the U+2206 character (INCREMENT, "Δ"). 300 5. Temperature changes in the Temperature Control Protocol are 301 indicated by the "Delta" character "Δ" (U+2206). 303 6. Temperature changes in the Temperature Control Protocol are 304 indicated by the character "Δ" (INCREMENT, U+2206). 306 Which option of (1), (2), (3), (4), (5), or (6) is preferred may 307 depend on context and the specific character(s) in question. All are 308 acceptable within an RFC. BCP 137, "ASCII Escaping of Unicode 309 Character" describes the pros and cons of different options for 310 identifying Unicode characters in an ASCII document BCP137 [BCP137]. 312 3.5. Tables 314 Tables follow the same rules for identifiers and characters as in 315 "Body of the Document" (Section 3.4). If it is sensible (i.e., more 316 understandable for a reader) for a given document to have two tables 317 -- one including the identifiers and non-ASCII characters and a 318 second with just the non-ASCII characters -- that will be allowed on 319 a case-by-case basis. 321 Original text from "Preparation, Enforcement, and Comparison of 322 Internationalized Strings Representing Usernames and Passwords" 323 [RFC7613]. 325 Table 3: A sample of legal passwords 327 +------------------------------------+------------------------------+ 328 | # | Password | Notes | 329 +------------------------------------+------------------------------+ 330 | 12| | ASCII space is allowed | 331 +------------------------------------+------------------------------+ 332 | 13| | Different from example 12 | 333 +------------------------------------+------------------------------+ 334 | 14| <πßå> | Non-ASCII letters are OK | 335 | | | (e.g., GREEK SMALL LETTER | 336 | | | PI, U+03C0) | 337 +------------------------------------+------------------------------+ 338 | 15| | Symbols are OK (e.g., BLACK | 339 | | | DIAMOND SUIT, U+2666) | 340 +------------------------------------+------------------------------+ 341 | 16| | OGHAM SPACE MARK, U+1680, is | 342 | | | mapped to U+0020 and thus | 343 | | | the full string is mapped to | 344 | | | | 345 +------------------------------------+------------------------------+ 347 Preferred text: 349 Table 3: A sample of legal passwords 351 +------------------------------------+------------------------------+ 352 | # | Password | Notes | 353 +------------------------------------+------------------------------+ 354 | 12| | ASCII space is allowed | 355 +------------------------------------+------------------------------+ 356 | 13| | Different from example 12 | 357 +------------------------------------+------------------------------+ 358 | 14| <πß๗> | Non-ASCII letters are OK | 359 | | | (e.g., GREEK SMALL LETTER | 360 | | | PI, U+03C0; LATIN SMALL | 361 | | | LETTER SHARP S, U+00DF; THAI | 362 | | | DIGIT SEVEN, U+0E57) | 363 +------------------------------------+------------------------------+ 364 | 15| | Symbols are OK (e.g., BLACK | 365 | | | DIAMOND SUIT, U+2666) | 366 +------------------------------------+------------------------------+ 367 | 16| | OGHAM SPACE MARK, U+1680, is | 368 | | | mapped to U+0020 and thus | 369 | | | the full string is mapped to | 370 | | | | 371 +------------------------------------+------------------------------+ 372 3.6. Code Components 374 The RFC Editor encourages the use of the U+ notation except within a 375 code component where you must follow the rules of the programming 376 language in which you are writing the code. 378 Code components are generally expected to use fixed-width fonts. 379 Where such fonts are not available for a particular script, the best 380 script- appropriate font will be used for that part of the code 381 component. 383 3.7. Bibliographic Text 385 The reference entry must be in English; whatever subfields are 386 present must be available in ASCII-encoded characters. For 387 references to RFCs and Internet Drafts, the author's name will be 388 included in the reference as listed on the front header of the RFC or 389 Internet Draft. As long as good sense is used, the reference entry 390 may also include non-ASCII characters at the author's discretion and 391 as provided by the author. The RFC Editor may request a review of 392 any non-ASCII reference entry. This applies to both normative and 393 informative references. 395 Example: 397 [GOST3410] "Information technology. Cryptographic data security. 398 Signature and verification processes of [electronic] 399 digital signature.", GOST R 34.10-2001, Gosudarstvennyi 400 Standard of Russian Federation, Government Committee of 401 Russia for Standards, 2001. (In Russian) 403 Allowable addition to the above citation: 404 "Информационная технология. Криптографическая защита 405 информации. Процессы формирования и проверки 406 электронной цифровой подписи", GOST R 34.10-2001, 407 Государственный стандарт Российской Федерации, 2001. 409 Alternatively: 410 [GOST3410] "Information technology. Cryptographic data security. 411 Signature and verification processes of [electronic] 412 digital signature.", GOST R 34.10-2001, Gosudarstvennyi 413 Standard of Russian Federation, Правительственная комиссия 414 России по стандартам (Government Committee of 415 Russia for Standards), 2001. (In Russian) 417 3.8. Keywords and Citation Tags 419 Keywords (as tagged with the element in XML), and citation 420 tags (as defined in the anchor attributes of elements) 421 must be ASCII only. 423 3.9. Address Information 425 The purpose of providing address information, either postal or 426 e-mail, is to assist readers of an RFC to contact the author or 427 authors. Authors may include the official postal address as 428 recognized by their company or local postal service without 429 additional non-ASCII character escapes. If the email address 430 includes non-ASCII characters and is a valid email address at the 431 time of publication, non-ASCII character escapes are not required. 433 Example: 435 Qin Wu (editor) 436 Huawei 437 101 Software Avenue, Yuhua District 438 Nanjing, Jiangsu 210012 439 China 441 Alternate contact information: 442 吴钦 (editor) 443 华为技术有限公司 444 雨花区软件大道101号 445 江苏南京 210012 446 中国 448 ------ 450 Roni Even 451 Huawei 452 14 David Hamelech 453 Tel Aviv 64953 454 Israel 456 Alternate contact information: 457 רוני אבן 458 וואווי 459 דוד המלך 14 460 תל אביב 64953 461 ישראל 463 4. Normalization Forms 465 Authors should not expect normalization forms to be preserved. If a 466 particular normalization form is expected, note that in the text of 467 the RFC. 469 5. XML Markup 471 As described above, use of non-ASCII characters in areas such as 472 email, company name, addresses, and name is allowed. In order to 473 make it easier for code to identify the appropriate ASCII 474 alternatives, authors must include an "ascii" attribute to their XML 475 markup when an ASCII alternative is required. See [I-D.iab-xml2rfc] 476 for more detail on how to tag ASCII alternatives. 478 6. IANA Considerations 480 This document makes no request of IANA. 482 Note to RFC Editor: this section may be removed on publication as an 483 RFC. 485 7. Internationalization Considerations 487 The ability to use non-ASCII characters in RFCs in a clear and 488 consistent manner will improve the ability to describe 489 internationalized protocols and will recognize the diversity of 490 authors. However, the goal of readability will override the use of 491 non-ASCII characters within the text. 493 8. Security Considerations 495 Valid Unicode that matches the expected text must be verified in 496 order to preserve expected behavior and protocol information. 498 9. Change log - to be removed by the RFC Editor 500 9.1. draft-iab-rfc-nonascii-01 to -02 502 Authors, Contributors: section renamed "Person names", text 503 simplified, example of a reference added. 505 Bibliographic Text: added an alternate example for a reference with 506 non-ASCII characters. 508 9.2. draft-iab-rfc-nonascii-00 to -01 510 Code Components: added fixed-width font clarification 512 Authors, Bibliographic info: Clarified requirements for full name, 513 how name will be displayed 515 9.3. draft-flanagan-nonascii to draft-iab-rfc-nonascii-00 517 Changed requirement for all nonASCII names (including company names) 518 to require an ASCII equivalent to requiring it only for non-Latin 519 characters. Extended Latin is also acceptable without an ASCII 520 equivalent. 522 9.4. -04 to -05 524 Keywords: expanded section to include citation tags. 526 Internationalization considerations: reiterated that the use of non- 527 ASCII characters is not automatically guaranteed. 529 9.5. -04 to -05 531 Introduction: added statement regarding document subject to change. 533 Tables: added example. 535 Code: removed placeholder for example. 537 9.6. -02 to -04 539 Introduction and Abstract: change to be clearer about what/why non- 540 ASCII characters are being allowed. 542 XML Markup: section added. 544 10. References 546 [BCP137] Klensin, J., "ASCII Escaping of Unicode Characters", 547 BCP 137, RFC 5137, February 2008, 548 . 550 [I-D.iab-xml2rfc] 551 Hoffman, P., "The "xml2rfc" version 3 Vocabulary", draft- 552 iab-xml2rfc-03 (work in progress), February 2016. 554 [MerrWeb] Merriam-Webster,Inc., "Merriam-Webster's Collegiate 555 Dictionary, 11th Edition", 2009. 557 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 558 RFC 20, DOI 10.17487/RFC0020, October 1969, 559 . 561 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 562 Jacobson, "RTP: A Transport Protocol for Real-Time 563 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 564 July 2003, . 566 [RFC4475] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, 567 J., and H. Schulzrinne, "Session Initiation Protocol (SIP) 568 Torture Test Messages", RFC 4475, DOI 10.17487/RFC4475, 569 May 2006, . 571 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 572 Requirements and Future Development", RFC 6949, 573 DOI 10.17487/RFC6949, May 2013, 574 . 576 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 577 DOI 10.17487/RFC7322, September 2014, 578 . 580 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 581 Preparation, Enforcement, and Comparison of 582 Internationalized Strings in Application Protocols", 583 RFC 7564, DOI 10.17487/RFC7564, May 2015, 584 . 586 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 587 Enforcement, and Comparison of Internationalized Strings 588 Representing Usernames and Passwords", RFC 7613, 589 DOI 10.17487/RFC7613, August 2015, 590 . 592 [UNICODE-CHART] 593 The Unicode Consortium, "The Unicode Standard", 594 2014-present, . 596 [UnicodeCurrent] 597 The Unicode Consortium, "The Unicode Standard", 598 2014-present, . 600 Appendix A. Acknowledgements 602 With many thanks to the members of the IAB i18n program and the RFC 603 Format Design Team. 605 Author's Address 607 Heather Flanagan (editor) 608 RFC Editor 610 Email: rse@rfc-editor.org 611 URI: http://orcid.org/0000-0002-2647-2220