<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc []>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-bray-unichars-15" number="9839" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="Unicode Subsets">Unicode Character Repertoire Subsets</title>
    <seriesInfo name="RFC" value="9839"/>
    <author initials="T." surname="Bray" fullname="Tim Bray">
      <organization>Textuality Services</organization>
      <address>
	<email>tbray@textuality.com</email>
      </address>
    </author>

    <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
      <organization>ICANN</organization>
      <address>
	<email>paul.hoffman@icann.org</email>
      </address>
    </author>

<date/>
<keyword>Internet-Draft</keyword>

    <date month="August" year="2025"/>

    <area>ART</area>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

<abstract>
<t>This document discusses subsets of the Unicode character repertoire for use in protocols and data formats, formats and specifies three subsets recommended for use in IETF specifications.</t>
</abstract>
</front>

<middle>

<section anchor="intro" title="Introduction"> anchor="intro">
  <name>Introduction</name>
<t>Protocols and data formats frequently contain or are made up of textual data.
Such text is normally composed of Unicode <xref target="UNICODE"/> characters, to support use by speakers of many languages.
Unicode characters are represented by numeric code points, and the "set of all Unicode code points" is generally not a good choice for use in text fields.
Unicode recognizes different types of code points, not all of which are appropriate in protocols, protocols or even associated with characters.
Therefore, even if the desire is to support "all Unicode characters" characters", a subset of the Unicode code point repertoire should be specified.
Subsets such as those discussed in this document are appropriate choices when more-specific limitations do not apply.</t>

<t>In this document, "subset" means a subset of the Unicode character repertoire.
This document specifies subsets that exclude some or all of the code points that are "problematic" as defined in <xref target="problematic"/>.
Authors should have a way to concisely and exactly reference a stable specification that identifies which subset a protocol or data format accepts.</t>

<t>This document discusses issues that apply in choosing subsets, names two subsets that have been popular in practice, and suggests one new subset.
The intended use is to serve as a convenient target for cross-reference from other specifications whose authors wish to exclude problematic code points from the data format or protocol being specified.</t>

<t>Note that this document only provides guidance on avoiding the use of code points which that cannot be used for interoperable interchange of Unicode textual data.
Dealing with strings, particularly in the context of user interfaces, requires addressing language, text rendering direction, alternate representations of the same abstract character, and so on.
These issues, among many others, led to many efforts by the Unicode Consortium,
IETF
efforts like by the IETF such as <xref target="IDN"/> and <xref target="PRECIS"/>,
and W3C internationalization efforts by W3C such as <xref target="W3C-CHAR"/>.
The results of these efforts should be consulted by anyone engaging in such work.</t>

<section anchor="notation" title="Notation"> anchor="notation">
  <name>Notation</name>

<t>In this document, the numeric values assigned to Unicode characters are provided in hexadecimal.
This document uses Unicode's standard notation of "U+" followed by four or more hexadecimal digits.
For example, "A", decimal 65, is expressed as U+0041, and "🖤" (Black Heart), decimal 128,420, is U+1F5A4.</t>

<t>Groups of numeric values described in <xref target="subsets"/> are given in ABNF <xref target="RFC5234"/>.
In ABNF, hexadecimal values are preceded by "%x" rather than "U+".</t>

<t>All the numeric ranges in this document are inclusive.</t>

<t>The subsets are described in ABNF.</t>

</section>

</section>

<section anchor="char-concepts" title="Characters anchor="char-concepts">
  <name>Characters and Code Points"> Points</name>

<t>Definition D9 in section Section 3.4 of <xref target="UNICODE"/> defines "Unicode codespace" as "a range of integers from 0 to 10FFFF<sub>16</sub>".
Definition D10 defines "code point" as "Any value in the Unicode codespace".</t>

<t>The Unicode Standard's definition of "Unicode character" is conceptual.
However, each Unicode character is assigned a code point, used to represent the characters in computer memory and storage systems and, in specifications, and to specify allowed subsets.</t>

<t>There subsets in specifications.</t>

<!--[rfced] FYI: In Section 2, we updated the enlarged "⨉" to "*"
for multiplication as the enlarged "⨉" is not used in the RFC
Series. If "x" (lowercase) is preferred instead of "*", please
let us know.

