Network Working Group H. Flanagan Internet-Draft RFC Editor Intended status: Informational February 14, 2014 Expires: August 18, 2014 The Use of Non-ASCII Characters in RFCs draft-flanagan-nonascii-00 Abstract This document lays out the requirements regarding the use of non- ASCII characters in RFCs. It includes examples for the different sections of an RFC. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 18, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Flanagan Expires August 18, 2014 [Page 1] Internet-Draft Non-ASCII RFCs February 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Basic requirements . . . . . . . . . . . . . . . . . . . . . 2 3. Rules for the use of non-ASCII characters . . . . . . . . . . 3 3.1. General usage throughout a document . . . . . . . . . . . 3 3.2. Author Names . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Body of the document . . . . . . . . . . . . . . . . . . 4 3.4. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Code components . . . . . . . . . . . . . . . . . . . . . 5 3.6. Bibliographic text . . . . . . . . . . . . . . . . . . . 5 3.7. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Normalization Forms . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Internationalization Considerations . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 10. Informative References . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction For much of the history of the RFC Series, the character encoding used has been US-ASCII [ASCII]. This was a sensible choice at the time: the language of the Series is English, a language which only uses US-ASCII-encoded characters (ignoring for a moment words borrowed from more richly decorated alphabets). US-ASCII is the "lowest common denominator" for character encoding, making cross- platform viewing trivial. There are limits to US-ASCII, however, which hinder its continued use as the exclusive character encoding for the Series. The increasing need for easily readable, internationalized content suggests it is time to allow non-ASCII characters in RFCs where necessary. Given the continuing goal of maximum readability across platforms, the use of non-ASCII should not be gratuitous in a document. This RFC describes the rules under which non-ASCII characters may be used in an RFC. These rules will be applied as the necessary changes are made to submission checking and editorial tools. 2. Basic requirements Three fundamental requirements inform the guidance and examples provided in this document. They are: Flanagan Expires August 18, 2014 [Page 2] Internet-Draft Non-ASCII RFCs February 2014 o Searches of an index need to be able to find multiple ways of writing an author's name; o People whose system does not have the fonts needed to display a particular RFC need to be able to read the non-canonical HTML, text, or PDF RFC correctly. 3. Rules for the use of non-ASCII characters 3.1. General usage throughout a document The mention, as opposed to the use, of non-ASCII characters requires the use of Unicode identifiers. Including non-ASCII characters in the text is encouraged to make the mention clearer to readers with devices that can render the non-ASCII text. Including Unicode character names is allowed. The distinction is between an occasion in which a word appears in a sentence in order to convey the meaning of that word (use), and an occasion in which a word appears in order to make some point about that word itself (mention). Spelling for words commonly used in the English language will follow the guidance in the Mirriam-Webster dictionary. Other uses, including archaic or untraditional spellings, are not allowed. Example: Use: SIP/2.0 200 = 2**3 * 5**2 но сто девяносто девять - простое Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 Call-ID: unreason.1234ksdfak3j2erwedfsASdf CSeq: 35 INVITE From: sip:user@example.com;tag=11141343 To: sip:user@example.edu;tag=2229 Content-Length: 154 Content-Type: application/sdp Mention: For example, the characters "ᏚᎢᎵᎬᎢᎬᏒ" (U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2) from the Cherokee block look similar to the ASCII characters "STPETER" as they might look when presented using a "creative" font family. 3.2. Author Names Flanagan Expires August 18, 2014 [Page 3] Internet-Draft Non-ASCII RFCs February 2014 Valid Unicode is required, and for non-ASCII names, an ASCII-only identifier is required. Example for the header: Network Working Group L. Daigle Request for Comments: 2611 Thinking Cat Enterprises BCP: 33 D. van Gulik Category: Best Current Practice ISIS/CEO, JRC Ispra R. Iannella DSTC Pty Ltd P. Faeltstroem (P. Faltstrom) Tele2/Swipnet June 1999 Example for the Acknowledgements: OLD: The following people contributed significant text to early versions of this draft: Patrik Faltstrom, William Chan, and Fred Baker. PROPOSED/NEW: The following people contributed significant text to early versions of this draft: Patrik Faeltstroem (Patrik Faltstrom), 陈智昌 (William Chan), and Fred Baker. 3.3. Body of the document Non-ASCII characters may be used only where necessary to clearly express the intended meaning of the text. When such characters are mentioned in the text, the following rules apply: o Non-ASCII characters will require identifying the codepoint (e.g. U+0394) o Use of the actual UTF-8 character (e.g., Δ) is encouraged so that a reader can more easily see what the character is, if their device can render the text. o If preferred by the author(s), the use of the official character names like "Greek Capital Letter Delta" is allowed. Examples: OLD (draft-ietf-precis-framework): However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the Cherokee block look similar to the ASCII characters "STPETER" as they might look when presented using a "creative" font family. NEW/ALLOWED: However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For Flanagan Expires August 18, 2014 [Page 4] Internet-Draft Non-ASCII RFCs February 2014 example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 (ᏚᎢᎵᎬᎢᎬᏒ) from the Cherokee block look similar to the ASCII characters "STPETER" as they might look when presented using a "creative" font family. ALSO ACCEPTABLE: However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For example, the characters "ᏚᎢᎵᎬᎢᎬᏒ" (U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2) from the Cherokee block look similar to the ASCII characters "STPETER" as they might look when presented using a "creative" font family. 3.4. Tables Tables follow the same rules for identifiers and characters as the body. If it is sensible (i.e., more understandable for a reader) for a given document to have two tables, one including the identifiers and characters, one with just the characters, that will be allowed on a case by case basis. Example: TBD 3.5. Code components Use the U+ notation except within a code component where you must follow the rules of the programming language in which you are writing the code Example: TBD 3.6. Bibliographic text The reference entry must be in English; whatever subfields are present must be available in ASCII. As long as good sense is used, they may also include non-ASCII characters at author discretion. This applies to both normative and informative references. Example: [GOST3410] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of Russian Federation, Government Committee of Russia for Standards, 2001. (In Russian) Allowable addition to the above citation "Инфо ;рмационнаn Flanagan Expires August 18, 2014 [Page 5] Internet-Draft Non-ASCII RFCs February 2014 3; технологи 103;. Криптогра фическая защита инфl 6;рмации. Процессы фl 6;рмировани 03; и проверки электронно ;й цифровой подписи ", GOST R 34.10-2001, Государс& #1090;венный стандарт Рl 6;ссийской Федерации, 2001. 3.7. Keywords Keywords must be US-ASCII only. 4. Normalization Forms If the normalization matters to the content, the authors must submit in a normalization-resistant form. In other words, authors should not expect normalization forms to be preserved. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Internationalization Considerations TBD 7. Security Considerations 8. Acknowledgements With many thanks to the members of the IAB i18n program. 9. Normative References Flanagan Expires August 18, 2014 [Page 6] Internet-Draft Non-ASCII RFCs February 2014 10. Informative References [ASCII] American National Standard for Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII), ANSI X3.4- 1986, American National Standards Institute, Inc., March 26, 1986. 11. References Author's Address Heather Flanagan RFC Editor Email: rse@rfc-editor.org Flanagan Expires August 18, 2014 [Page 7]