]>

paul.hoffman@icann.org

Internet-Draft The early policy for the RFC Series was that RFCs could only contain characters from the ASCII character set. Later policy, from RFC 7997, allowed more characters and enforced an encoding for RFCs of UTF-8. Since RFC 7997 was published, the IETF community has had much more experience of using non-ASCII characters in RFCs. The policy for the RFC Series is that all displayable text is allowed as long as the reader of an RFC can interpret that text. This document obsoletes RFC 7997. [[ A repository for this draft can be found here. ]]

Introduction This document sets policy for the inclusion of characters in the definitive versions and publication formats of RFCs. It also reaffirms the policy that the encoding format for the RFC Series is UTF-8, . 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 .

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 define in . More terminology about characters and encoding formats can be found in .

Basic Requirements for Text in RFCs RFCs should 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. Searches whose results might include RFCs should return accurate results and support appropriate Unicode string matching behaviors.

Policy for Text in RFCs The policy for the RFC Series is that all displayable text is allowed as long as the reader of an RFC can interpret that text. There are many Unicode characters that obviously cannot be displayed (such as control characters), and many whose ability to be displayed is debatable. If an RFC includes such characters in normative or descriptive text, the RFC needs to also clearly describe the character. The preferred method for describing such characters is using the "U+NNNN" syntax from . 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+NNNN" syntax to describing 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 text 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 based on their lived experiences. These authors can give their names using only ASCII characters, or as Unicode characters and an ASCII interpretation of their name. The RPC policy should be that authors' preferences for display of their names be honored. Company names and geographic names generally do not need ASCII interpretations, 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 and not otherwise required for correct protocol operation, giving the Unicode equivalent of the non-ASCII characters is not required, but it can improve the readability of the RFC. For example, for text that might just say "The value can be followed by a monetary symbol such as ¥ or €", it is likely more beneficial to the reader to instead say "The value can be followed by a monetary symbol such as ¥ (U+00A5) or € (U+20AC)". RFCs are often displayed on systems that use only black and white, 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 the "U+NNNN" syntax. For example, "A color display should be able to differentiate 🔴 (U+1F534), 🟢 (U+1F7E2), and 🔵 (U+1F535)."

IANA Considerations This document contains no IANA considerations.

Security Considerations Valid Unicode that matches the expected text must be verified in order to preserve expected behavior and protocol information.

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. The Unicode Consortium

Acknowledgements This document is based on that 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. This current document was greatly helped by contributions from the RFC Series Working Group (RSWG), including from Brian Carpenter, Carsten Bormann, Eliot Lear, John Levine, and Martin Thomson.