Original:
   There are 1,114,112 (17 ⨉ 2^16) code points;...

Current:
   There are 1,114,112 (17 * 2^16) code points;...
-->

<t>There are 1,114,112 (17 * 2<sup>16</sup>) code points; as of Unicode 16.0 (2024), about 155,000 have been assigned to characters.

Since unassigned code points regularly become assigned when new characters are added to Unicode, it is usually not a good practice to specify that unassigned code points should be avoided.</t>

<section anchor="encoding" title="Encoding forms"> anchor="encoding">
  <name>Encoding Forms</name>

<!--[rfced] Please clarify this sentence - does option A or B capture
the intended meaning, or do you prefer otherwise?

Original:
   Unicode describes a variety of encoding forms, ways to marshal code
   points into byte sequences.

Perhaps A:
   Unicode describes a variety of encoding forms and ways to
   marshal code points into byte sequences.

Perhaps B:
   Unicode describes a variety of encoding forms that can be used to
   marshal code points into byte sequences.
-->

<t>Unicode describes a variety of encoding forms, ways to marshal code points into byte sequences.
A survey of these is beyond the scope of this document.
However, it is useful to note that "UTF-16" represents each code point with one or two 16-bit chunks, while "UTF-8" uses variable-length byte sequences <xref target="RFC3629"/>.</t>

<t>The "IETF Policy on Character Sets and Languages", BCP 18 <xref target="RFC2277"/>, says "Protocols MUST <bcp14>MUST</bcp14> be able to use the UTF-8 charset", which becomes a mandate to use UTF-8 for any protocol or data format that specifies a single encoding form.
UTF-8 is widely used for interoperable data formats such as JSON, YAML, CBOR, and XML.</t>

</section>

<section anchor="problematic" title="Problematic anchor="problematic">
  <name>Problematic Code Points"> Points</name>

<t>This section classifies as "problematic" all the code points which that can never represent useful text and and, in some cases cases, can lead to software misbehavior. misbehavior as "problematic".
This is a low bar; the PRECIS <xref target="RFC8264"/> framework's "IdentifierClass" and "FreeformClass" exclude many more code points which that can cause problems when displayed to humans, in some cases presenting security risks.
Specifications of fields in protocols and data formats whose contents are designed for display to and interactions with humans would benefit from careful consideration of the issues described by PRECIS; its more-restrictive subsets might be better choices than those specified in this document.</t>

<t>Definition D10a in section Section 3.4 of <xref target="UNICODE"/> defines seven code point types.
Three types of code points are assigned to entities which that are not actually characters or whose value as Unicode characters in text fields is questionable: "Surrogate", "Control", and "Noncharacter".
In this document, "problematic" refers to code points whose type is "Surrogate" or "Noncharacter", "Noncharacter" and to "legacy controls" as defined in <xref target="legacy-controls"/> below.</t>

<t>Unicode's definition

<t>Definition D49 in <xref target="UNICODE"/> concerns the "private-use" type type, and section Section 3.5.10 states that they "are considered to be assigned characters".
Section 23.5 further states that these characters' "use may be determined by private agreement among cooperating users".
Because private-use code points may have uses based on private agreements, this document does not classify them as "problematic".</t>

<section anchor="surrogates" title="Surrogates"> anchor="surrogates">
  <name>Surrogates</name>

<t>A total of 2,048 code points, in the range U+D800-U+DFFF, is are divided into two blocks called "high surrogates" and "low surrogates"; collectively collectively, the 2,048 code points are referred to as "surrogates".
Section 23.6 of <xref target="UNICODE"/> section 23.6 specifies how surrogates may be used in Unicode texts encoded in UTF-16,
where a high-surrogate/low-surrogate pair represents a code point greater than U+FFFF.</t>

<t>A surrogate which that occurs in text encoded in any encoding form other than UTF-16 has no meaning.
In particular, Section 3.9.3 of <xref target="UNICODE"/> section 3.9.3 forbids representing a surrogate in UTF-8.</t>

</section>

