rfc9651.original.xml   rfc9651.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-httpbis-sfbis-06" number="9651" submissionType="IETF" category="std" conse
<?rfc tocindent="yes"?> nsus="true" obsoletes="8941" updates="" tocInclude="true" sortRefs="true" symRef
<?rfc strict="yes"?> s="true" version="3" xml:lang="en">
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-httpbis-sfbis-06" category="std" consensus="true" obsoletes="8941" tocIncl
ude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.21.0 -->
<front> <front>
<title>Structured Field Values for HTTP</title> <title>Structured Field Values for HTTP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-sfbis-06"/> <seriesInfo name="RFC" value="9651"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"> <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<postal> <postal>
<city>Prahran</city> <city>Prahran</city>
<region>VIC</region> <region>VIC</region>
<country>Australia</country> <country>Australia</country>
</postal> </postal>
<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>
<!-- [rfced] Poul-Henning, do you prefer "P.-H. Kamp" in the document header, wh ich is how your name appears in this document, or "P-H. Kamp", which is how it a ppears on RFC 8941? -->
<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="August" year="2024"/>
<area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 86?>
<area>WIT</area>
<workgroup>httpbis</workgroup>
<!-- [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 describes a set of data types and associated algorithms that ar e intended to make it easier and safer to define and handle HTTP header and trai ler fields, known as "Structured Fields", "Structured Headers", or "Structured T railers". 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 field valu es.</t> <t>This document describes a set of data types and associated algorithms that ar e intended to make it easier and safer to define and handle HTTP header and trai ler fields, known as "Structured Fields", "Structured Headers", or "Structured T railers". 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 field valu es.</t>
<t>This document obsoletes RFC 8941.</t> <t>This document obsoletes RFC 8941.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-httpbis-sfbis/"/>.
</t>
<t>
Discussion of this document takes place on the
HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.or
g"/>),
which is archived at <eref target="https://lists.w3.org/Archives/Public/
ietf-http-wg/"/>.
Working Group information can be found at <eref target="https://httpwg.o
rg/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http-extensions/labels/header-st
ructure"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 93?> <?line 93?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Specifying the syntax of new HTTP header (and trailer) fields is an one rous task; even with the guidance in <xref section="16.3.2" sectionFormat="of" t arget="HTTP"/>, there are many decisions -- and pitfalls -- for a prospective HT TP field author.</t> <t>Specifying the syntax of new HTTP header (and trailer) fields is an one rous task; even with the guidance in <xref section="16.3.2" sectionFormat="of" t arget="RFC9110"/>, there are many decisions -- and pitfalls -- for a prospective HTTP field author.</t>
<t>Once a field is defined, bespoke parsers and serializers often need to be written, because each field value has a slightly different handling of what l ooks like common syntax.</t> <t>Once a field is defined, bespoke parsers and serializers often need to be written, because each field value has a slightly different handling of what l ooks 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="HTTP"/> header 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="RFC9110"/> header and trailer fie lds.</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>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"/> describes how to specify a Structured Field.</ t> <t><xref target="specify"/> describes how to specify a Structured Field.</ t>
<t><xref target="types"/> defines a number of abstract data types that can be used in Structured Fields.</t> <t><xref target="types"/> defines a number of abstract data 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"/>.</t> <t>Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in <xref target="text"/>.</t>
<section anchor="strict"> <section anchor="strict">
<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 entire 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 entire operation altogether.</t>
<t>It is designed to encourage faithful implementation and good interope rability. Therefore, an implementation that tried to be helpful by being more to lerant of input would make interoperability worse, since that would create press ure on other implementations to implement similar (but likely subtly different) workarounds.</t> <t>It is designed to encourage faithful implementation and good interope rability. Therefore, an implementation that tried to be helpful by being more to lerant of input would make interoperability worse, since that would create press ure on other implementations to implement similar (but likely subtly different) workarounds.</t>
<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 he producer early and avoids both interoperability and security issues that migh t otherwise result.</t> <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 he producer early and avoids both interoperability and security issues that migh t otherwise result.</t>
<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), an error in one party's value is likely to cause the entire field value to fail parsing.</t> <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), an error in one party's value is likely to cause the entire field value to fail parsing.</t>
</section> </section>
<section anchor="notational-conventions"> <section anchor="notational-conventions">
<name>Notational Conventions</name> <name>Notational Conventions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp1
n this document are to be interpreted as described in BCP 14 <xref target="RFC21 4>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<
19"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp1
as shown here.</t> 4>" in this document are to be interpreted as described in BCP&nbsp;14 <xref tar
<t>This document uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from get="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
<xref target="RFC5234"/> to specify characters and/or their corresponding ASCII capitals, as shown here.</t>
bytes, depending on context. It uses the tchar and OWS rules from <xref target= <t>This document uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from
"HTTP"/> for the same purpose.</t> <xref target="RFC5234"/> to specify characters and/or their corresponding ASCII
<t>This document uses algorithms to specify parsing and serialization be bytes, depending on context. It uses the tchar and OWS rules from <xref target=
haviors. When parsing from HTTP fields, implementations MUST have behavior that "RFC9110"/> for the same purpose.</t>
is indistinguishable from following the algorithms.</t> <t>This document uses algorithms to specify parsing and serialization be
<t>For serialization to HTTP fields, the algorithms define the recommend haviors. When parsing from HTTP fields, implementations <bcp14>MUST</bcp14> have
ed way to produce them. Implementations MAY vary from the specified behavior so behavior that is indistinguishable from following the algorithms.</t>
long as the output is still correctly handled by the parsing algorithm described <t>For serialization to HTTP fields, the algorithms define the recommend
in <xref target="text-parse"/>.</t> ed way to produce them. Implementations <bcp14>MAY</bcp14> vary from the specifi
ed behavior so long as the output is still correctly handled by the parsing algo
rithm described in <xref target="text-parse"/>.</t>
</section> </section>
</section> </section>
<section anchor="specify"> <section anchor="specify">
<name>Defining New Structured Fields</name> <name>Defining New Structured Fields</name>
<t>To specify an HTTP field as a Structured Field, its authors need to:</t > <t>To specify an HTTP field as a Structured Field, its authors need to:</t >
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect. </t> <t>Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect. </t>
</li> </li>
<li> <li>
skipping to change at line 113 skipping to change at line 99
<t>Specify the type of the field value; either List (<xref target="lis t"/>), Dictionary (<xref target="dictionary"/>), or Item (<xref target="item"/>) .</t> <t>Specify the type of the field value; either List (<xref target="lis t"/>), Dictionary (<xref target="dictionary"/>), or Item (<xref target="item"/>) .</t>
</li> </li>
<li> <li>
<t>Define the semantics of the field value.</t> <t>Define the semantics of the field value.</t>
</li> </li>
<li> <li>
<t>Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.</t> <t>Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.</t>
</li> </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 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"/>) 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"/>) are only valid when a field definition explicitly allows them.</t>
<t>Fields that use the Display String type are advised to carefully specif y their allowable unicode code points; for example, specifying the use of a prof ile from <xref target="PRECIS"/>.</t> <t>Fields that use the Display String type are advised to carefully specif y their allowable Unicode code points; for example, specifying the use of a prof ile from <xref target="RFC8264"/>.</t>
<t>Field definitions can only use this specification for the entire field value, not a portion thereof.</t> <t>Field definitions can only use this specification for the entire field value, not a portion thereof.</t>
<t>Specifications can refer to a field name as a "structured header name", "structured trailer name", or "structured field name" as appropriate. Likewise, they can refer its field value as a "structured header value", "structured trai ler value", or "structured field value" as necessary.</t> <t>Specifications can refer to a field name as a "Structured Header name", "Structured Trailer name", or "Structured Field name" as appropriate. Likewise, they can refer its field value as a "Structured Header value", "Structured Trai ler value", or "Structured Field value" as necessary.</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>
<section anchor="example"> <section anchor="example">
<name>Example</name> <name>Example</name>
<t>A fictitious Foo-Example header field might be specified as:</t> <t>A fictitious Foo-Example header field might be specified as:</t>
<blockquote> <blockquote>
<t>42. Foo-Example Header Field</t> <t>42. Foo-Example Header Field</t>
<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.</t> much Foo the message has.</t>
<t>Foo-Example is an Item Structured Header Field [RFCnnnn]. Its value <t>Foo-Example is an Item Structured Header Field [RFC9651]. Its value
MUST be an Integer (Section 3.3.1 of [RFCnnnn]).</t> <bcp14>MUST</bcp14> be an Integer (Section 3.3.1 of [RFC9651]).</t>
<t>Its value indicates the amount of Foo in the message, and it MUST <t>Its value indicates the amount of Foo in the message, and it <bcp14
be between 0 and 10, inclusive; other values MUST cause >MUST</bcp14>
be between 0 and 10, inclusive; other values <bcp14>MUST</bcp14> cause
the entire header field to be ignored.</t> the entire header field to be ignored.</t>
<t>The following parameter is defined:</t> <t>The following parameter is defined:</t>
<ul> <ul>
<li>A parameter whose key is "foourl", and whose value is a String <li>A parameter whose key is "foourl", and whose value is a String
(Section 3.3.3 of [RFCnnnn]), conveying the Foo URL (Section 3.3.3 of [RFC9651]), conveying the Foo URL
for the message. See below for processing requirements.</li> for the message. See below for processing requirements.</li>
</ul> </ul>
<t>"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 <bcp14>MUST</bcp14> be ignored. If its value is a relative reference (Section 4.
of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before 2
of [RFC3986]), it <bcp14>MUST</bcp14> be resolved (Section 5 of [RFC3986]) befor
e
being used.</t> being used.</t>
<t>For example:</t> <t>For example:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Foo-Example: 2; foourl="https://foo.example.com/" Foo-Example: 2; foourl="https://foo.example.com/"
]]></artwork> ]]></artwork>
</blockquote> </blockquote>
</section> </section>
<section anchor="error-handling"> <section anchor="error-handling">
<name>Error Handling</name> <name>Error Handling</name>
<t>When parsing fails, the entire field is ignored (see <xref target="te xt-parse"/>). Field definitions cannot override this, because doing so would pre clude handling by generic software; they can only add additional constraints (fo r example, on the numeric range of Integers and Decimals, the format of Strings and Tokens, the types allowed in a Dictionary's values, or the number of Items i n a List).</t> <t>When parsing fails, the entire field is ignored (see <xref target="te xt-parse"/>). Field definitions cannot override this because doing so would prec lude handling by generic software; they can only add additional constraints (for example, on the numeric range of Integers and Decimals, the format of Strings a nd Tokens, the types allowed in a Dictionary's values, or the number of Items in a List).</t>
<t>When field-specific constraints are violated, the entire field is als o ignored, unless the field definition defines other handling requirements. For example, if a header field is defined as an Item and required to be an Integer, but a String is received, it should be ignored unless that field's definition ex plicitly specifies otherwise.</t> <t>When field-specific constraints are violated, the entire field is als o ignored, unless the field definition defines other handling requirements. For example, if a header field is defined as an Item and required to be an Integer, but a String is received, it should be ignored unless that field's definition ex plicitly specifies otherwise.</t>
</section> </section>
<section anchor="preserving-extensibility"> <section anchor="preserving-extensibility">
<name>Preserving Extensibility</name> <name>Preserving Extensibility</name>
<t>Structured Fields are designed to be extensible, because experience h as shown that even when it is not foreseen, it is often necessary to modify and add to the allowable syntax and semantics of a field in a controlled fashion.</t > <t>Structured Fields are designed to be extensible because experience ha s shown that, even when it is not foreseen, it is often necessary to modify and add to the allowable syntax and semantics of a field in a controlled fashion.</t >
<t>Both Items and Inner Lists allow Parameters as an extensibility mecha nism; this means that their values can later be extended to accommodate more inf ormation, if need be. To preserve forward compatibility, field specifications ar e discouraged from defining the presence of an unrecognized parameter as an erro r condition.</t> <t>Both Items and Inner Lists allow Parameters as an extensibility mecha nism; this means that their values can later be extended to accommodate more inf ormation, if need be. To preserve forward compatibility, field specifications ar e discouraged from defining the presence of an unrecognized parameter as an erro r condition.</t>
<t>Field specifications are required to be either an Item, List, or Dict ionary to preserve extensibility. Fields that erroneously defined as another typ e (e.g., Integer) are assumed to be Items (i.e., they allow Parameters).</t> <t>Field specifications are required to be either an Item, List, or Dict ionary to preserve extensibility. Fields that erroneously defined as another typ e (e.g., Integer) are assumed to be Items (i.e., they allow Parameters).</t>
<t>To further assure that this extensibility is available in the future, and to encourage consumers to use a complete parser implementation, a field def inition can specify that "grease" parameters be added by senders. A specificatio n could stipulate that all parameters that fit a defined pattern are reserved fo r this use and then encourage them to be sent on some portion of requests. This helps to discourage recipients from writing a parser that does not account for P arameters.</t> <t>To further assure that this extensibility is available in the future, and to encourage consumers to use a complete parser implementation, a field def inition can specify that "grease" parameters be added by senders. A specificatio n could stipulate that all parameters that fit a defined pattern are reserved fo r this use and then encourage them to be sent on some portion of requests. This helps to discourage recipients from writing a parser that does not account for P arameters.</t>
<t>Specifications that use Dictionaries can also allow for forward compa tibility by requiring that the presence of -- as well as value and type associat ed with -- unknown keys be ignored. Subsequent specifications can then add addit ional keys, specifying constraints on them as appropriate.</t> <t>Specifications that use Dictionaries can also allow for forward compa tibility by requiring that the presence of -- as well as value and type associat ed with -- unknown keys be ignored. Subsequent specifications can then add addit ional keys, specifying constraints on them as appropriate.</t>
<t>An extension to a Structured Field can then require that an entire fi eld value be ignored by a recipient that understands the extension if constraint s on the value it defines are not met.</t> <t>An extension to a Structured Field can then require that an entire fi eld value be ignored by a recipient that understands the extension if constraint s on the value it defines are not met.</t>
</section> </section>
<section anchor="using-new-structured-types-in-extensions"> <section anchor="using-new-structured-types-in-extensions">
<name>Using New Structured Types in Extensions</name> <name>Using New Structured Types in Extensions</name>
<t>Because a field definition needs to reference a specific RFC for Stru <t>Because a field definition needs to reference a specific RFC for Stru
ctured Fields, the types available for use in its value are limited to those def ctured Fields, the types available for use in its value are limited to those def
ined in that RFC. For example, a field whose definition references this document ined in that RFC. For example, a field whose definition references this document
can have a value that uses the Date type (<xref target="date"/>), whereas a fie can have a value that uses the Date type (<xref target="date"/>), whereas a fie
ld whose definition references RFC 8941 cannot, because it will be treated as in ld whose definition references RFC 8941 cannot because it will be treated as inv
valid (and therefore discarded) by implementations of that specification.</t> alid (and therefore discarded) by implementations of that specification.</t>
<t>This limitation also applies to future extensions to a field; for exa <t>This limitation also applies to future extensions to a field; for exa
mple, a field that is defined with reference to RFC 8941 cannot use the Date typ mple, a field that is defined with a reference to RFC 8941 cannot use the Date t
e, because some recipients might still be using an RFC 8941 parser to process it ype because some recipients might still be using a parser based on RFC 8941 to p
.</t> rocess it.</t>
<t>However, this document is designed to be backwards-compatible with RF <t>However, this document is designed to be backward compatible with RFC
C 8941; a parser that implements the requirements here can also parse valid Stru 8941; a parser that implements the requirements here can also parse valid Struc
ctured Fields whose definitions reference RFC 8941.</t> tured Fields whose definitions reference RFC 8941.</t>
<t>Upgrading a Structured Fields implementation to support a newer revis ion of the specification (such as this document) brings the possibility that som e field values that were invalid according to the earlier RFC might become valid when processed.</t> <t>Upgrading a Structured Fields implementation to support a newer revis ion of the specification (such as this document) brings the possibility that som e field values that were invalid according to the earlier RFC might become valid when processed.</t>
<t>For example, field instance might contain a syntactically valid Date (<xref target="date"/>), even though that field's definition does not accommodat e Dates. An RFC8941 implementation would fail parsing such a field instance, bec ause they are not defined in that specification. If that implementation were upg raded to this specification, parsing would now succeed. In some cases, the resul ting Date value will be rejected by field-specific logic, but values in fields t hat are otherwise ignored (such as extension parameters) might not be detected a nd the field might subsequently be accepted and processed.</t> <t>For example, a field instance might contain a syntactically valid Dat e (<xref target="date"/>), even though that field's definition does not accommod ate Dates. An implementation based on RFC 8941 would fail parsing such a field i nstance because it is not defined in that specification. If that implementation were upgraded to this specification, parsing would now succeed. In some cases, t he resulting Date value will be rejected by field-specific logic, but values in fields that are otherwise ignored (such as extension parameters) might not be de tected, and the field might subsequently be accepted and processed.</t>
</section> </section>
</section> </section>
<section anchor="types"> <section anchor="types">
<name>Structured Data Types</name> <name>Structured Data Types</name>
<t>This section provides an overview of the abstract types that Structured Fields use, and gives a brief description and examples of how each of those typ es are serialized into textual HTTP fields. <xref target="text"/> specifies the details of how they are parsed from and serialized into textual HTTP fields.</t> <t>This section provides an overview of the abstract types that Structured Fields use and gives a brief description and examples of how each of those type s are serialized into textual HTTP fields. <xref target="text"/> specifies the d etails of how they are parsed from and serialized into textual HTTP fields.</t>
<t>In summary:</t> <t>In summary:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>There are three top-level types that an HTTP field can be defined a s: Lists, Dictionaries, and Items.</t> <t>There are three top-level types that an HTTP field can be defined a s: Lists, Dictionaries, and Items.</t>
</li> </li>
<li> <li>
<t>Lists and Dictionaries are containers; their members can be Items o r Inner Lists (which are themselves arrays of Items).</t> <t>Lists and Dictionaries are containers; their members can be Items o r Inner Lists (which are themselves arrays of Items).</t>
</li> </li>
<li> <li>
<t>Both Items and Inner Lists can be Parameterized with key/value pair s.</t> <t>Both Items and Inner Lists can be Parameterized with key/value pair s.</t>
</li> </li>
</ul> </ul>
<section anchor="list"> <section anchor="list">
<name>Lists</name> <name>Lists</name>
<t>Lists are arrays of zero or more members, each of which can be an Ite m (<xref target="item"/>) or an Inner List (<xref target="inner-list"/>), both o f which can be Parameterized (<xref target="param"/>).</t> <t>Lists are arrays of zero or more members, each of which can be an Ite m (<xref target="item"/>) or an Inner List (<xref target="inner-list"/>), both o f which can be Parameterized (<xref target="param"/>).</t>
<t>An empty List is denoted by not serializing the field at all. This im plies that fields defined as Lists have a default empty value.</t> <t>An empty List is denoted by not serializing the field at all. This im plies that fields defined as Lists have a default empty value.</t>
<t>When serialized as a textual HTTP field, each member is separated by a comma and optional whitespace. For example, a field whose value is defined as a List of Tokens could look like:</t> <t>When serialized as a textual HTTP field, each member is separated by a comma and optional whitespace. For example, a field whose value is defined as a List of Tokens could look like:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-List: sugar, tea, rum Example-List: sugar, tea, rum
]]></sourcecode> ]]></sourcecode>
<t>Note that Lists can have their members split across multiple lines of the same header or trailer section, as per <xref section="5.3" sectionFormat="o f" target="HTTP"/>; for example, the following are equivalent:</t> <t>Note that Lists can have their members split across multiple lines of the same header or trailer section, as per <xref section="5.3" sectionFormat="o f" target="RFC9110"/>; for example, the following are equivalent:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-List: sugar, tea, rum Example-List: sugar, tea, rum
]]></sourcecode> ]]></sourcecode>
<t>and</t> <t>and</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-List: sugar, tea Example-List: sugar, tea
Example-List: rum Example-List: rum
]]></sourcecode> ]]></sourcecode>
<t>However, individual members of a List cannot be safely split between lines; see <xref target="text-parse"/> for details.</t> <t>However, individual members of a List cannot be safely split between lines; see <xref target="text-parse"/> for details.</t>
<t>Parsers MUST support Lists containing at least 1024 members. Field sp ecifications can constrain the types and cardinality of individual List values a s they require.</t> <t>Parsers <bcp14>MUST</bcp14> support Lists containing at least 1024 me mbers. Field specifications can constrain the types and cardinality of individua l List values as they require.</t>
<section anchor="inner-list"> <section anchor="inner-list">
<name>Inner Lists</name> <name>Inner Lists</name>
<t>An Inner List is an array of zero or more Items (<xref target="item "/>). Both the individual Items and the Inner List itself can be Parameterized ( <xref target="param"/>).</t> <t>An Inner List is an array of zero or more Items (<xref target="item "/>). Both the individual Items and the Inner List itself can be Parameterized ( <xref target="param"/>).</t>
<t>When serialized in a textual HTTP field, Inner Lists are denoted by surrounding parenthesis, and their values are delimited by one or more spaces. A field whose value is defined as a List of Inner Lists of Strings could look li ke:</t> <t>When serialized in a textual HTTP field, Inner Lists are denoted by surrounding parenthesis, and their values are delimited by one or more spaces. A field whose value is defined as a List of Inner Lists of Strings could look li ke:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-List: ("foo" "bar"), ("baz"), ("bat" "one"), () Example-List: ("foo" "bar"), ("baz"), ("bat" "one"), ()
]]></sourcecode> ]]></sourcecode>
<t>Note that the last member in this example is an empty Inner List.</ t> <t>Note that the last member in this example is an empty Inner List.</ t>
<t>A header field whose value is defined as a List of Inner Lists with Parameters at both levels could look like:</t> <t>A header field whose value is defined as a List of Inner Lists with Parameters at both levels could look like:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-List: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1 Example-List: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1
]]></sourcecode> ]]></sourcecode>
<t>Parsers MUST support Inner Lists containing at least 256 members. F ield specifications can constrain the types and cardinality of individual Inner List members as they require.</t> <t>Parsers <bcp14>MUST</bcp14> support Inner Lists containing at least 256 members. Field specifications can constrain the types and cardinality of in dividual Inner List members as they require.</t>
</section> </section>
<section anchor="param"> <section anchor="param">
<name>Parameters</name> <name>Parameters</name>
<t>Parameters are an ordered map of key-value pairs that are associate d with an Item (<xref target="item"/>) or Inner List (<xref target="inner-list"/ >). The keys are unique within the scope of the Parameters they occur within, an d the values are bare items (i.e., they themselves cannot be parameterized; see <xref target="item"/>).</t> <t>Parameters are an ordered map of key-value pairs that are associate d with an Item (<xref target="item"/>) or Inner List (<xref target="inner-list"/ >). The keys are unique within the scope of the Parameters they occur within, an d the values are bare items (i.e., they themselves cannot be parameterized; see <xref target="item"/>).</t>
<t>Implementations MUST provide access to Parameters both by index and by key. Specifications MAY use either means of accessing them.</t> <t>Implementations <bcp14>MUST</bcp14> provide access to Parameters bo th by index and by key. Specifications <bcp14>MAY</bcp14> use either means of ac cessing them.</t>
<t>Note that parameters are ordered, and parameter keys cannot contain uppercase letters.</t> <t>Note that parameters are ordered, and parameter keys cannot contain uppercase letters.</t>
<t>When serialized in a textual HTTP field, a Parameter is separated f rom its Item or Inner List and other Parameters by a semicolon. For example:</t> <t>When serialized in a textual HTTP field, a Parameter is separated f rom its Item or Inner List and other Parameters by a semicolon. For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-List: abc;a=1;b=2; cde_456, (ghi;jk=4 l);q="9";r=w Example-List: abc;a=1;b=2; cde_456, (ghi;jk=4 l);q="9";r=w
]]></sourcecode> ]]></sourcecode>
<t>Parameters whose value is Boolean (see <xref target="boolean"/>) tr ue MUST omit that value when serialized. For example, the "a" parameter here is true, while the "b" parameter is false:</t> <t>Parameters whose value is Boolean (see <xref target="boolean"/>) tr ue <bcp14>MUST</bcp14> omit that value when serialized. For example, the "a" par ameter here is true, while the "b" parameter is false:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Integer: 1; a; b=?0 Example-Integer: 1; a; b=?0
]]></sourcecode> ]]></sourcecode>
<t>Note that this requirement is only on serialization; parsers are st ill required to correctly handle the true value when it appears in a parameter.< /t> <t>Note that this requirement is only on serialization; parsers are st ill required to correctly handle the true value when it appears in a parameter.< /t>
<t>Parsers MUST support at least 256 parameters on an Item or Inner Li st, and support parameter keys with at least 64 characters. Field specifications can constrain the order of individual parameters, as well as their values' type s as required.</t> <t>Parsers <bcp14>MUST</bcp14> support at least 256 parameters on an I tem or Inner List, and support parameter keys with at least 64 characters. Field specifications can constrain the order of individual parameters, as well as the ir values' types as required.</t>
</section> </section>
</section> </section>
<section anchor="dictionary"> <section anchor="dictionary">
<name>Dictionaries</name> <name>Dictionaries</name>
<t>Dictionaries are ordered maps of key-value pairs, where the keys are short textual strings and the values are Items (<xref target="item"/>) or arrays of Items, both of which can be Parameterized (<xref target="param"/>). There ca n be zero or more members, and their keys are unique in the scope of the Diction ary they occur within.</t> <t>Dictionaries are ordered maps of key-value pairs, where the keys are short textual strings and the values are Items (<xref target="item"/>) or arrays of Items, both of which can be Parameterized (<xref target="param"/>). There ca n be zero or more members, and their keys are unique in the scope of the Diction ary they occur within.</t>
<t>Implementations MUST provide access to Dictionaries both by index and by key. Specifications MAY use either means of accessing the members.</t> <t>Implementations <bcp14>MUST</bcp14> provide access to Dictionaries bo th by index and by key. Specifications <bcp14>MAY</bcp14> use either means of ac cessing the members.</t>
<t>As with Lists, an empty Dictionary is represented by omitting the ent ire field. This implies that fields defined as Dictionaries have a default empty value.</t> <t>As with Lists, an empty Dictionary is represented by omitting the ent ire field. This implies that fields defined as Dictionaries have a default empty value.</t>
<t>Typically, a field specification will define the semantics of Diction <t>Typically, a field specification will define the semantics of Diction
aries by specifying the allowed type(s) for individual members by their keys, as aries by specifying the allowed type(s) for individual members by their keys, as
well as whether their presence is required or optional. Recipients MUST ignore well as whether their presence is required or optional. Recipients <bcp14>MUST<
members whose keys are undefined or unknown, unless the field's specification sp /bcp14> ignore members whose keys are undefined or unknown, unless the field's s
ecifically disallows them.</t> pecification specifically disallows them.</t>
<t>When serialized as a textual HTTP field, Members are ordered as seria <t>When serialized as a textual HTTP field, members are ordered as seria
lized and separated by a comma with optional whitespace. Member keys cannot cont lized and separated by a comma with optional whitespace. Member keys cannot cont
ain uppercase characters. Keys and values are separated by "=" (without whitespa ain uppercase characters. Keys and values are separated by "=" (without whitespa
ce). For example:</t> ce). For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=: Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=:
]]></sourcecode> ]]></sourcecode>
<t>Note that in this example, the final "=" is due to the inclusion of a Byte Sequence; see <xref target="binary"/>.</t> <t>Note that in this example, the final "=" is due to the inclusion of a Byte Sequence; see <xref target="binary"/>.</t>
<t>Members whose value is Boolean (see <xref target="boolean"/>) true MU ST omit that value when serialized. For example, here both "b" and "c" are true: </t> <t>Members whose value is Boolean (see <xref target="boolean"/>) true <b cp14>MUST</bcp14> omit that value when serialized. For example, here both "b" an d "c" are true:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Dict: a=?0, b, c; foo=bar Example-Dict: a=?0, b, c; foo=bar
]]></sourcecode> ]]></sourcecode>
<t>Note that this requirement is only on serialization; parsers are stil l required to correctly handle the true Boolean value when it appears in Diction ary values.</t> <t>Note that this requirement is only on serialization; parsers are stil l required to correctly handle the true Boolean value when it appears in Diction ary values.</t>
<t>A Dictionary with a member whose value is an Inner List of Tokens:</t > <t>A Dictionary with a member whose value is an Inner List of Tokens:</t >
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Dict: rating=1.5, feelings=(joy sadness) Example-Dict: rating=1.5, feelings=(joy sadness)
]]></sourcecode> ]]></sourcecode>
<t>A Dictionary with a mix of Items and Inner Lists, some with parameter s:</t> <t>A Dictionary with a mix of Items and Inner Lists, some with parameter s:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
skipping to change at line 268 skipping to change at line 254
<t>Note that Dictionaries can have their members split across multiple l ines of the same header or trailer section; for example, the following are equiv alent:</t> <t>Note that Dictionaries can have their members split across multiple l ines of the same header or trailer section; for example, the following are equiv alent:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Dict: foo=1, bar=2 Example-Dict: foo=1, bar=2
]]></sourcecode> ]]></sourcecode>
<t>and</t> <t>and</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Dict: foo=1 Example-Dict: foo=1
Example-Dict: bar=2 Example-Dict: bar=2
]]></sourcecode> ]]></sourcecode>
<t>However, individual members of a Dictionary cannot be safely split be tween lines; see <xref target="text-parse"/> for details.</t> <t>However, individual members of a Dictionary cannot be safely split be tween lines; see <xref target="text-parse"/> for details.</t>
<t>Parsers MUST support Dictionaries containing at least 1024 key/value pairs and keys with at least 64 characters. Field specifications can constrain t he order of individual Dictionary members, as well as their values' types as req uired.</t> <t>Parsers <bcp14>MUST</bcp14> support Dictionaries containing at least 1024 key/value pairs and keys with at least 64 characters. Field specifications can constrain the order of individual Dictionary members, as well as their value s' types as required.</t>
</section> </section>
<section anchor="item"> <section anchor="item">
<name>Items</name> <name>Items</name>
<t>An Item can be an Integer (<xref target="integer"/>), a Decimal (<xre f target="decimal"/>), a String (<xref target="string"/>), a Token (<xref target ="token"/>), a Byte Sequence (<xref target="binary"/>), a Boolean (<xref target= "boolean"/>), or a Date (<xref target="date"/>). It can have associated paramete rs (<xref target="param"/>).</t> <t>An Item can be an Integer (<xref target="integer"/>), a Decimal (<xre f target="decimal"/>), a String (<xref target="string"/>), a Token (<xref target ="token"/>), a Byte Sequence (<xref target="binary"/>), a Boolean (<xref target= "boolean"/>), or a Date (<xref target="date"/>). It can have associated paramete rs (<xref target="param"/>).</t>
<t>For example, a header field that is defined to be an Item that is an Integer might look like:</t> <t>For example, a header field that is defined to be an Item that is an Integer might look like:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Integer: 5 Example-Integer: 5
]]></sourcecode> ]]></sourcecode>
<t>or with parameters:</t> <t>or with parameters:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
skipping to change at line 305 skipping to change at line 291
<t>For example, a header whose value is defined as a Decimal could loo k like:</t> <t>For example, a header whose value is defined as a Decimal could loo k like:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Decimal: 4.5 Example-Decimal: 4.5
]]></sourcecode> ]]></sourcecode>
<t>While it is possible to serialize Decimals with leading zeros (e.g. , "0002.5", "-01.334"), trailing zeros (e.g., "5.230", "-0.40"), and signed zero (e.g., "-0.0"), these distinctions may not be preserved by implementations.</t> <t>While it is possible to serialize Decimals with leading zeros (e.g. , "0002.5", "-01.334"), trailing zeros (e.g., "5.230", "-0.40"), and signed zero (e.g., "-0.0"), these distinctions may not be preserved by implementations.</t>
<t>Note that the serialization algorithm (<xref target="ser-decimal"/> ) rounds input with more than three digits of precision in the fractional compon ent. If an alternative rounding strategy is desired, this should be specified by the field definition to occur before serialization.</t> <t>Note that the serialization algorithm (<xref target="ser-decimal"/> ) rounds input with more than three digits of precision in the fractional compon ent. If an alternative rounding strategy is desired, this should be specified by the field definition to occur before serialization.</t>
</section> </section>
<section anchor="string"> <section anchor="string">
<name>Strings</name> <name>Strings</name>
<t>Strings are zero or more printable ASCII <xref target="RFC0020"/> c haracters (i.e., the range %x20 to %x7E). Note that this excludes tabs, newlines , carriage returns, etc.</t> <t>Strings are zero or more printable ASCII <xref target="RFC0020"/> c haracters (i.e., the range %x20 to %x7E). Note that this excludes tabs, newlines , carriage returns, etc.</t>
<t>Non-ASCII characters are not directly supported in Strings, because they cause a number of interoperability issues, and -- with few exceptions -- f ield values do not require them.</t> <t>Non-ASCII characters are not directly supported in Strings because they cause a number of interoperability issues, and -- with few exceptions -- fi eld values do not require them.</t>
<t>When it is necessary for a field value to convey non-ASCII content, a Display String (<xref target="displaystring"/>) can be specified.</t> <t>When it is necessary for a field value to convey non-ASCII content, a Display String (<xref target="displaystring"/>) can be specified.</t>
<t>When serialized in a textual HTTP field, Strings are delimited with double quotes, using a backslash ("\") to escape double quotes and backslashes. For example:</t> <t>When serialized in a textual HTTP field, Strings are delimited with double quotes, using a backslash ("\") to escape double quotes and backslashes. For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-String: "hello world" Example-String: "hello world"
]]></sourcecode> ]]></sourcecode>
<t>Note that Strings only use DQUOTE as a delimiter; single quotes do <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 not delimit Strings. Furthermore, only DQUOTE and "\" can be escaped; other char
acters after "\" MUST cause parsing to fail.</t> acters after "\" <bcp14>MUST</bcp14> cause parsing to fail.</t>
<t>Parsers MUST support Strings (after any decoding) with at least 102 <t>Parsers <bcp14>MUST</bcp14> support Strings (after any decoding) wi
4 characters.</t> th at least 1024 characters.</t>
</section> </section>
<section anchor="token"> <section anchor="token">
<name>Tokens</name> <name>Tokens</name>
<t>Tokens are short textual words that begin with an alphabetic charac ter or "*", followed by zero to many token characters, which are the same as tho se allowed by the "token" ABNF rule defined in <xref target="HTTP"/>, plus the " :" and "/" characters.</t> <t>Tokens are short textual words that begin with an alphabetic charac ter or "*", followed by zero to many token characters, which are the same as tho se allowed by the "token" ABNF rule defined in <xref target="RFC9110"/> plus the ":" and "/" characters.</t>
<t>For example:</t> <t>For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Token: foo123/456 Example-Token: foo123/456
]]></sourcecode> ]]></sourcecode>
<t>Parsers MUST support Tokens with at least 512 characters.</t> <t>Parsers <bcp14>MUST</bcp14> support Tokens with at least 512 charac
<t>Note that Tokens are defined largely for compatibility with the dat ters.</t>
a model of existing HTTP fields, and may require additional steps to use in some <t>Note that Tokens are defined largely for compatibility with the dat
implementations. As a result, new fields are encouraged to use Strings.</t> a model of existing HTTP fields and may require additional steps to use in some
implementations. As a result, new fields are encouraged to use Strings.</t>
</section> </section>
<section anchor="binary"> <section anchor="binary">
<name>Byte Sequences</name> <name>Byte Sequences</name>
<t>Byte Sequences can be conveyed in Structured Fields.</t> <t>Byte Sequences can be conveyed in Structured Fields.</t>
<t>When serialized in a textual HTTP field, a Byte Sequence is delimit ed with colons and encoded using base64 (<xref section="4" sectionFormat="comma" target="RFC4648"/>). For example:</t> <t>When serialized in a textual HTTP field, a Byte Sequence is delimit ed with colons and encoded using base64 (<xref section="4" sectionFormat="comma" target="RFC4648"/>). For example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==: Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:
]]></sourcecode> ]]></sourcecode>
<t>Parsers MUST support Byte Sequences with at least 16384 octets afte r decoding.</t> <t>Parsers <bcp14>MUST</bcp14> support Byte Sequences with at least 16 384 octets after decoding.</t>
</section> </section>
<section anchor="boolean"> <section anchor="boolean">
<name>Booleans</name> <name>Booleans</name>
<t>Boolean values can be conveyed in Structured Fields.</t> <t>Boolean values can be conveyed in Structured Fields.</t>
<t>When serialized in a textual HTTP field, a Boolean is indicated wit h a leading "?" character followed by a "1" for a true value or "0" for false. F or example:</t> <t>When serialized in a textual HTTP field, a Boolean is indicated wit h a leading "?" character followed by a "1" for a true value or "0" for false. F or example:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-Boolean: ?1 Example-Boolean: ?1
]]></sourcecode> ]]></sourcecode>
<t>Note that in Dictionary (<xref target="dictionary"/>) and Parameter (<xref target="param"/>) values, Boolean true is indicated by omitting the valu e.</t> <t>Note that in Dictionary (<xref target="dictionary"/>) and Parameter (<xref target="param"/>) values, Boolean true is indicated by omitting the valu e.</t>
</section> </section>
<section anchor="date"> <section anchor="date">
<name>Dates</name> <name>Dates</name>
<t>Date values can be conveyed in Structured Fields.</t> <t>Date values can be conveyed in Structured Fields.</t>
<t>Dates have a data model that is similar to Integers, representing a (possibly negative) delta in seconds from 1970-01-01T00:00:00Z, excluding leap seconds. Accordingly, their serialization in textual HTTP fields is similar to t hat of Integers, distinguished from them with a leading "@".</t> <t>Dates have a data model that is similar to Integers, representing a (possibly negative) delta in seconds from 1970-01-01T00:00:00Z, excluding leap seconds. Accordingly, their serialization in textual HTTP fields is similar to t hat of Integers, distinguished from them with a leading "@".</t>
<t>For example:</t> <t>For example:</t>
<sourcecode type="http-message-new"><![CDATA[ <sourcecode type="http-message-new"><![CDATA[
Example-Date: @1659578233 Example-Date: @1659578233
]]></sourcecode> ]]></sourcecode>
<t>Parsers MUST support Dates whose values include all days in years 1 to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from 1970-01-01 T00:00:00Z).</t> <t>Parsers <bcp14>MUST</bcp14> support Dates whose values include all days in years 1 to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from 1970-01-01T00:00:00Z).</t>
</section> </section>
<section anchor="displaystring"> <section anchor="displaystring">
<name>Display Strings</name> <name>Display Strings</name>
<t>Display Strings are similar to Strings, in that they consist of zer o or more characters, but they allow Unicode scalar values (i.e., all Unicode co de points except for surrogates), unlike Strings.</t> <t>Display Strings are similar to Strings, in that they consist of zer o or more characters, but they allow Unicode scalar values (i.e., all Unicode co de points except for surrogates), unlike Strings.</t>
<t>Display Strings are intended for use in cases where a value is disp layed to end users, and therefore may need to carry non-ASCII content. It is NOT RECOMMENDED that they be used in situations where a String (<xref target="strin g"/>) or Token (<xref target="token"/>) would be adequate, because Unicode has p rocessing considerations (e.g., normalization) and security considerations (e.g. , homograph attacks) that make it more difficult to handle correctly.</t> <t>Display Strings are intended for use in cases where a value is disp layed to end users and therefore may need to carry non-ASCII content. It is <bcp 14>NOT RECOMMENDED</bcp14> that they be used in situations where a String (<xref target="string"/>) or Token (<xref target="token"/>) would be adequate because Unicode has processing considerations (e.g., normalization) and security conside rations (e.g., homograph attacks) that make it more difficult to handle correctl y.</t>
<t>Note that Display Strings do not indicate the language used in the value; that can be done separately if necessary (e.g., with a parameter).</t> <t>Note that Display Strings do not indicate the language used in the value; that can be done separately if necessary (e.g., with a parameter).</t>
<t>In textual HTTP fields, Display Strings are represented in a manner similar to Strings, except that non-ASCII characters are percent-encoded; there is a leading "%" to distinguish them from Strings.</t> <t>In textual HTTP fields, Display Strings are represented in a manner similar to Strings, except that non-ASCII characters are percent-encoded; there is a leading "%" to distinguish them from Strings.</t>
<t>For example:</t> <t>For example:</t>
<sourcecode type="http-message-new"><![CDATA[ <sourcecode type="http-message-new"><![CDATA[
Example-DisplayString: %"This is intended for display to %c3%bcsers." Example-DisplayString: %"This is intended for display to %c3%bcsers."
]]></sourcecode> ]]></sourcecode>
<t>See <xref target="security"/> for additional security consideration s when handling Display Strings.</t> <t>See <xref target="security"/> for additional security consideration s when handling Display Strings.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="text"> <section anchor="text">
<name>Working with Structured Fields in HTTP</name> <name>Working with Structured Fields in HTTP</name>
<t>This section defines how to serialize and parse the abstract types defi ned by <xref target="types"/> into textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 <xref target="RFC9113"/> before compressi on with HPACK <xref target="HPACK"/>).</t> <t>This section defines how to serialize and parse the abstract types defi ned by <xref target="types"/> into textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 <xref target="RFC9113"/> before compressi on with HPACK <xref target="RFC7541"/>).</t>
<section anchor="text-serialize"> <section anchor="text-serialize">
<name>Serializing Structured Fields</name> <name>Serializing Structured Fields</name>
<t>Given a structure defined in this specification, return an ASCII stri ng suitable for use in an HTTP field value.</t> <t>Given a structure defined in this specification, return an ASCII stri ng suitable for use in an HTTP field value.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>If the structure is a Dictionary or List and its value is empty ( i.e., it has no members), do not serialize the field at all (i.e., omit both the field-name and field-value).</t> <t>If the structure is a Dictionary or List and its value is empty ( i.e., it has no members), do not serialize the field at all (i.e., omit both the field-name and field-value).</t>
</li> </li>
<li> <li>
<t>If the structure is a List, let output_string be the result of ru nning Serializing a List (<xref target="ser-list"/>) with the structure.</t> <t>If the structure is a List, let output_string be the result of ru nning Serializing a List (<xref target="ser-list"/>) with the structure.</t>
</li> </li>
<li> <li>
skipping to change at line 743 skipping to change at line 729
<t>Append the result of base64-encoding input_bytes as per <xref s ection="4" sectionFormat="comma" target="RFC4648"/>, taking account of the requi rements below.</t> <t>Append the result of base64-encoding input_bytes as per <xref s ection="4" sectionFormat="comma" target="RFC4648"/>, taking account of the requi rements below.</t>
</li> </li>
<li> <li>
<t>Append ":" to output.</t> <t>Append ":" to output.</t>
</li> </li>
<li> <li>
<t>Return output.</t> <t>Return output.</t>
</li> </li>
</ol> </ol>
<t>The encoded data is required to be padded with "=", as per <xref se ction="3.2" sectionFormat="comma" target="RFC4648"/>.</t> <t>The encoded data is required to be padded with "=", as per <xref se ction="3.2" sectionFormat="comma" target="RFC4648"/>.</t>
<t>Likewise, encoded data SHOULD have pad bits set to zero, as per <xr ef section="3.5" sectionFormat="comma" target="RFC4648"/>, unless it is not poss ible to do so due to implementation constraints.</t> <t>Likewise, encoded data <bcp14>SHOULD</bcp14> have pad bits set to z ero, as per <xref section="3.5" sectionFormat="comma" target="RFC4648"/>, unless it is not possible to do so due to implementation constraints.</t>
</section> </section>
<section anchor="ser-boolean"> <section anchor="ser-boolean">
<name>Serializing a Boolean</name> <name>Serializing a Boolean</name>
<t>Given a Boolean as input_boolean, return an ASCII string suitable f or use in an HTTP field value.</t> <t>Given a Boolean as input_boolean, return an ASCII string suitable f or use in an HTTP field value.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>If input_boolean is not a boolean, fail serialization.</t> <t>If input_boolean is not a boolean, fail serialization.</t>
</li> </li>
<li> <li>
<t>Let output be an empty string.</t> <t>Let output be an empty string.</t>
</li> </li>
skipping to change at line 784 skipping to change at line 770
<li> <li>
<t>Append to output the result of running Serializing an Integer w ith input_date (<xref target="ser-integer"/>).</t> <t>Append to output the result of running Serializing an Integer w ith input_date (<xref target="ser-integer"/>).</t>
</li> </li>
<li> <li>
<t>Return output.</t> <t>Return output.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="ser-display"> <section anchor="ser-display">
<name>Serializing a Display String</name> <name>Serializing a Display String</name>
<t>Given a sequence of Unicode codepoints as input_sequence, return an ASCII string suitable for use in an HTTP field value.</t> <t>Given a sequence of Unicode code points as input_sequence, return a n ASCII string suitable for use in an HTTP field value.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>If input_sequence is not a sequence of Unicode codepoints, fail serialization.</t> <t>If input_sequence is not a sequence of Unicode code points, fai l serialization.</t>
</li> </li>
<li> <li>
<t>Let byte_array be the result of applying UTF-8 encoding (<xref section="3" sectionFormat="of" target="UTF8"/>) to input_sequence. If encoding f ails, fail serialization.</t> <t>Let byte_array be the result of applying UTF-8 encoding (<xref section="3" sectionFormat="of" target="RFC3629"/>) to input_sequence. If encodin g fails, fail serialization.</t>
</li> </li>
<li> <li>
<t>Let encoded_string be a string containing "%" followed by DQUOT E.</t> <t>Let encoded_string be a string containing "%" followed by DQUOT E.</t>
</li> </li>
<li> <li>
<t>For each byte in byte_array: <t>For each byte in byte_array:
</t> </t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00 -1f or %x7f-ff: <t>If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00 -1f or %x7f-ff:
</t> </t>
skipping to change at line 823 skipping to change at line 809
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>Append DQUOTE to encoded_string.</t> <t>Append DQUOTE to encoded_string.</t>
</li> </li>
<li> <li>
<t>Return encoded_string.</t> <t>Return encoded_string.</t>
</li> </li>
</ol> </ol>
<t>Note that <xref target="UTF8"/> prohibits the encoding of codepoint s between U+D800 and U+DFFF (surrogates); if they occur in input_sequence, seria lization will fail.</t> <t>Note that <xref target="RFC3629"/> prohibits the encoding of code p oints between U+D800 and U+DFFF (surrogates); if they occur in input_sequence, s erialization will fail.</t>
</section> </section>
</section> </section>
<section anchor="text-parse"> <section anchor="text-parse">
<name>Parsing Structured Fields</name> <name>Parsing Structured Fields</name>
<t>When a receiving implementation parses HTTP fields that are known to be Structured Fields, it is important that care be taken, as there are a number of edge cases that can cause interoperability or even security problems. This se ction specifies the algorithm for doing so.</t> <t>When a receiving implementation parses HTTP fields that are known to be Structured Fields, it is important that care be taken, as there are a number of edge cases that can cause interoperability or even security problems. This se ction specifies the algorithm for doing so.</t>
<t>Given an array of bytes as input_bytes that represent the chosen fiel d's field-value (which is empty if that field is not present) and field_type (on e of "dictionary", "list", or "item"), return the parsed field value.</t> <t>Given an array of bytes as input_bytes that represent the chosen fiel d's field-value (which is empty if that field is not present) and field_type (on e of "dictionary", "list", or "item"), return the parsed field value.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Convert input_bytes into an ASCII string input_string; if convers ion fails, fail parsing.</t> <t>Convert input_bytes into an ASCII string input_string; if convers ion fails, fail parsing.</t>
</li> </li>
<li> <li>
skipping to change at line 855 skipping to change at line 841
<li> <li>
<t>Discard any leading SP characters from input_string.</t> <t>Discard any leading SP characters from input_string.</t>
</li> </li>
<li> <li>
<t>If input_string is not empty, fail parsing.</t> <t>If input_string is not empty, fail parsing.</t>
</li> </li>
<li> <li>
<t>Otherwise, return output.</t> <t>Otherwise, return output.</t>
</li> </li>
</ol> </ol>
<t>When generating input_bytes, parsers MUST combine all field lines in the same section (header or trailer) that case-insensitively match the field nam e into one comma-separated field-value, as per <xref section="5.2" sectionFormat ="of" target="HTTP"/>; this assures that the entire field value is processed cor rectly.</t> <t>When generating input_bytes, parsers <bcp14>MUST</bcp14> combine all field lines in the same section (header or trailer) that case-insensitively matc h the field name into one comma-separated field-value, as per <xref section="5.2 " sectionFormat="of" target="RFC9110"/>; this assures that the entire field valu e is processed correctly.</t>
<t>For Lists and Dictionaries, this has the effect of correctly concaten ating all of the field's lines, as long as individual members of the top-level d ata structure are not split across multiple field instances. The parsing algorit hms for both types allow tab characters, since these might <t>For Lists and Dictionaries, this has the effect of correctly concaten ating all of the field's lines, as long as individual members of the top-level d ata structure are not split across multiple field instances. The parsing algorit hms for both types allow tab characters, since these might
be used to combine field lines by some implementations.</t> be used to combine field lines by some implementations.</t>
<t>Strings split across multiple field lines will have unpredictable res ults, because one or more commas (with optional whitespace) will become part of the string output by the parser. Since concatenation might be done by an upstrea m intermediary, the results are not under the control of the serializer or the p arser, even when they are both under the control of the same party.</t> <t>Strings split across multiple field lines will have unpredictable res ults, because one or more commas (with optional whitespace) will become part of the string output by the parser. Since concatenation might be done by an upstrea m intermediary, the results are not under the control of the serializer or the p arser, even when they are both under the control of the same party.</t>
<t>Tokens, Integers, Decimals, and Byte Sequences cannot be split across multiple field lines because the inserted commas will cause parsing to fail.</t > <t>Tokens, Integers, Decimals, and Byte Sequences cannot be split across multiple field lines because the inserted commas will cause parsing to fail.</t >
<t>Parsers MAY fail when processing a field value spread across multiple field lines, when one of those lines does not parse as that field. For example, a parsing handling an Example-String field that's defined as an sf-string is al lowed to fail when processing this field section:</t> <t>Parsers <bcp14>MAY</bcp14> fail when processing a field value spread across multiple field lines, when one of those lines does not parse as that fiel d. For example, a parsing handling an Example-String field that's defined as an sf-string is allowed to fail when processing this field section:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Example-String: "foo Example-String: "foo
Example-String: bar" Example-String: bar"
]]></sourcecode> ]]></sourcecode>
<t>If parsing fails, either the entire field value MUST be ignored (i.e. , treated as if the field were not present in the section), or alternatively the complete HTTP message MUST be treated as malformed. This is intentionally stric t to improve interoperability and safety, and field specifications that use Stru ctured Fields are not allowed to loosen this requirement.</t> <t>If parsing fails, either the entire field value <bcp14>MUST</bcp14> b e ignored (i.e., treated as if the field were not present in the section), or al ternatively the complete HTTP message <bcp14>MUST</bcp14> be treated as malforme d. This is intentionally strict to improve interoperability and safety, and fiel d specifications that use Structured Fields are not allowed to loosen this requi rement.</t>
<t>Note that this requirement does not apply to an implementation that i s not parsing the field; for example, an intermediary is not required to strip a failing field from a message before forwarding it.</t> <t>Note that this requirement does not apply to an implementation that i s not parsing the field; for example, an intermediary is not required to strip a failing field from a message before forwarding it.</t>
<section anchor="parse-list"> <section anchor="parse-list">
<name>Parsing a List</name> <name>Parsing a List</name>
<t>Given an ASCII string as input_string, return an array of (item_or_ inner_list, parameters) tuples. input_string is modified to remove the parsed va lue.</t> <t>Given an ASCII string as input_string, return an array of (item_or_ inner_list, parameters) tuples. input_string is modified to remove the parsed va lue.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Let members be an empty array.</t> <t>Let members be an empty array.</t>
</li> </li>
<li> <li>
<t>While input_string is not empty: <t>While input_string is not empty:
</t> </t>
skipping to change at line 1333 skipping to change at line 1319
<li> <li>
<t>If b64_content contains a character not included in ALPHA, DIGI T, "+", "/", and "=", fail parsing.</t> <t>If b64_content contains a character not included in ALPHA, DIGI T, "+", "/", and "=", fail parsing.</t>
</li> </li>
<li> <li>
<t>Let binary_content be the result of base64-decoding <xref targe t="RFC4648"/> b64_content, synthesizing padding if necessary (note the requireme nts about recipient behavior below). If base64 decoding fails, parsing fails.</t > <t>Let binary_content be the result of base64-decoding <xref targe t="RFC4648"/> b64_content, synthesizing padding if necessary (note the requireme nts about recipient behavior below). If base64 decoding fails, parsing fails.</t >
</li> </li>
<li> <li>
<t>Return binary_content.</t> <t>Return binary_content.</t>
</li> </li>
</ol> </ol>
<t>Because some implementations of base64 do not allow rejection of en <t>Because some implementations of base64 do not allow rejection of en
coded data that is not properly "=" padded (see <xref section="3.2" sectionForma coded data that is not properly "=" padded (see <xref section="3.2" sectionForma
t="comma" target="RFC4648"/>), parsers SHOULD NOT fail when "=" padding is not p t="comma" target="RFC4648"/>), parsers <bcp14>SHOULD NOT</bcp14> fail when "=" p
resent, unless they cannot be configured to do so.</t> adding is not present, unless they cannot be configured to do so.</t>
<t>Because some implementations of base64 do not allow rejection of en <t>Because some implementations of base64 do not allow rejection of en
coded data that has non-zero pad bits (see <xref section="3.5" sectionFormat="co coded data that has non-zero pad bits (see <xref section="3.5" sectionFormat="co
mma" target="RFC4648"/>), parsers SHOULD NOT fail when non-zero pad bits are pre mma" target="RFC4648"/>), parsers <bcp14>SHOULD NOT</bcp14> fail when non-zero p
sent, unless they cannot be configured to do so.</t> ad bits are present, unless they cannot be configured to do so.</t>
<t>This specification does not relax the requirements in Sections <xre <t>This specification does not relax the requirements in Sections <xre
f target="RFC4648" section="3.1" sectionFormat="bare"/> and <xref target="RFC464 f target="RFC4648" section="3.1" sectionFormat="bare"/> and <xref target="RFC464
8" section="3.3" sectionFormat="bare"/> of <xref target="RFC4648"/>; therefore, 8" section="3.3" sectionFormat="bare"/> of <xref target="RFC4648"/>; therefore,
parsers MUST fail on characters outside the base64 alphabet and on line feeds in parsers <bcp14>MUST</bcp14> fail on characters outside the base64 alphabet and o
encoded data.</t> n line feeds in encoded data.</t>
</section> </section>
<section anchor="parse-boolean"> <section anchor="parse-boolean">
<name>Parsing a Boolean</name> <name>Parsing a Boolean</name>
<t>Given an ASCII string as input_string, return a Boolean. input_stri ng is modified to remove the parsed value.</t> <t>Given an ASCII string as input_string, return a Boolean. input_stri ng is modified to remove the parsed value.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>If the first character of input_string is not "?", fail parsing .</t> <t>If the first character of input_string is not "?", fail parsing .</t>
</li> </li>
<li> <li>
<t>Discard the first character of input_string.</t> <t>Discard the first character of input_string.</t>
</li> </li>
skipping to change at line 1379 skipping to change at line 1365
<li> <li>
<t>If output_date is a Decimal, fail parsing.</t> <t>If output_date is a Decimal, fail parsing.</t>
</li> </li>
<li> <li>
<t>Return output_date.</t> <t>Return output_date.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="parse-display"> <section anchor="parse-display">
<name>Parsing a Display String</name> <name>Parsing a Display String</name>
<t>Given an ASCII string as input_string, return a sequence of Unicode codepoints. input_string is modified to remove the parsed value.</t> <t>Given an ASCII string as input_string, return a sequence of Unicode code points. input_string is modified to remove the parsed value.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>If the first two characters of input_string are not "%" followe d by DQUOTE, fail parsing.</t> <t>If the first two characters of input_string are not "%" followe d by DQUOTE, fail parsing.</t>
</li> </li>
<li> <li>
<t>Discard the first two characters of input_string.</t> <t>Discard the first two characters of input_string.</t>
</li> </li>
<li> <li>
<t>Let byte_array be an empty byte array.</t> <t>Let byte_array be an empty byte array.</t>
</li> </li>
<li> <li>
skipping to change at line 1419 skipping to change at line 1405
</li> </li>
<li> <li>
<t>Append octet to byte_array.</t> <t>Append octet to byte_array.</t>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>If char is DQUOTE: <t>If char is DQUOTE:
</t> </t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Let unicode_sequence be the result of decoding byte_arr ay as a UTF-8 string (<xref section="3" sectionFormat="of" target="UTF8"/>). Fai l parsing if decoding fails.</t> <t>Let unicode_sequence be the result of decoding byte_arr ay as a UTF-8 string (<xref section="3" sectionFormat="of" target="RFC3629"/>). Fail parsing if decoding fails.</t>
</li> </li>
<li> <li>
<t>Return unicode_sequence.</t> <t>Return unicode_sequence.</t>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>Otherwise, if char is not "%" or DQUOTE: <t>Otherwise, if char is not "%" or DQUOTE:
</t> </t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
skipping to change at line 1448 skipping to change at line 1434
</li> </li>
<li> <li>
<t>Reached the end of input_string without finding a closing DQUOT E; fail parsing.</t> <t>Reached the end of input_string without finding a closing DQUOT E; fail parsing.</t>
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>Please add the following note to the "Hypertext Transfer Protocol (HTTP <t>IANA has added the following note to the "Hypertext Transfer Protocol (
) Field Name Registry":</t> HTTP) Field Name Registry":</t>
<ul empty="true"> <!-- [rfced] IANA Considerations. FYI, at the end of AUTH48, we will ask IANA to
<li> update the following note:
<t>The "Structured Type" column indicates the type of the field (per R
FC nnnn), if any, and may be Original:
"Dictionary", "List" or "Item".</t>
The "Structured Type" column indicates the type of the field (per
RFC nnnn), if any, and may be "Dictionary", "List" or "Item".
Note that field names beginning with characters other than ALPHA
or "*" will not be able to be represented as a Structured Fields
Token, and therefore may be incompatible with being mapped into
field values that refer to it.
Current (two comma updates):
| The "Structured Type" column indicates the type of the field (per
| RFC 9651), if any, and may be "Dictionary", "List", or "Item".
|
| Note that field names beginning with characters other than ALPHA
| or "*" will not be able to be represented as a Structured Fields
| Token and therefore may be incompatible with being mapped into
| field values that refer to it.
-->
<blockquote>
<t>The "Structured Type" column indicates the type of the field (per R
FC 9651), if any, and may be
"Dictionary", "List", or "Item".</t>
<t>Note that field names beginning with characters other than ALPHA or "*" will not be able to be <t>Note that field names beginning with characters other than ALPHA or "*" will not be able to be
represented as a Structured Fields Token, and therefore may be incompatible with being mapped into represented as a Structured Fields Token and therefore may be incompatible with being mapped into
field values that refer to it.</t> field values that refer to it.</t>
</li> </blockquote>
</ul> <t>A new column, "Structured Type", has been added to the registry.</t>
<t>Then, add a new column, "Structured Type".</t> <t>The indicated Structured Type for each existing registry entry listed i
<t>Then, add the indicated Structured Type for each existing registry entr n <xref target="existing-fields"/> has also been added.</t>
y listed in <xref target="existing-fields"/>.</t>
<table anchor="existing-fields"> <table anchor="existing-fields">
<name>Existing Fields</name> <name>Existing Fields</name>
<thead> <thead>
<tr> <tr>
<th align="left">Field Name</th> <th align="left">Field Name</th>
<th align="left">Structured Type</th> <th align="left">Structured Type</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
skipping to change at line 1517 skipping to change at line 1523
<td align="left">List</td> <td align="left">List</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The size of most types defined by Structured Fields is not limited; as a result, extremely large fields could be an attack vector (e.g., for resource c onsumption). Most HTTP implementations limit the sizes of individual fields as w ell as the overall header or trailer section size to mitigate such attacks.</t> <t>The size of most types defined by Structured Fields is not limited; as a result, extremely large fields could be an attack vector (e.g., for resource c onsumption). Most HTTP implementations limit the sizes of individual fields as w ell as the overall header or trailer section size to mitigate such attacks.</t>
<t>It is possible for parties with the ability to inject new HTTP fields t o change the meaning <t>It is possible for parties with the ability to inject new HTTP fields t o change the meaning
of a Structured Field. In some circumstances, this will cause parsing to fail, b ut it is not possible to reliably fail in all such circumstances.</t> of a Structured Field. In some circumstances, this will cause parsing to fail, b ut it is not possible to reliably fail in all such circumstances.</t>
<t>The Display String type can convey any possible Unicode code point with out sanitization; for example, they might contain unassigned code points, contro l points (including NUL), or noncharacters. Therefore, applications consuming Di splay Strings need to consider strategies such as filtering or escaping untruste d content before displaying it. See <xref target="PRECIS"/> and <xref target="UN ICODE-SECURITY"/>.</t> <t>The Display String type can convey any possible Unicode code point with out sanitization; for example, they might contain unassigned code points, contro l points (including NUL), or noncharacters. Therefore, applications consuming Di splay Strings need to consider strategies such as filtering or escaping untruste d content before displaying it. See <xref target="RFC8264"/> and <xref target="U NICODE-SECURITY"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9113" to="HTTP/2"/> <displayreference target="RFC9113" to="HTTP/2"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC7541" to="HPACK"/>
<displayreference target="RFC8264" to="PRECIS"/>
<displayreference target="RFC3629" to="UTF8"/>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="HTTP">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<title>HTTP Semantics</title> 10.xml"/>
<author fullname="R. Fielding" initials="R." role="editor" surname=" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
Fielding"/> 629.xml"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
="Nottingham"/> 19.xml"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
eschke"/> 74.xml"/>
<date month="June" year="2022"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.00
<abstract> 20.xml"/>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.46
on-level protocol for distributed, collaborative, hypertext information systems. 48.xml"/>
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="UTF8" target="http://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>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC0020">
<front>
<title>ASCII format for network interchange</title>
<author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
<date month="October" year="1969"/>
</front>
<seriesInfo name="STD" value="80"/>
<seriesInfo name="RFC" value="20"/>
<seriesInfo name="DOI" value="10.17487/RFC0020"/>
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="October" year="2006"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and
base 16 encoding schemes. It also discusses the use of line-feeds in encoded da
ta, use of padding in encoded data, use of non-alphabet characters in encoded da
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IEEE754" target="https://ieeexplore.ieee.org/document /8766229"> <reference anchor="IEEE754" target="https://ieeexplore.ieee.org/document /8766229">
<front> <front>
<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 Std" 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>
<reference anchor="RFC9113">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<title>HTTP/2</title> 13.xml"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
homson"/> 41.xml"/>
<author fullname="C. Benfield" initials="C." role="editor" surname=" <!-- [rfced] Informative References. FYI, because a date was provided in the fol
Benfield"/> lowing reference, we have updated it to provide both a versioned and versionless
<date month="June" year="2022"/> URL. Please let us know if any changes are necessary.
<abstract>
<t>This specification describes an optimized expression of the sem Original:
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 [UNICODE-SECURITY]
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced Davis, M. and M. Suignard, "Unicode Security
latency by introducing field compression and allowing multiple concurrent excha Considerations", Unicode Technical Report #16, 19
nges on the same connection.</t> September 2014, <http://www.unicode.org/reports/tr36/>.
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract> Current:
</front> [UNICODE-SECURITY]
<seriesInfo name="RFC" value="9113"/> Davis, M. and M. Suignard, "Unicode Security
<seriesInfo name="DOI" value="10.17487/RFC9113"/> Considerations", Unicode Technical Report #36, 19
</reference> September 2014,
<reference anchor="HPACK"> <https://www.unicode.org/reports/tr36/tr36-15.html>.
<front> Latest version available at
<title>HPACK: Header Compression for HTTP/2</title> <https://www.unicode.org/reports/tr36/>.
<author fullname="R. Peon" initials="R." surname="Peon"/> -->
<author fullname="H. Ruellan" initials="H." surname="Ruellan"/> <reference anchor="UNICODE-SECURITY" target="https://www.unicode.org/rep
<date month="May" year="2015"/> orts/tr36/tr36-15.html">
<abstract>
<t>This specification defines HPACK, a compression format for effi
ciently representing HTTP header fields, to be used in HTTP/2.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7541"/>
<seriesInfo name="DOI" value="10.17487/RFC7541"/>
</reference>
<reference anchor="UNICODE-SECURITY" target="http://www.unicode.org/repo
rts/tr36/">
<front> <front>
<title>Unicode Security Considerations</title> <title>Unicode Security Considerations</title>
<author initials="M." surname="Davis" fullname="Mark Davis"> <author initials="M." surname="Davis" fullname="Mark Davis">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Suignard" fullname="Michel Suignard"> <author initials="M." surname="Suignard" fullname="Michel Suignard">
<organization/> <organization/>
</author> </author>
<date year="2014" month="September" day="19"/> <date year="2014" month="September" day="19"/>
</front> </front>
<seriesInfo name="Unicode Technical Report" value="#16"/> <seriesInfo name="Unicode Technical Report" value="#36"/>
</reference> <annotation>Latest version available at <eref target="https://www.unic
<reference anchor="PRECIS"> ode.org/reports/tr36/" brackets="angle"/>.</annotation>
<front>
<title>PRECIS Framework: Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="M. Blanchet" initials="M." surname="Blanchet"/>
<date month="October" year="2017"/>
<abstract>
<t>Application protocols using Unicode code points in protocol str
ings need to properly handle such strings in order to enforce internationalizati
on rules for strings placed in various protocol slots (such as addresses and ide
ntifiers) and to perform valid comparison operations (e.g., for purposes of auth
entication or authorization). This document defines a framework enabling applica
tion protocols to perform the preparation, enforcement, and comparison of intern
ationalized strings ("PRECIS") in a way that depends on the properties of Unicod
e code points and thus is more agile with respect to versions of Unicode. As a r
esult, this framework provides a more sustainable approach to the handling of in
ternationalized strings than the previous framework, known as Stringprep (RFC 34
54). This document obsoletes RFC 7564.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8264"/>
<seriesInfo name="DOI" value="10.17487/RFC8264"/>
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<author fullname="P. Overell" initials="P." surname="Overell"/>
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au
gmented BNF (ABNF), has been popular among many Internet specifications. The cur
rent specification documents ABNF. It balances compactness and simplicity with r
easonable representational power. The differences between standard BNF and ABNF
involve naming rules, repetition, alternatives, order-independence, and value ra
nges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC8259">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format
</title>
<author fullname="T. Bray" initials="T." role="editor" surname="Bray
"/>
<date month="December" year="2017"/>
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from the ECMAScrip
t Programming Language Standard. JSON defines a small set of formatting rules fo
r the portable representation of structured data.</t>
<t>This document removes inconsistencies with other specifications
of JSON, repairs specification errors, and offers experience-based interoperabi
lity guidance.</t>
</abstract>
</front>
<seriesInfo name="STD" value="90"/>
<seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference>
<reference anchor="RFC7493">
<front>
<title>The I-JSON Message Format</title>
<author fullname="T. Bray" initials="T." role="editor" surname="Bray
"/>
<date month="March" year="2015"/>
<abstract>
<t>I-JSON (short for "Internet JSON") is a restricted profile of J
SON designed to maximize interoperability and increase confidence that software
can process it successfully with predictable results.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7493"/>
<seriesInfo name="DOI" value="10.17487/RFC7493"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
64.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
34.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
59.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74
93.xml"/>
</references> </references>
</references> </references>
<?line 1069?>
<section anchor="faq"> <section anchor="faq">
<name>Frequently Asked Questions</name> <name>Frequently Asked Questions</name>
<section anchor="why-not-json"> <section anchor="why-not-json">
<name>Why Not JSON?</name> <name>Why Not JSON?</name>
<t>Earlier proposals for Structured Fields were based upon JSON <xref ta rget="RFC8259"/>. However, constraining its use to make it suitable for HTTP fie lds required senders and recipients to implement specific additional handling.</ t> <t>Earlier proposals for Structured Fields were based upon JSON <xref ta rget="RFC8259"/>. However, constraining its use to make it suitable for HTTP fie lds required senders and recipients to implement specific additional handling.</ t>
<t>For example, JSON has specification issues around large numbers and o bjects with duplicate members. Although advice for avoiding these issues is avai lable (e.g., <xref target="RFC7493"/>), it cannot be relied upon.</t> <t>For example, JSON has specification issues around large numbers and o bjects with duplicate members. Although advice for avoiding these issues is avai lable (e.g., <xref target="RFC7493"/>), it cannot be relied upon.</t>
<t>Likewise, JSON strings are by default Unicode strings, which have a n umber of potential interoperability issues (e.g., in comparison). Although imple menters can be advised to avoid non-ASCII content where unnecessary, this is dif ficult to enforce.</t> <t>Likewise, JSON strings are by default Unicode strings, which have a n umber of potential interoperability issues (e.g., in comparison). Although imple menters can be advised to avoid non-ASCII content where unnecessary, this is dif ficult to enforce.</t>
<t>Another example is JSON's ability to nest content to arbitrary depths . Since the resulting memory commitment might be unsuitable (e.g., in embedded a nd other limited server deployments), it's necessary to limit it in some fashion ; however, existing JSON implementations have no such limits, and even if a limi t is specified, it's likely that some field definition will find a need to viola te it.</t> <t>Another example is JSON's ability to nest content to arbitrary depths . Since the resulting memory commitment might be unsuitable (e.g., in embedded a nd other limited server deployments), it's necessary to limit it in some fashion ; however, existing JSON implementations have no such limits, and even if a limi t is specified, it's likely that some field definition will find a need to viola te it.</t>
<t>Because of JSON's broad adoption and implementation, it is difficult to impose such additional constraints across all implementations; some deploymen ts would fail to enforce them, thereby harming interoperability. In short, if it looks like JSON, people will be tempted to use a JSON parser/serializer on fiel d values.</t> <t>Because of JSON's broad adoption and implementation, it is difficult to impose such additional constraints across all implementations; some deploymen ts would fail to enforce them, thereby harming interoperability. In short, if it looks like JSON, people will be tempted to use a JSON parser/serializer on fiel d values.</t>
skipping to change at line 1737 skipping to change at line 1627
<name>Implementation Notes</name> <name>Implementation Notes</name>
<t>A generic implementation of this specification should expose the top-le vel serialize (<xref target="text-serialize"/>) and parse (<xref target="text-pa rse"/>) functions. They need not be functions; for example, it could be implemen ted as an object, with methods for each of the different top-level types.</t> <t>A generic implementation of this specification should expose the top-le vel serialize (<xref target="text-serialize"/>) and parse (<xref target="text-pa rse"/>) functions. They need not be functions; for example, it could be implemen ted as an object, with methods for each of the different top-level types.</t>
<t>For interoperability, it's important that generic implementations be co mplete and follow the algorithms closely; see <xref target="strict"/>. To aid th is, a common test suite is being maintained by the community at &lt;https://gith ub.com/httpwg/structured-field-tests&gt;.</t> <t>For interoperability, it's important that generic implementations be co mplete and follow the algorithms closely; see <xref target="strict"/>. To aid th is, a common test suite is being maintained by the community at &lt;https://gith ub.com/httpwg/structured-field-tests&gt;.</t>
<t>Implementers should note that Dictionaries and Parameters are order-pre serving maps. Some fields may not convey meaning in the ordering of these data t ypes, but it should still be exposed so that it will be available to application s that need to use it.</t> <t>Implementers should note that Dictionaries and Parameters are order-pre serving maps. Some fields may not convey meaning in the ordering of these data t ypes, but it should still be exposed so that it will be available to application s that need to use it.</t>
<t>Likewise, implementations should note that it's important to preserve t he distinction between Tokens and Strings. While most programming languages have native types that map to the other types well, it may be necessary to create a wrapper "token" object or use a parameter on functions to assure that these type s remain separate.</t> <t>Likewise, implementations should note that it's important to preserve t he distinction between Tokens and Strings. While most programming languages have native types that map to the other types well, it may be necessary to create a wrapper "token" object or use a parameter on functions to assure that these type s remain separate.</t>
<t>The serialization algorithm is defined in a way that it is not strictly limited to the data types defined in <xref target="types"/> in every case. For example, Decimals are designed to take broader input and round to allowed values .</t> <t>The serialization algorithm is defined in a way that it is not strictly limited to the data types defined in <xref target="types"/> in every case. For example, Decimals are designed to take broader input and round to allowed values .</t>
<t>Implementations are allowed to limit the size of different structures, subject to the minimums defined for each type. When a structure exceeds an imple mentation limit, that structure fails parsing or serialization.</t> <t>Implementations are allowed to limit the size of different structures, subject to the minimums defined for each type. When a structure exceeds an imple mentation limit, that structure fails parsing or serialization.</t>
</section> </section>
<section anchor="abnf"> <section anchor="abnf">
<name>ABNF</name> <name>ABNF</name>
<t>This section uses the Augmented Backus-Naur Form (ABNF) notation <xref target="RFC5234"/> to illustrate expected syntax of Structured Fields. However, it cannot be used to validate their syntax, because it does not capture all requ irements.</t> <t>This section uses the Augmented Backus-Naur Form (ABNF) notation <xref target="RFC5234"/> to illustrate the expected syntax of Structured Fields. Howev er, it cannot be used to validate their syntax because it does not capture all r equirements.</t>
<t>This section is non-normative. If there is disagreement between the par sing algorithms and ABNF, the specified algorithms take precedence.</t> <t>This section is non-normative. If there is disagreement between the par sing algorithms and ABNF, the specified algorithms take precedence.</t>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
sf-list = list-member *( OWS "," OWS list-member ) sf-list = list-member *( OWS "," OWS list-member )
list-member = sf-item / inner-list list-member = sf-item / inner-list
inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")" inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")"
parameters parameters
parameters = *( ";" *SP parameter ) parameters = *( ";" *SP parameter )
parameter = param-key [ "=" param-value ] parameter = param-key [ "=" param-value ]
skipping to change at line 1784 skipping to change at line 1674
unescaped = %x20-21 / %x23-24 / %x26-5B / %x5D-7E unescaped = %x20-21 / %x23-24 / %x26-5B / %x5D-7E
bs-escaped = "\" ( DQUOTE / "\" ) bs-escaped = "\" ( DQUOTE / "\" )
pct-encoded = "%" lc-hexdig lc-hexdig pct-encoded = "%" lc-hexdig lc-hexdig
lc-hexdig = DIGIT / %x61-66 ; 0-9, a-f lc-hexdig = DIGIT / %x61-66 ; 0-9, a-f
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="changes"> <section anchor="changes">
<name>Changes from RFC 8941</name> <name>Changes from RFC 8941</name>
<t>This revision of the Structured Field Values for HTTP specification has made the following changes:</t> <t>This revision of the "Structured Field Values for HTTP" specification h as made the following changes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Added the Date structured type. (<xref target="date"/>)</t> <t>Added the Date Structured Type. (<xref target="date"/>)</t>
</li> </li>
<li> <li>
<t>Stopped encouraging use of ABNF in definitions of new structured fi elds. (<xref target="specify"/>)</t> <t>Stopped encouraging use of ABNF in definitions of new Structured Fi elds. (<xref target="specify"/>)</t>
</li> </li>
<li> <li>
<t>Moved ABNF to an informative appendix. (<xref target="abnf"/>)</t> <t>Moved ABNF to an informative appendix. (<xref target="abnf"/>)</t>
</li> </li>
<li> <li>
<t>Added a "Structured Type" column to the HTTP Field Name Registry. ( <xref target="iana"/>)</t> <t>Added a "Structured Type" column to the "Hypertext Transfer Protoco l (HTTP) Field Name Registry". (<xref target="iana"/>)</t>
</li> </li>
<li> <li>
<t>Refined parse failure handling. (<xref target="text-parse"/>)</t> <t>Refined parse failure handling. (<xref target="text-parse"/>)</t>
</li> </li>
<li> <li>
<t>Added the Display String structured type. (<xref target="displaystr ing"/>)</t> <t>Added the Display String Structured Type. (<xref target="displaystr ing"/>)</t>
</li> </li>
</ul> </ul>
</section> </section>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Many thanks to Matthew Kerwin for his detailed feedback and careful con <t>Many thanks to <contact fullname="Matthew Kerwin"/> for his detailed fe
sideration during the development of this specification.</t> edback and careful consideration during the development of this specification.</
<t>Thanks also to Ian Clelland, Roy Fielding, Anne van Kesteren, Kazuho Ok t>
u, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and Jeffrey Yasskin for <t>Thanks also to <contact fullname="Ian Clelland"/>, <contact fullname="R
their contributions.</t> oy Fielding"/>, <contact fullname="Anne van Kesteren"/>, <contact fullname="Kazu
ho Oku"/>, <contact fullname="Evert Pot"/>, <contact fullname="Julian Reschke"/>
, <contact fullname="Martin Thomson"/>, <contact fullname="Mike West"/>, and <co
ntact fullname="Jeffrey Yasskin"/> for their contributions.</t>
</section> </section>
</back> <!-- [rfced] Terminology. We have made the following updates to terms by choosin
<!-- ##markdown-source: g the latter forms. Please review:
H4sIAAAAAAAAA9V9+3fbxtHo7/wr8NEn11JKUqJetqQoiWzLsVo/VEtOTtr0
+IAkSCIGARYAJTOq+7ffee0TIEXacu53c9qEIoHd2dl578xsu91ulHGZREfB codepoint / code point - 4 instances
ZZnP+uUsjwbB8zhKBsHPYTKLimCY5cGLq6uLxiDrp+EEnhzk4bBsx1E5bI/L Member / member - 1 instance
ctqLi3YxxH9vHzQGYQlP3D47vTr71OjDH6Msnx8FRTloxNP8KIBJinJne/tw structured field / Structured Field - 3 instances
e6cR5lF4FJxOp0kMT8ZZWgRhOgjeRmHSvoonUeMmyz+M8mw2PWIIPkRz+Gpw structured header / Strctured Header - 2 instances
FJynZZSnUdl+hqA0sl6RJVEZFUfB48O9bqNRlDDQ+zDJUgBmHhWNYhLm5ft/ structured trailer / Structured Trailer - 2 instances
zzJ6KM0a0/go+GeZ9VsB/CtOB1FatoIiy8s8GhbwaT6RD2Ue9+GnfjaZhvJh structured type / Structured Type - 2 instances
Ag/DT3GaxGn0r0YD/ozL+VEjCC7PXj4/Cppvnz8NUvin2WiEs3Kc5fBbG34O unicode / Unicode - 1 instance
4B2Y/lUneJ2VZZyOxuGEvma8vgrzD/4vWT4K0/gPQs9R8DTJZoNhAoijH/s4
bXCRh+M8TOmbPBrRgz+fP+Unslla4gacAtrzMIlD+jqahHFyFEzSrPwR/9UB
XNIPsxzwgptaHG1t3dzcdNSvW84KLtovOsHfwsnUgv4imyXtF1GaAvTmNxf+
q3EEZJWncTEOnoZ9+Osiz36P+qUN1XT84cdrfqjdx4c6MEijkWb5BIa5jhDR
SA5HAeD5sNvdbsAX766ePz6iUYSc4Yv241YQAsWFaTHkl7M04E9BNgzOL98E
3e2DvQN6TW8U/NPmVT7vBL9G+SgKZ/StWqj3NVM8kPRuu9ulb4ooj6MiTofZ
kbx4efXsKDjYlb8A7KNg92DnkOENYaySsS5Iz4f9djSIyyzHpW/hSFvAQTBA
Az9beDg/Ozt7tL93VBkJ9y+OoujjNMnyqIMfaSxg4hnS79bjRwcHOwoERhkO
BmIAWCfMB8T3z5MsRGpsX2RxWganeVyOJ1EZ96sok7W5+40jOkjqHra3Hy1A
Ej58FMBq2vicfPnszflRANvUgX0+3MJHAJcdfKBjrwDevnzy+ig4fPS43W3v
b+/ttfcPd2AkpA0mk12eZxAX0yScs0TZ2kFaujh9+jciJpgbd/Dd6/Onb56d
tS/Pnr57e371q0tXadzPBlFwGfWBWcp58BTkVjyIcpZgNbRkMfez8Dou3K9j
IPAkuJzFoxSw7iJrr7192BZUVPH1UIFyFfXH8DFMQHROQYQ9PAoePugePFxE
XjN+j+ghpzeKrTLfPQAeDy7enj09vyRsPN452Gs0rqN0RqRmC2IYdj4FGH8B
AY3s/hP+Bt+OM1yToj/8782IpoHfmLm11mjfjH682SXWBoTl/bF5L4mLsujw
j1un8BMQe7F1MeuBntiyB8BhcQHm1REQ6KzXASEts9N/2tHHMoJdgv3ZSsJe
lBRb4yiEPWsXSuk1+M12XBSzqE0Pwaj+Q41Gu90Owh7KUhBajatxXASKpYJB
VPTzuAc6M4TtIhkDWxkSrli1hUUB2ga2Fz4moBmRnYqgHINAApkOUgfAHMCP
ZQbo+gBflEEUFnGU09tFOIRP8NsgGoLmoe/G8K8kol0RcOlrgC9O4PMQNTno
qg9pdpPC9EHTV/NFs+V8+YIGwW+B/+0frnjIotkJzssA1q2hRUkxK6KgNw+K
adSPh1qdAwbS6IahY1B4sTeoAGAh+FZIKhUkczFPy/AjPwDDT0Buwe6yAgYK
wB9SXBgIRhgcqN0MG1yTrdLxd0QbBkjPZBt0ZA8n8QDw1mg8QFsizwawShi0
0bikBcyRqEtQTwKTvQ7B8oaF5k21uBi3OQCrA/gBlhoWH46DCDgIFlyOacDR
LB6EaR/3Ori9BSFCSql70Nnt7OA0OMWnTy18FpaPRDEJ0znseD8m+g2Q/mDm
aVwOwyShvxH/YTDNM8Q+ocrCDMsiWPYbnDWUbxFJRESDVgAEO82A2KZhDkKG
CRWlDVgLf+Df2RD2GdbPdNmLghugW/gK3+yHuIURaGl7I4AqiQeSeDQuE4A+
HgLl4oYQuSJyYak3uNFJln0ogiSG+R0yqGxlLNtkc5e8QUymmbTQ9AgopkXG
C4hRqAZXFQ4G8CZSZwQvAip7STQpgNJTRAsovBkYXS3kR0YbAjGKYJ9jsCCV
PACSHYAsx+lhnAn8AAboiPceqTzt50CLGrfaHglAS+PsTHShGgfAJ1hvb5ko
FvM3IOs0tRemeEj2OKDtqHJ5cwGPN4ONeEjkysP1gahh36MYqZKwEPsDkixp
biLeCYsi9BQAsJYSt9ORD5Yoi8tC8RourwdCr2+IJZ8lUSE8gUImnoDLwEza
ywC5+LbZ6YocIoJVlK0HhadwnAipi8UVonGgpEsybwXDGS4uuIZ3FQURkhEf
SgYn6ImQPeZuLD2NiPCog78FIjMEi4SSZDcIlC0kkYQtcmDeI2t2gvw3YAkZ
DWGZMawB+AwpLZuV8BxhLRLsw7rAq5DBePPAqkcKzkIByOY0mEi96snA6CNo
ZhzaEujH9MwETBCw+4pJobUgoBq2CzYehViWAni2eoOlwPoGzBz2qtFihQXh
crIpsX1G3ASLuL3lbZ0DLxhdO85ucED5CVblUyW9SeRI7yn2TWeTHnAQLEvv
kKWtCRahewIUFlJRnSSkssLaY35Z3tNCdMDLILmNQhZUZp5NaiTRrFCKxzIP
DEJJZ5RgzHz6hHrsASkv9D6ZYBFA0JXoU/VFnNw+YP35ScSpyxex87ZCDb9B
kOIQtjrg13rRGOzYLFfwFmU0bffmbfyvBThTBu18lOcgaTTraalAsncIMoce
RViQVqZiTCNzZWC8Ah3Bcs9FohVgKTMNRSm4t3k4inCIcjycJR5HE+yjLCP8
g07GgXtxAlZ7B11R8PCBg1qosr33aPcBDZpWwUaf4vggNJi5iPdKMC6AH0kX
xekUOO8GnOCB2G7elPAbbH0LpBcqYjaD6GnQCmARBqQCZsQrQYZr9sUTgqK/
QiEYg04KNnowLepPQHMx6znqdhPn/BCCMZISsZ6rkTGKooMbqO4UvbABY9FF
MATgCKphjQQ/RnFCwgtFStoGHUfuKelrxAdjD3yufgZSFDUR7Eg/y3MwVOAv
QCdu/JQ1OyjCMAf4yVK+zmIQCSzefUwySYr/RRa7MOwEDQ5eI5iYZD7OktKR
f6QK+XuzJsID0D5GdYa2kRROp0ZkzYMJvBXDDrBRALNuRJ1Rp8UQTsBlD9FJ
Q61qTB6MHIFFmJYFa0GUCzBkvkmEx5wRk9FIo84fFmJExYXaV5icDS2LS2xz
SzGRsKzIBlhzKJsIPuo172iBgiAKPkRzJoKg+erd5RX6APjf4PUb+vz27O/v
zt+ePSPf4MXpy5f6g3ri8sWbdy+fmU/mzadvXr06e/2MX4ZvA++rV6e/Nlu0
hc03F1fnb16fvmxq+0AroZDYC4mHcDtFy4nsGEcaPnl6EXT3QCj+D9j3O93u
IUh4/uNx99Ee/HEzRjsVJyM5xH8CFue0syFhHugX0AsGdZigKgZyGKOzhPKh
YoVq8+bnpy9O37aCy4tW8Oz8p/OrVnD68uLFKc/17O/v3lydsdnCov729gcA
an9nF4GytBVoTdQbYpxsseUY58wiYJanA+TK08un5+dAfyXaCoMISZJs6BSN
StQH5JIZ0wtHJUDe/HLpQiGWpJio4FFOgOpm+RSUWP1abTfVgL2CbugEvwCy
9ZOewkNG86Qb0R+8HOkxtBkbw3rJ8JiB3xiCac7DDTNlNrkaE1byHN52AQPo
nekrSlbbOyCbKMaLbH8TEveJgGJDJDj3IT/9FRgxnzNUhFcWkijh1FqKLCBv
IOQ9AjMN5SMJnxgJkGUi0Ch79EY2KlQrWOvsgTaZFWIVBM/IFIZ3XoO7UzFa
0CYQMwp23DKcHA+CxKT/bossbfYoC+URHjUa34KskaAkLADUKko+QpevMDrB
W/hrGpM4JO2MTlRYZrm2l3l+5W5i4ELUMW3Nv2cg/CgAXzVcOYSCFjFgsoNg
nWNcHxcHjE+Kz0wQewt8IW593Ik65OL0yZNP5rYFiK+LF1aI6w7+N34rrmg/
LCIU7EHVqQo2xAhmHpUvZZhNCrdUMQ7qHbTZJi1GQhPau3IRRprgWHy04CXw
S7Bxe4uhtE+fYPRnMc2DVApfD/Rf9CNMfV5GE/wFHKUJfEcTPrN8gAiVetwv
aiZ1gMNgRaidKJRPaBnHuF+zaZb675K8vYmAAYQv8AXYZCSfgsQ1fIsWtj0Q
7jPwVIJxNJRa8ykGP9FhI3qYRGGqgmoyl+Uc3iC3FTYqs2k7ia7Rw0Kkwn4i
8myMGQRJ8KVEuCzPlSwgkksm1Fe3cpAdz8ndD1GCIJkIMTl+Ou0dWzIkDlE/
oZ0/ggcnETothVDLJCa3jCY9rh8tZcB5OIKTiRpdhXRUsL4KLa+Xfy74Z6D9
UcwnOjqClUTgfOZB8+8cIlRPAl3D4FGOHNCBNXyI0AJrAeSp0GNB9IV/toUs
jWsIxBAPeL9r9szyCcXYFI/wecVdjmDfKMAvK+RNxXnCwXVcsFDpw99gzSdz
mxBA65p9lBB5QP+a4uEHIHho713hBgpxdnQlUVUMY6Whbm85nk6S+bm3rMKI
GIa94p8pNV01+VriwWPwnh0WELnZsKMCmDoCi1OQQKYolxKuqPY5JlQYgSPU
gz+inWb9ooSV/IRBI+tXM2aTBp0CCqY5RrltOiCjy0CDbGObsIugoV8XgKN+
q4WHf8Rx0wi9G+DjTq0TrNzeCWzLZDYpNNaTKB0BzcNfJlQAaj7G0K4VbSxm
U9wF1th+RAntskEWccBFEdsk/IgzgQv3R0SMM8mKklQH8CO6c0rDgiGKDiIo
oPCGDGKkc1LSvvE0INcQBaWCMAH/EJWkuBwwFXupg/g6HszQsbMMoRJchcRa
pvrN2KR6BIseZYvwAVebdcj/OGNWaTROYTz4viS4nmdZW35RA/CGsYjq2cZT
WIBx8V0vyfof6Oj++8Z35fd7Ox1nEFHcxF3fbZXfN/Ah9HGch6zIvcQ00SWa
I/rN2XDYw+gZWP+Nyaw/xgEkuAXkM6KodkfPYI8eG0FbtSiY7f8J5j+mBPwL
SUI8vAaZvLi7qRbwG+pIYLez2+kiwvWbm2ZyPQRtKKZZsPYMJ3jej28h7GJq
CPgs6sGwwVkbPTSzy5sIBO42/dDdRje2n8wKsOKOJU4gYSmCkzzQRnX7JeLM
vtoozWDpHWcfjJkOVipICdQeJjZ9JM/OEtjdJP7+1HrqhlQ/+qrwfHOYZbM8
Ed+Rf9KOcijivhG4GNx1MdiSbVdSG7H07u1LeEsxvSCrE1xGiCHUl/iTFSKx
bVBYKIDc+G4Locf1KiDJMQPlj5C9e3veNjaxBm/PbO/u4eMD2N7gfNiIS8v9
ZxnPutEZpVXDhrQPmqTUTsCYgTMmBj8SjlfXArXTcIBqKYrBQUHcZck1kLZ+
ft9dAjyEIbUGx8jQarYZRmtPtedhXmKA6nvAv8VOR8EO6lrE40lTHezC3x15
m053m4B0/fp3W7aMINlDYZUXEnBsNFxfFIRV0apqVvQ0GW3BRgHb7/pWsD+1
Ghw3CYNbeTxgJW7OxQYZhUczCfRNwcNLZoPIOYOQUyR4aliikD82mpJMA7DN
FhnUG45BIpIehDiNl4fpiAS2SBa2Sp+BaJ2EavUmF0bMQXrmKvsQpUoxsD2L
DMweUGjZxSpSxeaoTC4aBIVhwS+g7YcOBe0BYbqtNPBCs75+dwDwTG1RC2y0
RI7sqhajUuosxsxBks27ri1OcT9HpHnnZyLgEUMyjJJ6RnyL+la2J4wAWx4B
r5HrbOlzRWd6DbANNOvDYoHhq7RiYcKbEue7ALaM8muc8IzzHDhMCrZgxfdH
HNshdDzVk3cQCfpA9+MU001QNIx1QIyPZ+g0G3fSHCQhywO/pOpkUB0Yi9lF
2QzZgL1DIuaAz3Qse9s6+3NcTR2KTfkEtcxBmaCNFxZjNjSeYISYqQ3ftt0N
dnculDopZBsjG0nm5Oq44j2yUyA6EBkSSTPXOJOwcNgn3x+TdvhUwLIoiKwo
lNEDlXKVUZAf9opY7wazrCivsBRgWrJaL4uCNg1D6HTYIYdHAxXk4QA6DIu7
hShLgaowhjVK6ejJqFNZPonGPoYWxVZ7vmhSj84ltiCc0BI/GQazggultUYH
0Z3AdtYQiDQCe1CfOwmTMcOS0yaxdWEtdhbDogD5pgDibZeQDUd1vS1HuQNo
H85yBp1PWGR3YbddWkARcw3KgUhSrCc+A2ajwzlzQtGFsrZwElmmmG4iqRSe
ld6qc22RrIwTCmA1R3kEnkDT7FtBMmYwYA+DDw9Aep16fkyfZEtRxtMZ0qkE
QJLEHkjkDIoohXWgPjzBlv2mjRuINRQXvC4V8TBrR/db9qCgPBtYRIahZHFH
gQyRdiLM4wrI58IDNMKUIWSUjSoUSCSNx/QU6lT4I3C1+4SMhtYtAmd2uOry
6miAJstY+Jf0B5MIDlLLg4hjpnudjuFzGEaBTNRK/FdEEoUaTIoXhUzg4VnK
6Vcf0N+wbbPLWY+DXaXPfQgt4dxT/ziEE3uwFagEmXwnnJJDdAYcxwEqcUY9
ofC8kE9ad9xk6a/enAxK2UdBPREoppGycjZTx8MaeJVpaqXWwHy44bDB7Em+
K2qi2VdkmgCXnunkPtAGosBqOA3FcMHJDcrsDTXaKT8MaaKiMh07SAsHK8XI
WNcIN7ndkWg4dFGcDBjADkxUiQIyrDfmeYZYA1p4gW7cLA4NqgNAIXlG+DNi
fxKht7eolyjIe4MhIgqz3D2dypYT+9YYBnHJAVTKRIlCOZOLU/ZRNkRU8ME6
sTrwVzTYrAmNcCwh9ChfhWgIjSoJAJkWiwQ4VUuSckxKpxXZ8mJ0aql+OhQx
pnVMkfkLNsFEhUqDAhJ0lujiuAWf4tBRAR+MmSGVMMuUFwlYhHW+AJP6Gk1G
d2+9HAf008P+B5RTRVsJKiBAWoKa4tgTmRrVRfXUhPIKtTCkt8TDrFqLPokU
FtKshMp30xFmZZLkrg7ip1ZkKmKGOTjRDcCcR9eU3KjCS65e2ygwFhN6PAAk
xR4LCees0DqcaQr3yM3xo3yLiMwzXi6qk5ygFmsUkw8w1RZXpoJRfRzICk7L
DtK5g8PEykxFuQfY4fclCIByBu1b0EZ0TiEDEm3ZHEq2NWZwjcYLPQJHGyqz
E0dCi4CIjmjOQzr7n3aOQMBY9eA2VM7WlAhiX4Z5R3rnQ4/sZFLE9oxoQwlE
P/ja0uAwhHjYB4D1I4pciFEhgVGmZMzbwOcJeSz8lEDKo991VonnZibZCBM1
0TkTeohTJ+uMDiJ02oiJAgjpGRVmjKlN2WREEOa4wJc0u8hAJ6pZaEXP54mw
edFUPWzTVOOBzUHPMB+N9dztA85gUyFsib/Au9fxIOK042v0AkFJ+omHVkZb
lT1nhRi3I8yyB4oAvoqGcsg81VlUQugktjHjjlJ+aSIUEaIe82rOG0ZQZk6u
NhCqSmKznFoEGFCIkRk1hSZBO2fOSU5eMgclO4F9PgGnhE6or3RCdTnOI//Y
T5GBcwYuaXzGPzlix7LlWJaMPXJF6CRUfE8Mttj2J84s8gCI51icSznPU1Ox
Q4Onjfap2c04RjLM2e4uooQ2Ks/DeaFDLXxiu8QZlhm04UzoIy0CNuUWc9I0
jMmgRpuL37p9QEd1jYasilCoJv4jyjMElrxefTKpKIOhlmlV9MScMNMJZmqB
WDkdbHH2lz+UuwJ4iViSz6zR0J1MQQvQgKRKgT1ZJNAJjFCO8psl14H8JHFU
KLc4skMyThiI8SDGF3wfYh4Zz6kOwynOZdEo2VxVGhVMMd4oESTClZTKqkbx
HnLq0lSsf8ADCPpp2I+WmpA61ls9VgZkcnhP3EVMv6csM+CR//73v1RH05YY
eEPisW188wiYaYQp8GUUtoJ8NsHH7bw6Q2WEHJe8C8ApqqwcFLVJoks4RCdK
H88kF54oUZ7AFP42NRP7HNznjCbP8CudYwekWjSBAC8ggT9zpbARa7zo/aBH
0UafdRCnkEThLtolMULRuw6HlNhJ+FMHNoS346AaoiYkiBQFQryQgg4K3yuj
S/aJJRFhpwwS8AvKoLu9s6eAUbHuGrdUe3C2Y4QJDyFaUyEZYe5JI61J9C6n
eSgXW0KYDxxJdfvAEgPE05aQ4KM2kkEVESThIJPEwvIQwbSgMeIRf7CHLkG0
DlcRMz6Hk4lXx+FONJJCr1ocFbOc8nLlXAwIcwxmv2gTJ/LILyrHsjenVFG1
ZpIGFA1aXQLYUFmx/7UlwgaedjWDZi/MmyCtN+DDH+pDCd8DnPTnpi8r6HQd
SU4Jv1RF4+zzVJaqBliU726Eft3Fkrqz48ElqxiyAz4bAeB9nXSPeyc7m8fJ
dXKyzwjICTGAD/qyyyio5UhHS9fw5c7+wVdhS4v0lQhawJ0Wym4fMB/QWjQe
c9Lw4E5RjvcknOJUYFe0LbvCGNp+iKzeOFhiGVD2PofTcLxZGv97xi6xyrDu
ZyY/7sKOf8Lisn5/lsvTmt1sZutRImEltmwZX0ZAT20xoWSySaKrpIrixovR
Tl5AQeELC0QiSAyXpINIiqHmuNRO4IU5MeuUzmo4Ks/nFqhD+n1dS0ZJUobv
pu6WyX61VGGKHBMQXmWFyoMFUuXULkn/KtaRgqFZn2vnkEWP8TPafnfPyfCh
ldnImVPx3yTuZwl6nvaZ8p3cGvb6x8Kpx0F/EL3f2z8AXh2N4+PfP5zsBcnm
8b9PmofN4/zkRrOrmtkTNU+yDJgzVefEPf4TKRccrIi3OQOBzXgXP9XFl2fC
IQ02Qyvsz5EaLJHJMd8LbL+EY1LNXtPNpBiGSbF0/XKEchRgpOg46J38sF0V
yXRYqQNFdI6XUjqgm0h9bOpEUf1Q2Ms+J/ITmVkcIVIsLKAxSPn3ckSsl7PI
anGEoUXG5J3WkA/TtHrbo20WOmrEgz0rC39lAUu84wlUA5ef1qqV+UMlmTWy
B+JvOc7i7QMrQ7fRqDiSlqQtakStBHsJUC0lizGiQvFnYR34e+LPN6PIU3O9
zbVdM3G/5bl6x9EYPr5kr5Pq9pmjL9VXF7wOZu9X9GqdDWaL0JxED7RtY62B
uI8PmZSVh1Weaiz7FGY1R9VZ2VJ/1cqfDusOoDnAZheE2if0Lgbnfl6sSh1B
st8oNslDqfF9enNr6x3usTL349wcwxlpNUBKUi6yU19Ae86xPD2RTilTBKZQ
hgc6fE5XzSx56OeM6r+objIu3KzklQMAr5TZZbE0pltYr1K4qyYuQPRUGxjg
Qe/Q4rbE+xshIx3YMsCZs3nSDDZUbbGZanNl/Ys0cgQ0fNLEZk8RbE+zFQzC
k6ObvX/EvZ9+3r45+Md88NO7kyNfLXmegXj2aM8SVGj0c/0bO3mUvsgHCWHw
ZF5imxYuJlCmWS/mqgfYplcOSXxF1U6ij4QLqm6qfOs3OZ6Xz1ZAXAj6GiRu
K+hTXtwJ2Kf/D9S3wstCNW5JM92O49T+VhohiNPnZ3A6br6OU92NnZw6FJ10
O+B4DaMI87yKk43fMxBF4QBrOsX9rAWFCyhqI6YtPn2gJ41mX2W3NrrBDkYv
T3Zhy072jsPwpAe7NzjZ2A8ONo/p9MffwEquwteIot1TlIzXiZTYbaGzdLKz
SojMesv7zhrizviYtYdfM0rmbseiYJkXOScK+qoWprV6Yzata2kytd8+IPOO
42toP1uRepWLjm43faRofKiyR+nQkj/KD5LvCN+zXSlfEwvjtyV+kC8dsYw/
KpHMvyrpa0teKXfyDkypuMKkQpigguUfuHG7+uKr+hwBk9qJyFG/Wtjhk72V
okXa/9pnKs/ydcSKedsT/xI5lfReDJvyZuHZl3wphp9OBm4fHh62vP/jUuu+
1tUAKgoym1L+RTwskb8G8SgmKUm5CrBHyFbUQu7R/p6XU3V7K43quBBqNatB
r3tPhINeVYI9zSjXIQ26+wKJ7rqh63HItcR6mIhjXzfgwngisDdXCRuLaHgZ
uXLfJe1cijMq9MHhrn7JaafgvIQJJ5/3S+rH9As59JwxywkMCVky2owwW0vE
ArxAwWJ0nnTjgeb29vYOlke1t7vNTTYXOXeEfKwN+B5DsCV1nOEi6j4LnEk4
V0fXU533V9sTxygpMj1J15uk8tyujjUn02AyY0MqKe9DnOcAvzRwOHbTCzgd
QsTeDfk5lECrwo8qaR3dYhE74BOrL2mUmZhyEk4UTuB842CIolelz0szBg4h
quf019y5quSKrO6OkBZ3MqkbxnmeD5b5lYXSZlnMWsnXNQLR8gowSUeEy910
pVF3B1119oWyOru7e0RGaE5Un93v7Oxu86OdPaK3Ch3Kk/DAfdIjO6N2lb+p
kkc+jvK20VMBt0FRjVpw6dzEhdrKWVuHogJLNTgnSaUB19LQOaVb2z2g9JkO
anIgrrlK6Mq5qCG2q/qsNgFz6zzaSveBfePABhfWuKtV/KEOcLjZD0guyvzn
8E7uRVum8H1JKYzcVIK7ZcBmb4NhZHWjMIFvUR7ffNzZRnC++fjobJMa2Lp5
1FTZgj3veqAT0uiGzK8WHj8AxJTsW85yLCuJyj5tYtpmCOwWGCrfKBYfxJHl
umTZyVFS+Z6m9KTSLoY7xDBVttvSciq6QaCjKVMfdtGz08UGGQFikmGNYy91
D7q6gbvvee1YuMyMeuLIKjPqqUNWlFugTOX49I3WO1qVKfpYJ9pub705NqRF
D7IZ7jy3QW5pzYcJhkUSFmPQF7/9BmoE89xBX00j9w1pzSYPR8XK/j+DdBQ0
x2CoYjVUngyavgek4NYF0dJFhSSjWkh+jP2TRgYk2Sj5XQ0CkHHG/4QaPNGQ
ajh0v2GVuqkdLXSgKh5tahxSnTs+awogdcKa9NxZ5ECo1WzwKNLDMUPRsOm5
B+RKWA6CcLXkadw+YOMZ6xjoi2oslxv5EBKpXl+rwTCZjsMe9us141O19LfN
lnh+LHtIRFDT0RRLONBqNwC1AicBiX1M8jao9ZkZhQ4n6O1mcPrk9XNqPWMn
D6r+M61gmsw4vtY8kojIVtPFwYqkRUght7K7s7u1t3+w5KBVEOhifx+0vDOx
oUgL4WoRZHmKQeOauLo/AjWR073+6lrmsSRChafki5Xhj03UdElJLCmQlbLy
U9PFiqStCgCTE5/qSiEZRnGFUJZj0iKFiUnbaHi/CIuwMIsW9sBb4yDQtaZJ
NToSis71WNDgMjBxlKVULywi8KNBWIK62jvYe9wKdM0q12auRi8IgJr/KDjq
v/hrMvjp59k/nj7ZDn9K/jin//912ps8n0eXT37v7exv/+OX/e2XoxMVnKwl
LQ9xHoMf7D7eAz1eRqWSKkoW6C1hX5c2Q9xeLG2zIm5fZTdkAmmx1LeO5LVZ
2PzBYkxHaIRBs9sU9Wcd8KF82ebv6WBy9a1haI6CH7o1YeAlDWyIXMwRs+Xz
6/pUtVKC01muf9KiTkXY86DKenA7MOIAPodOOl55N3gEdf5iRIMKKKg2fsCp
yqdqmZMg1s8bYsaDPRGNyMzcRL6BsVA+RFjKJxVU3cNH22Cvw/+utreP6H//
aIlxhmMBDqbqDRAiKgOeW+dg7Mi1ptH2rebWemDTSqw641ZgNetSh/xUl+RT
1o/NO+V8G2Sb8XWoL/qP3YP9w/1Hj3d2d5cwJOPdcrYKjmcMuJ/OIKTWD8Gc
gtddCYEcKrO3fbDT6u7ut/YPD1qPt8nu3dnfbe1t77R2unvw323ZgDuxv6lJ
ybH6+IjXtvrwlNd9ghS9wbM2f1UWPpu/2H2eA+aOnW+rb0x7t6ojVdt4jEiE
OstMVo7IeVdtfiO2MnE1Za6NEL+bdFSGvZuNhqlbRaVTeMydsgo5pw4tf5hf
j6TYEsW/fTgslUXkLEa6mU9eY2mrLuVeB0ILdVZfryIGImdPQEFUEw5C5FZC
mlK5QCWaIP8BLcZBUYjEIIHVQaLv3BignGO630Kx3qbb47L+jXE2yUZ5OEVV
U6JZvsmrU63jJ1yEhQ2C8dQXcCVnOvqQp+MeQbg7J6a1EpWStQd8je6c3RFN
Wo/ZLXMHmKOoDhGx69nQ8pgEfBEHOn62yUn7NRKnVYGNq1XNeTkpObBe8fSm
jmeEfAnEdJHriYejMFxbLI9jJjhumqGF1jdNqWJVIo5lGwkAwwXrSDVemvKR
vmny6b7XX1/4gjzw/u43vT6yRUecqEs641DUIicctk25gI7oEE83R/BwjIKr
8UBf8UC7VVPdpZqUP6CSDq88RVV0qh7NOgSlWyHXVaooY7uHgWPVuHlBpYc+
tNbpYrR7ktDqlsvRRumOrXIBSEAWJd4PApNIlAVfpIbsmfhSdEUIui/4Xz5L
wLiLVU1Q12aRDp30mgE3P8XX1OBMd49a3h+9JUETdOWYYFkUgQSOS78M1S1d
UVZMV6qzrHbjTM+WOZVZGXdOqxhOEzEdEVGMpZk6eQLhLxLCbKtfU6FepvPy
nkrG5uIsbkKWSr8uTl8CxO4ugpjTuhLs/E+9M98LMnqqa6dq6ZvPuGOdvT2h
TiQtrPZz2mfTU3UaO53gLCm4IchSvH0BLK4tS2FKx56tg2tvKVyqJcPngmQy
cBEalfhVB8e+goOqCb145AHm3xDJukCQlSxxPGqEbjL4paste3lM5YqDneCk
DnZWd/X2QWHKBYTHrBk2mGDfS+M8u4KvnFFNWyhR4fcJ0dh9cN1LvRFyjMjM
xEMRlZGKwAqgJfCpvuIEGN37wwxtv2GXRLSkYfWKW+5kWNPG4zcOdyxDXiYr
7CBgsKI3qoByTTAWUd7Kc7PMsLIJ34tWyPFKMfJjPDQyJk8Zymar6Q3I65Gf
QxVyvLywH9v1aJ10gk+gDpKZTg2Ov4BYYQghVid3m37F79/buaj3T88iE8gg
2miuR84KdEXOp38qqewYUqmhEQutd+29op1Nh3b21ljPhZOmgEsisAu9KG8j
7Xn2VyA+p2rDGt4iO5V0aCkkLQvtLAq7UhH7WasmLeHkPXbn42NW/pv1+D0Q
3fadQrRrUZ0BRtwKCUYNbbCMILAzL1xZcOzLgp11SBSTKdVuAjB6Kw147uB7
RI4OiFzebwesaiTWyVKJtQqgPZXqrcDFL1ymssGyZtup0l6N5CNMMN0hIozx
SwSjiAz+uB9SecoWhhlWLI1AdZNGTPhe37F0pJELflRjwDrLhvWuGV33d7R8
SPaWg6RP5y76YoDmb+/pcBz/1ZF2tb/RCUzNPDva/B3GOZaCmnMbe3qhEplq
+ZC7dzKSkVpmhuXCpsYUs2QIb7tTwrCSyBlYdnGtyBEpb2QO6UTD64vVwH1I
pPXMOgtWXyQt0VZaQhlcrK8oF0khnvZhYcNWqx4987JOGK0F0Z2qrl7LsWmn
zcqaqWsF4YJV/C8wkgNvRX+2obznG8pVE9mju5Vs5c80l6tCRNYohjLnp2rJ
we03C9Jc72PVi9Nt74hff2Xbt47p12DNJ3frXbPAWpPzHtjNQ5Nnwa6i3c0y
eLPMKmp2jCkrpgjFPYW0zJBuWq6eYEXm1pnOzNkq21nQpCdRitmbVqXSrTOr
nUXtZahVJt2tnZQDtGvNaZ1m8IW2cqJRmXGvdkY69VhrQn1OgvOZsxJ/uv3a
6ZzT9LWmrWTrEm3GTmDNnv+gfn7Wd+vNbBLXaU5TNlSZ9FE9KdHR0Tp0JOnw
REScEl+d63H9XE6of71ZK9lrbOvRt7UgHDoKr85CrdcEwpsqaqJy2410UUm+
WsB4IuCLHAqDNZlG9WM32cVy/PVlyfUL3Y27tU4diKqddMoXAyLEeCqJ14du
Btva3gBvpF65OAOCpajaibMV5R25YVJO0N2W4C1l2Yk0U6m0dyuWBcJRXAid
7q28RzW+pHsa18ETxPejX9Rsuhe/O/0yF84dAI9O/GxjTJCmsx68OlyjiyiK
rzFkP1ANQQfxLU4wxtMYepayltUDCbaCaZkUZFMrScOr0dMoxGu11UUyWa4b
ICKKxVweSp4rJqjhYScA6aqj+pV1d5YsK4mG9auSpCgFeD1a9+5kif36nfs8
ljjwWEIGfFjUFA0sYIuNhXxh2eXHBteYwGHA2W6SplB2d8eB7nF1qQ+L+gqF
moHtkQ4XuSM1+5itOOWX4ANk3/ZKkkIUEAsKnUSj5IT8quVD4Wq6e4w1yQhf
L9xkztAqESdHA33zcXu73R0iQ3/z8dGwPRyq41cJTNGdlfjz5cXmQtG1MNDP
+dMkBHSMw0Sn6MpJ7UTyK9aBFf9ccDY1doynwWoCm/j7ovgrDVIbbJfc7rVj
VmylMgmpNGtFQfybJqDSMYHvkX443fprkM/SKKJMy4qN7i41UUS5zYNDA7g8
1dfdutXGDCnURbeOtjChm0OcW4sjnHfIcd8aYVDXNiVcX0Dc1NiNR3oP6d2W
U+l7NSRpTGNK2Fst0322Jai452iBVeca9pxL3dbH7DZ4us1iXZp1KyhDSgZS
rfhFmTsNpunSJJs5PahqOPNqHOl0b8qRtbt7cCHulC9AIOeiedJsLQF0t7ND
6QLm7jlnbLmvmFJyYdSgh5qtiMg8EkW5ZOh9xIL0BzE3oNh1doMMb/yRthRe
S2Sr+/0CmhUvUqhVp4JrcpXfDaF6ruo9kapJDGdi1dN8MYn+4JNo3aTc8koZ
LF3/iLXuFco1X2TkrHiCgQ61OB6c8K3QTr8YX8P21O/xgJMSoq2wuoJ/vViW
5X8PrAiBiW0tPMFb7umrQx129K1kNkuO2ZnDkjhsLDA/nnM/pFpYxSRVwVoF
aCkJowx8z7kYlbwpvIKA2hq9u3refmySlDZMS1pqSAs/P6ZuMZkHIQGtX1ui
vUVDitSyErnCwLUFY0lItasy6sw0XBYZ4np5lmnGPxZY4LkfbMBwYBvC551g
g4fiOnfb0ixqTM0aU44zZd1VWGfV9hIJhsUYR4XVPahF+WN88H9EUAvacTSV
XozXEddUwRVWSlqZWTfXNvQhjSzDAbF+PW7qE5X2RIxWvnHJM+T46LKimGvG
rjNw/WeMaPN/sVK7b2+ZKjELfRyTxiuVziWXbGizrOqg8u4vz7D4AcGFj8+f
P8eG+Dr3/1gyEVXrNWP8a0Z3q0mojZjUTDa4qyj5gwtTZ7lfi1Q0hXKVGhks
rlal5wqnREX3GuWbd9iGqLnbhVU4Xp2aY4hD5bDnTI0hmfzcWEWax9uFxtFg
JLcTmNx3uSbFL0FGTrymuizJxIaNAFE3UdcjqYRptyG+qWanFHC5TbBTlzem
rTfbmCOotDNOQ/axIibVbc2s3FvVZ14n/sZyrYO+DY8sHR5r02TuvuebZqgp
8TBomvNDzHfAY1LxBzAY3Nx0Ys2qsf9yB0nsZkkcdVSG7W0uc4+kaJfk/DO+
lYZEg8rqv7ywRQO3JbWGVjE9a73oy8rikorHXNXVitZNHjKt3c1EdqfcrZvS
we56E7tJxzx9TdqxC8ReHRC0k2tOb06veWbnwNOdc/8z9+igGjMRoiV69knh
kSO1c88eIplDd3NSezHXLZzaFWf9bNLDzoiY7s6UzB25VNNKTHNX7L1Rac21
qUQH4iQt8JYRLPBL8JZo8KitjHrKlycuQFajVixtq5WuYeTaXvk7dq98KjXg
u/DMVYd1N33FhbmdxKkaep7ptubeRRfS5GIciooZDuEdVjCqsxwwKRYUpYxZ
xFs2NAt9WATSOwJzWTMVxKtrB0a96fQ9HuTdmbR41Uyivmuae+9Nwe1gVG2/
lrt8GTgXLpibULHJhVNgBy/1iQMKufmnoWrLqBUE04dNG9gns66u2zTuWAY1
j0HqlLzYWQpSGVmZrGdmQqtNht0uXjr4bCxqH7mpbtOhi48AH9rHF45SDD83
AjzvBJeEAGtfgeb0fd5UC4b1wtiAssBrwyasICcANBVSGNlheoDQLXKssvja
Tw2IqjbJVZyKoWhZd5Pq9kK0dYuHCmWRdDW8XHtr6ljNZblI5NXaeNV97s6t
shqWIMmx2SlbQfi+s7XE6a8svexLqFis2+xaTLHJ0jJQWjyCKGvu4MAw6oul
uCwrtBvLVm4bUZDq2rEwDdxmH1ZXtYf+PbrFsG3ks24Qm9WvkKSJdKVlabZS
p5FhllW+xKb80kls6F8GLa18F8hB71Zt3R3HugLPkmB885VlLWldwAuQzmGm
a1AyF+qU60PJklW3zqu5rcmAKLFDVqRbAUuxILNzwnGXfikBqDy7rrFIqb40
HEaoGLUt53cl1FdpVm10xafW/iUZ2ZZ+L9LO0kal5kIz9PYCNvL8O+OkWF6R
pzncrLnzL3WEi3rNDicidqbIOtLNipfO10tptEspoNwRSsSq4ySeNUd3Iihj
zjLOHVN1yUmUKf6gvKwsf29XIlRLQDoVI4euV455dYDXjFuHKvvaS2XTPZet
QB2BQGautA9bZEWtlIzqW32V2xyMDdjO8sVGMLWkUV202dGuswzf/HJ5h2mo
a4T8dYllKHthz7VHbgje8Lv8HMVyPkw8uNlq+uYmDLnAsF0J/HrjVsC36pR1
izZSL8ceELvYuMvYSBIRR1uthw7/EA/gjz1s+H7hps4IXL7NiiucXV6XO8jC
oxzvu3hD9byvPqY7Pcn11So/VV/zIVeRGTbUCZj3zH13ncmZIZsbzTuysmzk
1/FWJUm54tC+XXX4VR23GrKoIYe68re1aeEOGjB7790X9dW29gtkxUZFVkh0
1FpGjazeXVlWf5Y3rdPoV6XYzaYVA14DHV5I2MpKvjOq4OY5M33p1j81BKon
ersqRSnVQduBfHCvkQ5WM+qsWxK+DSRKaay+Cbj1sLMYbtusUNUeO7k4l/g/
FnvehPy2qAD3Td/qcUp9KpGkz7CA7JujnJ49KKL/HKvIqj2ymK1lg7aOfYRD
oq1LNTYrROekYoeRadfsfCFXnjTtqpnPYEvFl1KKtTL9f67Nt7DqR5Cqr6C3
i5L+dBmyW4cUESXVKhyr9sYiszBBb31uJ9VQQZaimg3qX8LnfVYDNqtHJTqS
14ClPMYjPN26w6r1UiKkmuLnTEVv8MuyJOpxo0BVFuhnW6+PVjC+veke37/9
ffgFK9j+8+1vuxqyaoIbl5oiJgOgPW7TZAlnfc0NtYREr5hue8MA38y6hVHf
Wk4GMYc4Op7M15VZllJbW9AvN7++UICbqqkVxK1ThcVLqtZhVSzmry1bduss
k3qUVa1tpyTLX9L6W6Xrw/8Ufyek9Gu+5YGrpld3fjjtBZNKTWEVr5+Pahfv
5zrw8Qn8qnBZ5TEMSm3JlXvUtyooqZ+uuSJIuiSLIaorynKP/Va1MY5Wh6FS
nyWEWleh5ab1rwrMD2sAY0q2BIzaoi33fHFVOH5cHQ5VyCWWdLWUS0HwaC0I
vlkDgkpRl7Lq68q6FDiPHbuCDjfIh5Fz4lmaR/1slPLNqJ5H4cguS04q0cVi
8r5dCS3UvtRbcLXAF3sL63l4zeMmdjSMRYVn2VQ5BrbFhJ1MLLtRurByh3Da
/jqDf/fzowV7Fmbu3+vZt0df7AOsx6Mni0IW2FbAytcqV8Cc530YGL+CKaIt
aosMF3gTZju+zJ2wFqXM83qfwkxoORU2SoC9DNi2zWN/u9i81U99uXX7wKNE
JXucfjUrG0x0UeifYCot7vvixw8rjQDrKi2+ioSS8+WVO+E42TdesANXQpU/
FV7qE8fG+jDw7njG7oJaItvwqWtgWAmB1dqdin7E7PwM5VUd9HNJ6jWWV/Hp
sMkinHKiJCVF6BucnFveOJ1H3Q/k3/MGv8k1LnJencNmTDN94Y3qEam0JFkC
mNguEzQ1aWJxIf7S1e2JeJmSXLmgSdEaoh1prC8SPebepoWaFxDX7rrloktc
egWHrMG3ZNbSOJygLtxQSUdbI7R4Xwyx41TnadBCFZI2Wey8M4qLTCtSnRQo
W0yo1uV+HVvDamzLLmtV5dQP24lVlRBOJds6dNnZGV9tOsEIPzaFmJvKXrHG
meZRzUCKQ+k+iorBJY5JLQbuXOj+8oUeuGMryFcb+2DJ2I/rgbaJS0Sfw4vO
rXZx4RGeSspw0V9YzRLcQuOKVqH64SqlykhMSTVYMj68ycqu3uDTaZrkdDPi
iPJp5BZBqqSvmWB3EUa00F8TIV4HgY5bBWTNQDI9zwYzzp50f1f3q1FCs6uw
1Lj+mc2lquJx4hGfoaNmKV29NJARv9CRuttGWStOg8JSRWoqoVfl2awkHPf+
V8hj/2quOmlqg3ZTn+vs+Cdp9LF8f18A68waM6qzDWzj/VbHvM7pp3m9apR5
KkdN4kXkqi/t1by0YsW8OUqor5v30nrOkhpd5AFEhTphH69EKc0xrLOF6o71
YcwmVRj0k4z4l9d617msKme3A3zrOzI0yp/mynixzP9ljsyCuvb/7/yVSjG8
E3ddn0ac4f40WqE9qFDIWmJdh9pzq2IUK9TNO5L5uYBJa7Iq6PTpYO+93Dyz
bOPVI/4C+Wpl1Z6GbypyCUWHMSR3w8AL0JN0cQJYR+sFsNjctBexpNUDXaNE
nV2IeY17/xd07JE/Qm7NWePjEK6I6hajS/oTqDvS5BoALvC0YWwFxTyFVwuu
WMYWAUQszl0zaVaq8a0mBWEP5Sxe8jqNGQbsMYu1Hti9YJOxwVfOaTAkU1yZ
dkO+P/6x5kB3WUDfTyTtv67Uw6xT3aLBpSV59LvU7GRDt2+BkwRNqdzJnAKV
0hphg2+6r2+HsGmKlqT/Ad6LZBLu1TgWs0nuuu52UPJtq6rqAZY5jEczSamm
pgdfZ8l860japuutdMOGxavdv3u11eHo+p/PWfBV5dYWk9GeR0n4sUp7dBGm
D3gBkHeJb3Y7u1yjJZddeeVmtIrMvp8TRT/e6sM8zghWNc80IjydUAVSFPGN
PTaSa1SF7kHhnop9hpbgN/88/fDD/emHO+ek+jzY6Wa3SVfeLZrDjpvJQcXq
oSw9yfYak/C1i6gSXmcSgKcubTTW3cl93AXDOoxcf+NxjD9v13+8j1237Exq
m7FSotvn5h4wAdjTud1k3dX43UvojbqsTK9fh3uGu/4uLm+k8bn7u+3tb3mT
OcLM22RVZ1Tf52JJffeqM2gvw23+oV0MbuSwbs711wsKfAUPdtft0fZN08u5
pKtr34+jj0tX42K5ekhsDG+1p+4rC4MWyCoagro2eLYCVHjZ3W7vHjJeDrrt
g4NavGy36RHd/iMI28M6BBnPjgCpogEh04aiAXZJo5JqpxEeWvqXvBeK04mj
btTD26AZc6dphlMBUANnUTnFI7mbTaETP+p62XSC5xZG0MB2jeJqZr0PUE0e
qhWUUfxd1xhQceaS9jDerWElE1X1WhTVwsXG795XicoE56evT8khs25bvH0Q
h2kIcvgCr4WmS79ZBJBUw/HYV+Fmqc0X8ykWCn8sgyug6WIIwuEiz8qsn4GW
wQrRTS7FDF5jFfNb8O0A3jmwbuN7yvNvXpo00ysYq4mXa88mGAjnCz05Zk0n
AXb9fbDBvQP+z+XZy+dkS8NOhenc3Frei2CK5jOn0QdmedMGNjGVARzS7+EZ
c4hvWhgUlhvKV35bfFyOVUDehIW+bXKNtJjhobRZIyDsRqOhtEb36lSldXn1
/lgs5039KyJ7EVtdQDB8Vx1M4twzKS1VhpwiHUv3OpxggFcf4FXsjOZWdQOc
ZyldSt9C7T3KJa3YuknfH5/LBmN5Mvwb8+fZB7+9Vc+0ufkNNb/7j00cd/zz
n8r0/2n8p736P9Vn4X28XTqalu2nL+6aHuanGgH7G3j/KXJl+xKcx1nxWe8/
e93mMZ5K1f/i962cafM+FtG33+QxUGv7DIw58LLz9kWWxP25/z6l7/jzL3m/
/TbCjkPtN9gKd5X330yxFUnt7Ou/786+6H1583SEV+I+TWYFmicL8Ff3/kUe
Z9Tq6M5/6vEPwu7j/LP3//YoHpw0Pc5oBmVcJtFJ80xxFQuJ5icS2peqOVNF
cOurdblXZYF3nWZ4kUpRc2dtVQaprJ14EpfogJGoYkWGiXwlRgZgK5IwH0Wq
g1VfXyudyvXOwTWoZpALcoMtiggYI5vl3HoDzDDq5wHa+hXCRU0E/BAMgUCy
B9cgtrBurSJTY1eKCCSutHDBnDDMqqr0rjFdq+ju1yyAsWNsDhYUs76+lBpv
dSabSzfJRMhBW5YxdTGRK0ZVXwI6e8eAEMlSp6cX6XW07vD5SRSiDmmgIVBB
OVhMKceg+nHen02ky4v0plnccoPvSq/v65lHSQzKZ87aHnsTwii0UGcOaWfq
OWOkZak/GDaomlNypR68et+6tjkKWGQpDdS8RgcUnuImK2ITg9UVFngsTN1F
9N3tLd32RPq7bZj48ut3L7kbRZqlRhFToaCKPqGZpRtCGHPfv5FbX8cuvIMm
JZDCCDeZyQHbeGDPCzKRYSHgpk0p9g3AzQpuiaIiwkO+upymIJOz7AR8y/XF
27On55efPpFGv7199/r86ZtnZ+3Ls6fv3p5f/UrKDzQQnZwSVz/PyQbFxkOn
xQeY5e+gxxVjD8N/f6JmdL+M52iuBH+9fPP6h0bjLMyTGBaBgdaswFwoxH2V
s6nTB8bcBsFsCpyArwNUP4Cd/3hn/xCgCV6Ac3GNERrd/JUXVFBjDeQaua7d
6X9pE77uXVHgfeB5IbEeiV0XTp9ZHYu07/9WbVrci8lbDC2GhtwAZlwUnDBN
Vw2wVOJwhtyz3UP+FN41mZmqe0JwmiDxjmDLB9dxn9cTXmexOtHABnk8BUY9
roGdaNki1xh7j/YOd9n4LK0YLPKgoNpp8EsLKYQSKdEbO8wPQ/QUFHfJz1gj
jrVU1DnJ7uY3zaiDCt4Z4PdKEWjN1eGSSluQtNXL1ZtA/SW56QCiQBpBEQrs
2+eF2rlmfZbqQwsRU/C/QTyEXdHdIQGR6Eo1TlO56pw3Ep9EDDwsbCma4h0P
ag6cPu/FQH45YmZajgvVtck4VWT6RpMsn1P1WlwSQek+TrNUU6jBRMSGzSAw
F7CLmsNGTUD3OFuSzSn0TduJl4ro4xnsGkMqKSZ/nET2MCzGJO7GinO0EUz7
7Os02sk0YylDo0nHJuoHhc6LmkMTOiYKEyQJkBB13wGrnicnq5m0eWx1rYxT
tu55J6/jLKGgnX3KAyQkm9DLM+zCNOD+Wpyy5cCsohDO9mITykKpTsO7Vsto
1dgJFY+HhGOG3sJ1cEMGBCkrQzy42xPJbgQeAYlPwtyneNafYzASW1JYmWTZ
B0YXrbIVTKNsSl4TtQsLSox+MXYQGSFvFZ9cbNktu1LHn8KOZ0SFIYjB30FO
jDK0Q2plbawk3ZKGRoiWeDiv4JulDjYoizB7NRGOxJkmYam8OhKznKSlHDNe
gaQSqlUgC+odSnS2KCmDG1B+2IEJUItt+aIoIaFEMxBO8HgofVgGTUQpX/VC
+WmWxJcYgtsECZ3pAibmroQg4L0mSeTDVw6jYBORDKKPRFzk8OuGeXpBGPeh
jqv6G5UKTMvXP9Nf+NNwlvKpFVkKc2YMkdH6N89eQUGubFojKVVPMNYpLVW7
DBJ1UBgvWOITyC+AY5JnahFkfoti82lCmNxr71qPv4LP+KQDF3XEyrjZ3ziy
GwJi7Ac2GBiOzBHUKv0S9fwV0FM8oD3AFmkoQbF1FUphlJskpVV4ISZ7jd0F
zqSeTGYpUXEZ/PYdtjYrjra2RjDlrNeBX7fwq5vRlk6yHrBL08bxi9++RyPb
1j6y7akOwNgtGgP/3sQ84sKlNkVT8muJgaCK0DKxoKAJ7rGYsGKAq3g0DSC5
BcxtfISL26PNagELhDlLDSbLATbM5+PtUgsUYxcgo9o2KD2pRDF12y0dY8Df
1woufKLIAll3JFSGyoY9G9UKmZsDEuLE4FUnAeQDgkgaATpJlibgosxC7JLN
iok6vImXSNNjZZoE+STgRb+hy0VcIsEpR0n2KVkVyOomx9hUHjQpu6spfBNI
x/TQKo9BSatYkXBI/T4D1e6zUDDJBaCqlaj4L27rZlNCEBtXF12g4Cac660T
p4lZAv1ZMQRksYYe7CFAtOBXYNCjNQHqfk7NUL2Wg7okAWl1EImTgwOj8UwK
ly5km874yJtNV1y1nBhpdXPuUQc1dbZ62DkOMkXOtdDRzIctP2eMeFkb7Hw8
AR9Qr0yLLlwd0gr3ytfdSaOPfTqNrza7IwhaYpLo5ynOrt3VLK+5Qi84ffL6
Ofg0YS8dflKZCeKhzwoJ957ORiJ3n4CDNCvar8NZjrieBBv4/iZuIQPChvj+
zu4ebA5q3gSDQEgjyLcwMDLuHMD+iGiq6GvL83FseNUXFXYkpqNPACvOZSTT
tTS2WgOCo8gtXUE02KkUHW+VMWeKpKTUgevcXC/g63CUR+wmKcZWB5QU2DdS
HmkI0cFlrdpqtB8hyptiU/IBn3BQV0pEfqMYUn8TCUadULC2LY01vt2ghhN4
jy7+1/5ps2H/hS/CQFRSuxVQ7xsatdEwn3n45kYz+PbyIvinfh4m6eI36u9N
+v1f2BWo4UfPTNldo2HVE9LIMA6WkeLLRrBsmsdkffQ3ls0BCJxJhH9z5sG/
GuZXfho+NdRfCkMbuqRtiyL+mxUwv7UfoYQzfPR9E//dpn93mvpl9aQans4A
H50Gx0HY/qNhg4e/6nLLBu6c1XbjhHpwLNg5+6fNhv0XjskfadUbdpnmFvyJ
KJLfGYjNzYb1vEaS88xCalDfOiuxd9V8yUNI0sIW/qGqEbaspqz0mdSLswn0
Nee4yWfJE+KBkJP5E0dteDAGT2ZUu/FP2LB/AYF292kfGxYclUd2eKtxc7vf
7urnBVT9vCSbwxbNUgosAa9u0ZniVtAr2uqrTXmwoVbokCCfOQkN4ViU+otf
HBFpbSFpGSToN/FnybuCjw0LNfqJH5q479s0TFeGIZRZADR/bFr70/BRiU/A
ehas9Dccego0qHK7qhwE/8jqGwKtmvlbs3bNWX/RSw6+BYJtNMx0wlI72+2d
LjwEn3bbO3v86aC9/4Q+7T9rPzprWLinJf6GeJAlMNSbIHUssGWVSb89jj4O
4pH51DDfnWgw1eH+MR7lt/D4nhv8gjZ8Oua7SigRARRZ8PhwrwvqkWPIhdKQ
eXQdF9p/qna6DX7mgz8dlHP9K06sktwDc5Irkxw1Gt8GpxQfwd8ptcqY8GIb
YJUl93yAhy/Bs0FsUU1zHo4oQMrRBVLvYCSZ4ATF7zFMbo0pHiRd+0OQznng
V+A0s05TPXbTodKTUrkQf6TXyH6gdxjycPFRslg/hJeaw2gajg69abi3Yhux
U4kWDSp1HZysuJku7tyAei0WbXbB98ko6uMVIAne1UE2Q+P2iGN+0eCkSZly
ePrzCgPyePD8gWzlV2EJc94Ef8NkhZT2fkyWb4kHH+TWDzDAzMWOIF+Hs0RH
viULdJarHJ8BOqrZdBKpG9N8L53sGJob4MkQgHPYoKcJeAQwQSt4m80ZvZSf
dQrCH6ynFKDDMzk8UP5b+MdsnAVvPsxawRldnXGRgQ3511kC2Ae8F/3xB7Ci
X+GhCzgz42xSYFTkFYZzfomwnx4u5K/RcJiDAvoVXIUPsmw2zugAIQYnjrvU
/1/zZJOQNvoAAA==
--> -->
<!-- [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.
For example, please consider whether the following should be updated:
native, whitespace
In addition, please consider whether "traditional" should be updated for clarity
.
While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
uthor-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->
</back>
</rfc> </rfc>
 End of changes. 71 change blocks. 
778 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.48.