rfc8941xml2.original.v2v3.xml   rfc8941-linewraptest.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocindent="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<?rfc sortrefs="yes"?> docName="draft-ietf-httpbis-header-structure-19" number="8941"
<?rfc symrefs="yes"?> consensus="true" category="std" obsoletes="" updates="" submissionType="IET
<?rfc strict="yes"?> F" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" tocDepth="3" v
<?rfc compact="yes"?> ersion="3">
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc tocdepth="3"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-httpbis-header-structure-19" category="std" obsoletes="" updates="" submis
sionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" t
ocDepth="3" version="3">
<!-- xml2rfc v2v3 conversion 3.2.1 --> <!-- xml2rfc v2v3 conversion 3.2.1 -->
<front> <front>
<title>Structured Field Values for HTTP</title> <title>Structured Field Values for HTTP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-header-structure -19"/> <seriesInfo name="RFC" value="8941"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"> <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<email>mnot@mnot.net</email> <email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri> <uri>https://www.mnot.net/</uri>
</address> </address>
</author> </author>
<author initials="P-H." surname="Kamp" fullname="Poul-Henning Kamp"> <author initials="P-H." surname="Kamp" fullname="Poul-Henning Kamp">
<organization>The Varnish Cache Project</organization> <organization>The Varnish Cache Project</organization>
<address> <address>
<email>phk@varnish-cache.org</email> <email>phk@varnish-cache.org</email>
</address> </address>
</author> </author>
<date/> <date month="November" year="2020"/>
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup> <workgroup>HTTP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document describes a set of data types and associated algorithms t hat are intended to make it easier and safer to define and handle HTTP header an d trailer fields, known as "Structured Fields", "Structured Headers", or "Struct ured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP fiel d values.</t> <t>This document describes a set of data types and associated algorithms t hat are intended to make it easier and safer to define and handle HTTP header an d trailer fields, known as "Structured Fields", "Structured Headers", or "Struct ured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP fiel d values.</t>
</abstract> </abstract>
<note> <note>
<name>Note to Readers</name> <name>Note to Readers</name>
<t><em>RFC EDITOR: please remove this section before publication</em></t> <t><em>RFC EDITOR: please remove this section before publication</em></t>
<t>Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at <eref target="https://lists.w3. org/Archives/Public/ietf-http-wg/">https://lists.w3.org/Archives/Public/ietf-htt p-wg/</eref>.</t> <t>Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at <eref target="https://lists.w3. org/Archives/Public/ietf-http-wg/">https://lists.w3.org/Archives/Public/ietf-htt p-wg/</eref>.</t>
<t>Working Group information can be found at <eref target="https://httpwg. github.io/">https://httpwg.github.io/</eref>; source code and issues list for th is draft can be found at <eref target="https://github.com/httpwg/http-extensions /labels/header-structure">https://github.com/httpwg/http-extensions/labels/heade r-structure</eref>.</t> <t>Working Group information can be found at <eref target="https://httpwg. github.io/">https://httpwg.github.io/</eref>; source code and issues list for th is draft can be found at <eref target="https://github.com/httpwg/http-extensions /labels/header-structure">https://github.com/httpwg/http-extensions/labels/heade r-structure</eref>.</t>
<t>Tests for implementations are collected at <eref target="https://github .com/httpwg/structured-field-tests">https://github.com/httpwg/structured-field-t ests</eref>.</t> <t>Tests for implementations are collected at <eref target="https://github .com/httpwg/structured-field-tests">https://github.com/httpwg/structured-field-t ests</eref>.</t>
<t>Implementations are tracked at <eref target="https://github.com/httpwg/ wiki/wiki/Structured-Headers">https://github.com/httpwg/wiki/wiki/Structured-Hea ders</eref>.</t> <t>Implementations are tracked at <eref target="https://github.com/httpwg/ wiki/wiki/Structured-Headers">https://github.com/httpwg/wiki/wiki/Structured-Hea ders</eref>.</t>
</note> </note>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>Specifying the syntax of new HTTP header (and trailer) fields is an one <t>Specifying the syntax of new HTTP header (and trailer) fields is an one
rous task; even with the guidance in Section 8.3.1 of <xref target="RFC7231" for rous task; even with the guidance in Section 8.3.1 of <xref target="RFC7231" for
mat="default"/>, there are many decisions - and pitfalls - for a prospective HTT mat="default"/>, there are many decisions -- and pitfalls -- for a prospective H
P field author.</t> TTP field author.</t>
<t>Once a field is defined, bespoke parsers and serializers often need to <t>Once a field is defined, bespoke parsers and serializers often need
be written, because each field value has slightly different handling of what loo to be written, because each field value has a slightly different handling
ks like common syntax.</t> of what looks like common syntax.</t>
<t>This document introduces a set of common data structures for use in def initions of new HTTP field values to address these problems. In particular, it d efines a generic, abstract model for them, along with a concrete serialization f or expressing that model in HTTP <xref target="RFC7230" format="default"/> heade r and trailer fields.</t> <t>This document introduces a set of common data structures for use in def initions of new HTTP field values to address these problems. In particular, it d efines a generic, abstract model for them, along with a concrete serialization f or expressing that model in HTTP <xref target="RFC7230" format="default"/> heade r and trailer fields.</t>
<t>A HTTP field that is defined as a "Structured Header" or "Structured Tr ailer" (if the field can be either, it is a "Structured Field") uses the types d efined in this specification to define its syntax and basic handling rules, ther eby simplifying both its definition by specification writers and handling by imp lementations.</t> <t>An HTTP field that is defined as a "Structured Header" or "Structured T railer" (if the field can be either, it is a "Structured Field") uses the types defined in this specification to define its syntax and basic handling rules, the reby simplifying both its definition by specification writers and handling by im plementations.</t>
<t>Additionally, future versions of HTTP can define alternative serializat ions of the abstract model of these structures, allowing fields that use that mo del to be transmitted more efficiently without being redefined.</t> <t>Additionally, future versions of HTTP can define alternative serializat ions of the abstract model of these structures, allowing fields that use that mo del to be transmitted more efficiently without being redefined.</t>
<t>Note that it is not a goal of this document to redefine the syntax of e xisting HTTP fields; the mechanisms described herein are only intended to be use d with fields that explicitly opt into them.</t> <t>Note that it is not a goal of this document to redefine the syntax of e xisting HTTP fields; the mechanisms described herein are only intended to be use d with fields that explicitly opt into them.</t>
<t><xref target="specify" format="default"/> describes how to specify a St ructured Field.</t> <t><xref target="specify" format="default"/> describes how to specify a St ructured Field.</t>
<t><xref target="types" format="default"/> defines a number of abstract da ta types that can be used in Structured Fields.</t> <t><xref target="types" format="default"/> defines a number of abstract da ta types that can be used in Structured Fields.</t>
<t>Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in <xref target="text" format="default"/>. </t> <t>Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in <xref target="text" format="default"/>. </t>
<section anchor="strict" numbered="true" toc="default"> <section anchor="strict" numbered="true" toc="default">
<name>Intentionally Strict Processing</name> <name>Intentionally Strict Processing</name>
<t>This specification intentionally defines strict parsing and serializa tion behaviors using step-by-step algorithms; the only error handling defined is to fail the operation altogether.</t> <t>This specification intentionally defines strict parsing and serializa tion behaviors using step-by-step algorithms; the only error handling defined is to fail the operation altogether.</t>
<t>It is designed to encourage faithful implementation and therefore goo d interoperability. Therefore, an implementation that tried to be helpful by bei ng more tolerant of input would make interoperability worse, since that would cr eate pressure on other implementations to implement similar (but likely subtly d ifferent) workarounds.</t> <t>It is designed to encourage faithful implementation and therefore goo d interoperability. Therefore, an implementation that tried to be helpful by bei ng more tolerant of input would make interoperability worse, since that would cr eate pressure on other implementations to implement similar (but likely subtly d ifferent) workarounds.</t>
<t>In other words, strict processing is an intentional feature of this s <t>In other words, strict processing is an intentional feature of this s
pecification; it allows non-conformant input to be discovered and corrected by t pecification; it allows non-conformant input to be discovered and corrected by t
he producer early, and avoids both interoperability and security issues that mig he producer early and avoids both interoperability and security issues that migh
ht otherwise result.</t> t otherwise result.</t>
<t>Note that as a result of this strictness, if a field is appended to b <t>Note that as a result of this strictness, if a field is appended to b
y multiple parties (e.g., intermediaries, or different components in the sender) y multiple parties (e.g., intermediaries or different components in the sender),
, an error in one party's value is likely to cause the entire field value to fai an error in one party's value is likely to cause the entire field value to fail
l parsing.</t> parsing.</t>
</section> </section>
<section anchor="notational-conventions" numbered="true" toc="default"> <section anchor="notational-conventions" numbered="true" toc="default">
<name>Notational Conventions</name> <name>Notational Conventions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i n this document are to be interpreted as described in BCP 14 <xref target="RFC21 19" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t> <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i n this document are to be interpreted as described in BCP 14 <xref target="RFC21 19" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t>
<t>This document uses algorithms to specify parsing and serialization be haviors, and the Augmented Backus-Naur Form (ABNF) notation of <xref target="RFC 5234" format="default"/> to illustrate expected syntax in HTTP header fields. In doing so, it uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from <xref targe t="RFC5234" format="default"/>. It also includes the tchar and OWS rules from <x ref target="RFC7230" format="default"/>.</t> <t>This document uses algorithms to specify parsing and serialization be haviors, and the Augmented Backus-Naur Form (ABNF) notation of <xref target="RFC 5234" format="default"/> to illustrate expected syntax in HTTP header fields. In doing so, it uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from <xref targ et="RFC5234" format="default"/>. It also includes the tchar and OWS rules from < xref target="RFC7230" format="default"/>.</t>
<t>When parsing from HTTP fields, implementations MUST have behavior tha t is indistinguishable from following the algorithms. If there is disagreement b etween the parsing algorithms and ABNF, the specified algorithms take precedence .</t> <t>When parsing from HTTP fields, implementations MUST have behavior tha t is indistinguishable from following the algorithms. If there is disagreement b etween the parsing algorithms and ABNF, the specified algorithms take precedence .</t>
<t>For serialization to HTTP fields, the ABNF illustrates their expected wire representations, and the algorithms define the recommended way to produce them. Implementations MAY vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm.</t> <t>For serialization to HTTP fields, the ABNF illustrates their expected wire representations, and the algorithms define the recommended way to produce them. Implementations MAY vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm.</t>
</section> </section>
</section> </section>
<section anchor="specify" numbered="true" toc="default"> <section anchor="specify" numbered="true" toc="default">
<name>Defining New Structured Fields</name> <name>Defining New Structured Fields</name>
<t>To specify a HTTP field as a Structured Field, its authors needs to:</t > <t>To specify an HTTP field as a Structured Field, its authors need to:</t >
<ul spacing="normal"> <ul spacing="normal">
<li>Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect.< /li> <li>Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect.< /li>
<li>Identify whether the field is a Structured Header (i.e., it can only be used in the header section - the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both).</li> <li>Identify whether the field is a Structured Header (i.e., it can only be used in the header section - the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both).</li>
<li>Specify the type of the field value; either List (<xref target="list " format="default"/>), Dictionary (<xref target="dictionary" format="default"/>) , or Item (<xref target="item" format="default"/>).</li> <li>Specify the type of the field value; either List (<xref target="list " format="default"/>), Dictionary (<xref target="dictionary" format="default"/>) , or Item (<xref target="item" format="default"/>).</li>
<li>Define the semantics of the field value.</li> <li>Define the semantics of the field value.</li>
<li>Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.</li> <li>Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.</li>
</ul> </ul>
<t>Typically, this means that a field definition will specify the top-leve l type - List, Dictionary or Item - and then define its allowable types, and con straints upon them. For example, a header defined as a List might have all Integ er members, or a mix of types; a header defined as an Item might allow only Stri ngs, and additionally only strings beginning with the letter "Q", or strings in lowercase. Likewise, Inner Lists (<xref target="inner-list" format="default"/>) are only valid when a field definition explicitly allows them.</t> <t>Typically, this means that a field definition will specify the top-leve l type -- List, Dictionary or Item -- and then define its allowable types, and c onstraints upon them. For example, a header defined as a List might have all Int eger members, or a mix of types; a header defined as an Item might allow only St rings, and additionally only strings beginning with the letter "Q", or strings i n lowercase. Likewise, Inner Lists (<xref target="inner-list" format="default"/> ) are only valid when a field definition explicitly allows them.</t>
<t>When parsing fails, the entire field is ignored (see <xref target="text -parse" format="default"/>); in most situations, violating field-specific constr aints should have the same effect. Thus, if a header is defined as an Item and r equired to be an Integer, but a String is received, the field will by default be ignored. If the field requires different error handling, this should be explici tly specified.</t> <t>When parsing fails, the entire field is ignored (see <xref target="text -parse" format="default"/>); in most situations, violating field-specific constr aints should have the same effect. Thus, if a header is defined as an Item and r equired to be an Integer, but a String is received, the field will by default be ignored. If the field requires different error handling, this should be explici tly specified.</t>
<t>Both Items and Inner Lists allow parameters as an extensibility mechani <t>Both Items and Inner Lists allow parameters as an extensibility mechani
sm; this means that values can later be extended to accommodate more information sm; this means that values can later be extended to accommodate more information
, if need be. To preserve forward compatibility, field specifications are discou , if need be. To preserve forward compatibility, field specifications are discou
raged from defining the presence of an unrecognized Parameter as an error condit raged from defining the presence of an unrecognized parameter as an error condit
ion.</t> ion.</t>
<t>To further assure that this extensibility is available in the future, a <t>To further assure that this extensibility is available in the future, a
nd to encourage consumers to use a complete parser implementation, a field defin nd to encourage consumers to use a complete parser implementation, a field defin
ition can specify that "grease" Parameters be added by senders. A specification ition can specify that "grease" parameters be added by senders. A specification
could stipulate that all Parameters that fit a defined pattern are reserved for could stipulate that all parameters that fit a defined pattern are reserved for
this use and then encourage them to be sent on some portion of requests. This he this use and then encourage them to be sent on some portion of requests. This he
lps to discourage recipients from writing a parser that does not account for Par lps to discourage recipients from writing a parser that does not account for Par
ameters.</t> ameters.</t>
<t>Specifications that use Dictionaries can also allow for forward compati <t>Specifications that use Dictionaries can also allow for forward compati
bility by requiring that the presence of - as well as value and type associated bility by requiring that the presence of -- as well as value and type associated
with - unknown members be ignored. Later specifications can then add additional with -- unknown members be ignored. Later specifications can then add additiona
members, specifying constraints on them as appropriate.</t> l members, specifying constraints on them as appropriate.</t>
<t>An extension to a structured field can then require that an entire fiel <t>An extension to a Structured Field can then require that an entire fiel
d value be ignored by a recipient that understands the extension if constraints d value be ignored by a recipient that understands the extension if constraints
on the value it defines are not met.</t> on the value it defines are not met.</t>
<t>A field definition cannot relax the requirements of this specification because doing so would preclude handling by generic software; they can only add additional constraints (for example, on the numeric range of Integers and Decima ls, the format of Strings and Tokens, the types allowed in a Dictionary's values , or the number of Items in a List). Likewise, field definitions can only use th is specification for the entire field value, not a portion thereof.</t> <t>A field definition cannot relax the requirements of this specification because doing so would preclude handling by generic software; they can only add additional constraints (for example, on the numeric range of Integers and Decima ls, the format of Strings and Tokens, the types allowed in a Dictionary's values , or the number of Items in a List). Likewise, field definitions can only use th is specification for the entire field value, not a portion thereof.</t>
<t>This specification defines minimums for the length or number of various structures supported by implementations. It does not specify maximum sizes in m ost cases, but authors should be aware that HTTP implementations do impose vario us limits on the size of individual fields, the total number of fields, and/or t he size of the entire header or trailer section.</t> <t>This specification defines minimums for the length or number of various structures supported by implementations. It does not specify maximum sizes in m ost cases, but authors should be aware that HTTP implementations do impose vario us limits on the size of individual fields, the total number of fields, and/or t he size of the entire header or trailer section.</t>
<t>Specifications can refer to a field name as a "structured header name", <t>Specifications can refer to a field name as a "structured header
"structured trailer name" or "structured field name" as appropriate. Likewise, name", "structured trailer name", or "structured field name" as
they can refer its field value as a "structured header value", "structured trail appropriate. Likewise, they can refer its field value as a "structured
er value" or "structured field value" as necessary. Field definitions are encour header value", "structured trailer value", or "structured field value"
aged to use the ABNF rules beginning with "sf-" defined in this specification; o as necessary. Field definitions are encouraged to use the ABNF rules
ther rules in this specification are not intended for their use.</t> beginning with "sf-" defined in this specification; other rules in this
specification are not to be used in field definitons.</t>
<t>For example, a fictitious Foo-Example header field might be specified a s:</t> <t>For example, a fictitious Foo-Example header field might be specified a s:</t>
<artwork type="example" name="" align="left" alt=""><![CDATA[ <blockquote>
42. Foo-Example Header <t>42. Foo-Example Header</t>
The Foo-Example HTTP header field conveys information about how <t>The Foo-Example HTTP header field conveys information about how
much Foo the message has. much Foo the message has.</t>
Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be <t>Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is: an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:</t>
<artwork>
Foo-Example = sf-integer Foo-Example = sf-integer
</artwork>
Its value indicates the amount of Foo in the message, and MUST <t>Its value indicates the amount of Foo in the message, and MUST
be between 0 and 10, inclusive; other values MUST cause be between 0 and 10, inclusive; other values MUST cause
the entire header field to be ignored. the entire header field to be ignored.</t>
The following parameters are defined: <t>The following parameters are defined:</t>
* A Parameter whose name is "foourl", and whose value is a String <ul>
<li>A Parameter whose name is "foourl", and whose value is a String
(Section Y.Y of [RFCxxxx]), conveying the Foo URL (Section Y.Y of [RFCxxxx]), conveying the Foo URL
for the message. See below for processing requirements. for the message. See below for processing requirements.</li>
</ul>
"foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If <t>"foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
its value is not a valid URI-reference, the entire header field its value is not a valid URI-reference, the entire header field
MUST be ignored. If its value is a relative reference (Section 4.2 MUST be ignored. If its value is a relative reference (Section 4.2
of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before
being used. being used.</t>
For example: <t>For example:</t>
<artwork>
Foo-Example: 2; foourl="https://foo.example.com/" Foo-Example: 2; foourl="https://foo.example.com/"
]]></artwork> </artwork>
</blockquote>
</section> </section>
<section anchor="types" numbered="true" toc="default"> <section anchor="types" numbered="true" toc="default">
<name>Structured Data Types</name> <name>Structured Data Types</name>
<t>This section defines the abstract types for Structured Fields. The ABNF provided represents the on-wire format in HTTP field values.</t> <t>This section defines the abstract types for Structured Fields. The ABNF provided represents the on-wire format in HTTP field values.</t>
<t>In summary:</t> <t>In summary:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>There are three top-level types that a HTTP field can be defined as: Lists, Dictionaries, and Items.</li> <li>There are three top-level types that a HTTP field can be defined as: Lists, Dictionaries, and Items.</li>
<li>Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items).</li> <li>Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items).</li>
<li>Both Items and Inner Lists can be parameterized with key/value pairs .</li> <li>Both Items and Inner Lists can be parameterized with key/value pairs .</li>
</ul> </ul>
skipping to change at line 310 skipping to change at line 316
chr = unescaped / escaped chr = unescaped / escaped
unescaped = %x20-21 / %x23-5B / %x5D-7E unescaped = %x20-21 / %x23-5B / %x5D-7E
escaped = "\" ( DQUOTE / "\" ) escaped = "\" ( DQUOTE / "\" )
]]></artwork> ]]></artwork>
<t>Strings are delimited with double quotes, using a backslash ("\") t o escape double quotes and backslashes. For example:</t> <t>Strings are delimited with double quotes, using a backslash ("\") t o escape double quotes and backslashes. For example:</t>
<artwork type="example" name="" align="left" alt=""><![CDATA[ <artwork type="example" name="" align="left" alt=""><![CDATA[
Example-String: "hello world" Example-String: "hello world"
]]></artwork> ]]></artwork>
<t>Note that Strings only use DQUOTE as a delimiter; single quotes do not delimit Strings. Furthermore, only DQUOTE and "\" can be escaped; other char acters after "\" MUST cause parsing to fail.</t> <t>Note that Strings only use DQUOTE as a delimiter; single quotes do not delimit Strings. Furthermore, only DQUOTE and "\" can be escaped; other char acters after "\" MUST cause parsing to fail.</t>
<t>Unicode is not directly supported in Strings, because it causes a n umber of interoperability issues, and - with few exceptions - field values do no t require it.</t> <t>Unicode is not directly supported in Strings, because it causes a n umber of interoperability issues, and - with few exceptions - field values do no t require it.</t>
<t>When it is necessary for a field value to convey non-ASCII content, a Byte Sequence (<xref target="binary" format="default"/>) can be specified, al ong with a character encoding (preferably <xref target="UTF-8" format="default"/ >).</t> <t>When it is necessary for a field value to convey non-ASCII content, a Byte Sequence (<xref target="binary" format="default"/>) can be specified, al ong with a character encoding (preferably <xref target="STD63" format="default"/ >).</t>
<t>Parsers MUST support Strings (after any decoding) with at least 102 4 characters.</t> <t>Parsers MUST support Strings (after any decoding) with at least 102 4 characters.</t>
</section> </section>
<section anchor="token" numbered="true" toc="default"> <section anchor="token" numbered="true" toc="default">
<name>Tokens</name> <name>Tokens</name>
<t>Tokens are short textual words; their abstract model is identical t o their expression in the HTTP field value serialization.</t> <t>Tokens are short textual words; their abstract model is identical t o their expression in the HTTP field value serialization.</t>
<t>The ABNF for Tokens is:</t> <t>The ABNF for Tokens is:</t>
<artwork type="abnf" name="" align="left" alt=""><![CDATA[ <artwork type="abnf" name="" align="left" alt=""><![CDATA[
sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" ) sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )
]]></artwork> ]]></artwork>
<t>For example:</t> <t>For example:</t>
skipping to change at line 900 skipping to change at line 906
<title>IEEE Standard for Floating-Point Arithmetic</title> <title>IEEE Standard for Floating-Point Arithmetic</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2019" month="July"/> <date year="2019" month="July"/>
</front> </front>
<seriesInfo name="IEEE" value="754-2019"/> <seriesInfo name="IEEE" value="754-2019"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
<seriesInfo name="ISBN" value="978-1-5044-5924-2"/> <seriesInfo name="ISBN" value="978-1-5044-5924-2"/>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3629.xml"/> <reference anchor='STD63' target='https://www.rfc-editor.org/info/std63'>
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'><organization
/></author>
<date year='2003' month='November' />
</front>
<seriesInfo name='STD' value='63'/>
<seriesInfo name='RFC' value='3629'/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7231.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7540.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7540.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7541.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7541.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8259.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7493.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7493.xml"/>
</references> </references>
</references> </references>
<section anchor="faq" numbered="true" toc="default"> <section anchor="faq" numbered="true" toc="default">
<name>Frequently Asked Questions</name> <name>Frequently Asked Questions</name>
<section anchor="why-not-json" numbered="true" toc="default"> <section anchor="why-not-json" numbered="true" toc="default">
 End of changes. 28 change blocks. 
78 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/