<section anchor="controls" title="Control Codes"> anchor="controls">
  <name>Control Codes</name>

<t>Section 23.1 of <xref target="UNICODE"/> introduces the control codes for compatibility with legacy pre-Unicode standards.
They comprise 65 code points in the ranges U+0000-U+001F ("C0 controls") and U+0080-U+009F ("C1 controls"), plus U+007F, "DEL".</t>

<section anchor="useful-controls" title="Useful Controls"> anchor="useful-controls">
  <name>Useful Controls</name>
<t>The C0 controls include newline (U+000A), carriage return (U+000D), and tab (U+0009); this document refers to these three characters as the "useful controls".</t>
</section>

<section anchor="legacy-controls" title="Legacy Controls"> anchor="legacy-controls">
  <name>Legacy Controls</name>

<t>Aside from the useful controls,  both the C0 and C1 control codes are mostly obsolete and generally lack interoperable semantics.
This document uses the phrase "legacy controls" to describe control codes that are not useful controls.</t>

<t>Because the code points for C0 controls include the 32 smallest integers including zero, they are likely to occur in data as a result of programming errors.</t>

</section>

</section>

<section anchor="noncharacters" title="Noncharacters"> anchor="noncharacters">
  <name>Noncharacters</name>

<t>Certain code points are classified as "noncharacters", and <xref target="UNICODE"/> asserts repeatedly that they are not designed or used for open interchange.</t>

<t>Code points are organized into 17 "planes", each containing 2<sup>16</sup> code points.
The last two code points in each plane are noncharacters: U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, and so on, up to U+10FFFE, U+10FFFF.</t>

<t>The code points in the range U+FDD0-U+FDEF are noncharacters.</t>

</section>
</section>
</section>

<section anchor="dealing" title="Dealing With anchor="dealing">
  <name>Dealing with Problematic Code Points"> Points</name>

<t><xref target="RFC9413"/>, "Maintaining Robust Protocols", provides a thorough discussion of strategies for dealing with issues in input data.</t>

<t>Different types of problematic code points cause different issues.
Noncharacters and legacy controls are unlikely to cause software failures, but they cannot usefully be displayed to humans, and they can be used in attacks based on attempting to display text that includes them.</t>

<t>The behavior of software which that encounters surrogates is unpredictable and differs among programming-language implementations, even between different API calls in the same language.</t>

<t>Section 3.9 of <xref target="UNICODE"/> makes it clear that a UTF-8 byte sequence which that would map to a surrogate is ill-formed.
If a specification requires that input data be encoded with UTF-8, and if all input were well-formed, implementors would never have to concern themselves with surrogates.</t>

<t>Unfortunately, industry experience teaches that problematic code points, including surrogates, can and do occur in program input where the source of input data is not controlled by the implementor.
In particular, the specification of JSON allows any code point to appear in object member names and string values <xref target="RFC8259"/>.</t>
<t>For example, the following is a conforming JSON text:</t>

<sourcecode>{"example": "\u0000\u0089\uDEAD\uD9BF\uDFFF"}</sourcecode>

<sourcecode type="json"><![CDATA[{"example": "\u0000\u0089\uDEAD\uD9BF\uDFFF"}]]></sourcecode>

<t>The value of the "example" field contains the C0 control NUL, the C1 control "CHARACTER TABULATION WITH JUSTIFICATION", an unpaired surrogate, and the noncharacter U+7FFFF encoded per JSON rules as two escaped UTF-16 surrogate code points as described in <xref target="RFC8259"/> section 7. target="RFC8259" section="7"/>.
It is unlikely to be useful as the value of a text field.
That value cannot be serialized into well-formed UTF-8, but the behavior of libraries asked to parse the sample is unpredictable; some will silently parse this and generate an ill-formed UTF-8 string.</t>

<t>Two reasonable options for dealing with problematic input are either rejecting text containing problematic code points, points or replacing the problematic code points with placeholders.</t>

<t>Silently deleting an ill-formed part of a string is a known security risk.
Responding to that risk, Section 3.2 of <xref target="UNICODE"/> section 3.2 recommends dealing with ill-formed byte sequences by signaling an error, error or replacing problematic code points, ideally with "�" (U+FFFD, REPLACEMENT CHARACTER).</t>

