]>

paul.hoffman@icann.org

Internet-Draft This document sets policy for the inclusion of characters in the definitive versions and publication formats of RFCs. The policy for the RFC Series is that all displayable text is allowed as long as there is a high expectation that readers of an RFC will be able to interpret its text as intended. This document obsoletes RFC 7997.

Introduction The early policy for the RFC Series was that RFCs could only contain characters from the ASCII character set. Later policies, from , allowed more characters, set the language of the RFC Series to be English, and set the encoding for RFCs of UTF-8. In the time since was published, the IETF community has had much more experience of using non-ASCII characters in RFCs. This document obsoletes . This document makes substantial changes to the policies in based on the positive experience since its publication. The RFC Publication Center (RPC) is responsible for implementing the policies in this document, as described in . The RPC style guides may define which characters authors may use and how they are used.

Terminology The term "non-ASCII characters" means characters outside the set that was defined in ASCII. ASCII is described in . The term "Unicode characters" means characters defined in . "U+ notation" means using the characters "U+" and a hexadecimal number to represent a Unicode code point. See for more on U+ notation. More terminology about characters and encoding formats can be found in .

Basic Requirements for Text in RFCs RFCs should only contain text that can be displayed correctly across a wide range of readers and browsers. People whose systems do not have the fonts needed to display part of a particular RFC still need to be able to read the definitive versions and publication formats correctly in order to understand and implement the information described in the document. The ability to use non-ASCII characters in RFCs in a clear and consistent manner will allow the correct display of proper names and improve the ability to describe internationalized protocols. Apart from their role in proper names, non-ASCII characters should be used only when they enhance the technical content and accuracy of the document.

Policy for Text in RFCs English is the required language of RFCs. However, because non-ASCII characters are often required for instances including proper names and examples, the policy for the RFC Series is that all displayable text is allowed as long as there is a high expectation that readers of an RFC will be able to interpret its text as intended. Apart from their role in proper names, non-ASCII characters should be used only when they enhance the technical content and accuracy of the document. There are some Unicode characters that cannot be displayed (such as control and whitespace characters). Additionally, many characters are also not widely available in the font packages that are available to viewers. Although HTML and PDF formats render any character that has a glyph, that can involve additional steps in preparation. The text publication format of an RFC, as well as excerpts copied from an RFC, are displayed using the font packages supplied by the viewer, which might not include the necessary glyphs. RFCs need to include descriptions of any such characters. The preferred method for describing such characters is using the U+ notation from and/or using the character's official name from the Unicode Standard . describes the pros and cons of different options for identifying Unicode characters and may help authors decide how to represent the non-ASCII characters in their documents. Note that this policy only applies to normative or descriptive text; text such as names does not need character description. Further, some RFC authors might choose to use something other than the U+ notation to describe characters, such as if the RFC already covers a different syntax that the reader will understand from the rest of the RFC. Characters in an RFC will generally appear in Normalization Form C (NFC) as defined in . If the RFC would be more correct and more understandable with particular characters not in NFC, the RPC can use unnormalized text. In such a case, a note should be included to describe why unnormalized text was used.

Names Authors of RFCs whose names include non-ASCII characters will likely have preferences for how their names are displayed. If the author's preferred name is in a non-Latin script, they must also provide an alternate name in Latin script. Authors' preferences for display of their names should be honored. Company names and geographic names generally do not need Latin alternates, but they can be included at the discretion of the author and the RPC.

Examples Where the use of non-ASCII characters is purely part of an example or not otherwise required for correct protocol operation, giving the Unicode code points and Unicode names of the non-ASCII characters is not required, but it can improve the readability of the RFC. An RFC can use either or both forms, whichever is sensible in the circumstance. For example, for text that might just say "The value can be followed by a monetary symbol such as ¥ or €", text that says one of the following is likely more beneficial to the reader: The value can be followed by a monetary symbol such as ¥ (U+00A5) or € (U+20AC) The value can be followed by a monetary symbol such as ¥ (YEN SIGN) or € (EURO SIGN) The value can be followed by a monetary symbol such as ¥ (U+00A5, YEN SIGN) or € (U+20AC, EURO SIGN) RFCs may be viewed using only black and white or grayscale, particularly when printed. Because of this, examples should generally use characters that do not specify a color. However, some examples might require text with color due to the nature of the examples. If so, those examples need to also include U+ notation. For example, "A color display should be able to differentiate 🔴 (U+1F534, LARGE RED CIRCLE), 🟢 (U+1F7E2, LARGE GREEN CIRCLE), and 🔵 (U+1F535, LARGE BLUE CIRCLE)."

RFC Publication Language The RFC publication language is English.

RFC Publication Encoding The encoding format for the RFC Series is UTF-8 .

IANA Considerations This document contains no IANA considerations.

Security Considerations Authors and the RPC should cross-check that the used characters match their code point numbers or Unicode character names.

There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs. This document updates RFC 7322. Please view this document in PDF form to see the full text. In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published. This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280. The Unicode Consortium This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice. In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.

Acknowledgements This document is based on which was authored by Heather Flanagan. The acknowledgements from are to the members of the IAB i18n program, to the RFC Format Design Team: Nevil Brownlee, Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks, and Dave Thaler. Writing this document was greatly helped by contributions from the RFC Series Working Group (RSWG), including: Brian Carpenter, Carsten Bormann, Eliot Lear, John Klensin, John Levine, Martin Dürst, Martin Thomson, Pete Resnick, Rob Sayre, and Russ Housley.