</section>

<section anchor="subsets" title="Subsets"> anchor="subsets">
  <name>Subsets</name>

<t>This section describes three increasingly restrictive subsets that can be used in specifying acceptable content for text fields in protocols and data types.
Specifications can refer to these subsets by the names "Unicode Scalars", "XML Characters", and "Unicode Assignables".</t>

<section anchor="scalars" title="Unicode Scalars"> anchor="scalars">
  <name>Unicode Scalars</name>

<t>Definition D76 in section Section 3.9 of <xref target="UNICODE"/> defines the term "Unicode scalar value" as "Any Unicode code point except high-surrogate and low-surrogate code points."</t> points".</t>

<t>The "Unicode Scalars" subset can be expressed as an ABNF production:</t>

<sourcecode>

<sourcecode type="abnf"><![CDATA[
unicode-scalar =
   %x0-D7FF /    ; exclude surrogates
   %xE000-10FFFF
</sourcecode>
]]></sourcecode>

<t>This subset is the default for CBOR Concise Binary Object Representation (CBOR) <xref target="RFC8949"/>, target="RFC8949"/> and has the advantage of excluding surrogates.
However, it includes legacy controls and noncharacters.</t>

</section>

<section anchor="xml" title="XML Characters"> anchor="xml">
  <name>XML Characters</name>

<t>The XML 1.0 Specification <xref target="XML"/>, in its grammar production labeled "Char", specifies a subset of Unicode code points that excludes surrogates, legacy C0 controls, and the noncharacters U+FFFE and U+FFFF.</t>

<t>The "XML Characters" subset can be expressed as an ABNF production:</t>

<!--
#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
-->
<sourcecode>

<!--[rfced] AD: As requested by the authors, we made the following
update within the sourcecode in Section 2 (see the last
line). Please review and provide your approval of this change.

Original:
 xml-character =
    %x9 / %xA / %xD /   ; useful controls
    %x20-D7FF /         ; exclude surrogates
    %xE000-FFFD /       ; exclude FFFE and FFFF nonchars
    %x100000-10FFFF
</sourcecode>

Current:
 xml-character =
    %x9 / %xA / %xD /   ; useful controls
    %x20-D7FF /         ; exclude surrogates
    %xE000-FFFD /       ; exclude FFFE and FFFF nonchars
    %x10000-10FFFF
-->

<sourcecode type="abnf"><![CDATA[
xml-character =
   %x9 / %xA / %xD /   ; useful controls
   %x20-D7FF /         ; exclude surrogates
   %xE000-FFFD /       ; exclude FFFE and FFFF nonchars
   %x10000-10FFFF
]]></sourcecode>

<t>While this subset does not exclude all the problematic code points, the C1 controls are less likely than the C0 controls to appear erroneously in data, data and have not been observed to be a frequent source of problems.
Also, the noncharacters greater in value than U+FFFF are rarely encountered.</t>

</section>

<section anchor="unicode-assignables" title="Unicode Assignables"> anchor="unicode-assignables">
  <name>Unicode Assignables</name>

<t>This document defines the "Unicode Assignables" subset as all the Unicode code points that are not problematic.
This, a proper subset of each of the others, comprises all code points that are currently assigned, excluding legacy control codes, or that might in future be assigned.</t> assigned in the future.</t>

<t>Unicode Assignables can be expressed as an ABNF production:</t>

<sourcecode>

<sourcecode type="abnf"><![CDATA[
unicode-assignable =
   %x9 / %xA / %xD /               ; useful controls
   %x20-7E /                       ; exclude C1 controls and DEL
   %xA0-D7FF /                     ; exclude surrogates
   %xE000-FDCF /                   ; exclude FDD0 nonchars
   %xFDF0-FFFD /                   ; exclude FFFE and FFFF nonchars
   %x10000-1FFFD / %x20000-2FFFD / ; (repeat per plane)
   %x30000-3FFFD / %x40000-4FFFD /
   %x50000-5FFFD / %x60000-6FFFD /
   %x70000-7FFFD / %x80000-8FFFD /
   %x90000-9FFFD / %xA0000-AFFFD /
   %xB0000-BFFFD / %xC0000-CFFFD /
   %xD0000-DFFFD / %xE0000-EFFFD /
   %xF0000-FFFFD / %x100000-10FFFD
</sourcecode>
]]></sourcecode>

</section>
</section>

<section anchor="restricting" title="Using Subsets"> anchor="restricting">
  <name>Using Subsets</name>

<t>Many IETF specifications rely on well-known data formats such as JSON, I-JSON, Internet JSON (I-JSON), CBOR, YAML, and XML.
These formats specify default subsets.
For example, JSON allows object member names and string values to include any Unicode code point, including all the problematic types.</t>

<t>A protocol based on JSON can be made more robust and implementor-friendly by restricting the contents of object member names and string values to one of the subsets described in <xref target="subsets"/>.
Equivalent restrictions are possible for other packaging formats such as I-JSON, XML, YAML, and CBOR.</t>

<t>Note that escaping techniques such as those in the JSON example in <xref target="dealing"/> cannot be used to circumvent this sort of restriction, which applies to data content, not textual representation in packaging formats.

<!--[rfced] FYI: As requested by the authors, we made the following
update in Section 6:

Original:
   ...the example would remain a conforming JSON Text but...

Current:
   ...the example would remain a conforming JSON text but...
-->

If a specification restricted a JSON field value to the Unicode Assignables, the example would remain a conforming JSON Text text but the data it represents would not constitute Unicode Assignable code points.</t>

</section>

<section anchor="iana-considerations" title="IANA Considerations"> anchor="iana-considerations">
  <name>IANA Considerations</name>

<t>This document has no actions for IANA.</t> IANA actions.</t>

</section>

<section anchor="security-considerations" title="Security Considerations"> anchor="security-considerations">
  <name>Security Considerations</name>

<t><xref target="dealing"/> of this document discusses security issues.</t>

<t>Unicode Security Considerations <xref target="TR36"/> is a wide-ranging survey of the issues implementors should consider while writing software to process Unicode text.
Unicode Source Code Handling <xref target="TR55"/> discusses use of Unicode in programming languages, with a focus on security issues.
Many of the attacks they discuss are aimed at deceiving human readers, but vulnerabilities involving issues such as surrogates and noncharacters are also covered, and covered and, in fact fact, can contribute to human-deceiving exploits.</t>

<t>The Security Considerations security considerations in Section 12 of <xref target="RFC8264"/> target="RFC8264" section="12"/> generally applies apply to this document as well.</t>

<t>Note that the Unicode-character subsets specified in this document are increasingly restrictive, omitting more and more problematic code points, and thus should be less and less susceptible to many of these exploits.
The subset in <xref target="unicode-assignables"/> subset, target="unicode-assignables"/>, "Unicode Assignables", excludes all of these code points.</t>

</section>

</middle>

<back>
<references title="Normative References">
<references>
  <name>References</name>
<references>
  <name>Normative References</name>

<reference anchor="UNICODE" target="http://www.unicode.org/versions/latest/">
<front>
<title abbrev="Unicode">The Unicode Standard</title>
<author><organization>The Unicode Consortium</organization><address /></author>
</front>
<annotation>Note that this reference is to the latest version of
Unicode, rather than to a specific release. It is not expected that
future changes in the Unicode Standard will affect the referenced
definitions.</annotation>
</reference>

<reference anchor="TR36" target="https://www.unicode.org/reports/tr36/">
<front>
<title abbrev="Unicode Security Considerations">Unicode Security Considerations</title>
<author><organization>The Unicode Consortium</organization><address /></author>
<author fullname="Mark Davis" role="editor"/>
<author fullname="Michel Suignard" role="editor"/>
</front>
<annotation>Note that this reference is to the latest version of
this document, rather than to a specific release. It is not expected that
future updates will affect the referenced discussions.</annotation>
</reference>

<reference anchor="TR55" target="https://www.unicode.org/reports/tr55/">
<front>
<title abbrev="Unicode Source Code Handling">Unicode Source Code Handling</title>
<author><organization>The Unicode Consortium</organization><address /></author>
<author fullname="Robin Leroy" role="editor"/>
<author fullname="Mark Davis" role="editor"/>
</front>
<annotation>Note that this reference is to the latest version of
this document, rather than to a specific release. It is not expected that
future updates will affect the referenced discussions.</annotation>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>

</references>

<references title="Informative References">

<references>
  <name>Informative References</name>

<reference anchor="IDN" target="https://datatracker.ietf.org/group/idn/">
<front>
<title>Internationalized Domain Name Working Group</title>
<author><organization></organization></author><date/>
</front>
</reference>

<reference anchor="PRECIS" target="https://datatracker.ietf.org/group/precis/">
<front>
<title>PRECIS Working Group</title>
<author><organization></organization></author><date/>
</front>
</reference>

<reference anchor="W3C-CHAR" target="https://www.w3.org/International/articles/definitions-characters/">
<front>
<title>Character encodings: Essential concepts</title>
<author><organization>W3C</organization></author><date/>
</front>
</reference>

<reference anchor="XML" target="http://www.w3.org/TR/2008/REC-xml-20081126/">
<front>
<title abbrev="XML 1.0">Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author fullname="Tim Bray" surname="Bray"><organization>Textuality surname="Bray" role="editor"><organization>Textuality and Netscape</organization></author>
<author fullname="Jean Paoli" surname="Paoli"><organization>Microsoft</organization></author> surname="Paoli" role="editor"><organization>Microsoft</organization></author>
<author fullname="C.M. Sperberg-McQueen" initials="C.M." surname="McQueen"><organization>W3C</organization></author> surname="McQueen" role="editor"><organization>W3C</organization></author>
<author fullname="Eve Maler" surname="Maler"><organization>Sun surname="Maler" role="editor"><organization>Sun Microsystems, Inc.</organization></author>
<author fullname="François Yergeau" surname="Yergeau"></author> surname="Yergeau" role="editor"></author>
<date year='2008' month='November' day='26'/>
</front>
<refcontent>W3C Recommendation</refcontent>
<annotation>Note that this reference is to a specific release, based on a history of previous "Edition" releases having changed this production.</annotation>
</reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2277.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8264.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9413.xml"/>

</references>
</references>

<section numbered="false" anchor="acknowledgements" title="Acknowledgements"> anchor="acknowledgements">
  <name>Acknowledgements</name>

<t>Thanks are due to Guillaume Fortin-Debigaré, <contact fullname="Guillaume Fortin-Debigaré"/>, who
filed an Errata Report errata report against RFC 8259, The "The JavaScript Object Notation, Notation (JSON) Data Interchange Format",
noting frequent references to "Unicode characters", when in fact the RFC
formally specifies the use of Unicode Code Points.</t> code points.</t>
<t>Thanks also to Asmus Freytag <contact fullname="Asmus Freytag"/> for careful review and
many constructive suggestions aimed at making the language more consistent
with the structure of the Unicode Standard.</t>
<t>Thanks also to James Manger <contact fullname="James Manger"/> for the correctness of
the ABNF and JSON samples.</t>
<t>Thanks also to Addison Phillips <contact fullname="Addison Phillips"/> and the W3C
Internationalization Working Group for helpful suggestions on language and
references.</t>
<t>Thoughtful comments during the many iterations draft versions of this draft, document, which helped
tighten up wording and make difficult points clearer, were contributed by Harald Alvestrand, Martin J Dürst, Donald
<contact fullname="Harald Alvestrand"/>, <contact fullname="Martin J. Dürst"/>,
<contact fullname="Donald E. Eastlake, John Klensin, Barry Leiba, Glyn Normington, Peter Saint-Andre, and Rob Sayre.</t> Eastlake"/>, <contact fullname="John Klensin"/>,
<contact fullname="Barry Leiba"/>, <contact fullname="Glyn Normington"/>,
<contact fullname="Peter Saint-Andre"/>, and <contact fullname="Rob
Sayre"/>.</t>
</section>

</back>

<!-- [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
 -->

<!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->

<!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

 Concise Binary Object Representation (CBOR)
 Internet JSON (I-JSON)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>