<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?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 tocindent="yes"?> <?rfc strict="yes"?> <?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" number="9651" submissionType="IETF" category="std" consensus="true" obsoletes="8941" updates="" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.21.0 -->version="3" xml:lang="en"> <front> <title>Structured Field Values for HTTP</title> <seriesInfoname="Internet-Draft" value="draft-ietf-httpbis-sfbis-06"/>name="RFC" value="9651"/> <author initials="M." surname="Nottingham" fullname="Mark Nottingham"> <organization>Cloudflare</organization> <address> <postal> <city>Prahran</city> <region>VIC</region> <country>Australia</country> </postal> <email>mnot@mnot.net</email> <uri>https://www.mnot.net/</uri> </address> </author> <!-- [rfced] Poul-Henning, do you prefer "P.-H. Kamp" in the document header, which is how your name appears in this document, or "P-H. Kamp", which is how it appears on RFC 8941? --> <author initials="P.-H." surname="Kamp" fullname="Poul-Henning Kamp"> <organization>The Varnish Cache Project</organization> <address> <email>phk@varnish-cache.org</email> </address> </author><date/> <area>Applications and Real-Time</area> <workgroup>HTTP</workgroup> <keyword>Internet-Draft</keyword><date month="August" year="2024"/> <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><?line 86?><t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t> <t>This document obsoletes RFC 8941.</t> </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.org"/>), 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.org/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/httpwg/http-extensions/labels/header-structure"/>.</t> </note></front> <middle> <?line 93?> <section anchor="introduction"> <name>Introduction</name> <t>Specifying the syntax of new HTTP header (and trailer) fields is an onerous task; even with the guidance in <xref section="16.3.2" sectionFormat="of"target="HTTP"/>,target="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 looks like common syntax.</t> <t>This document introduces a set of common data structures for use in definitions of new HTTP field values to address these problems. In particular, it defines a generic, abstract model for them, along with a concrete serialization for expressing that model in HTTP <xreftarget="HTTP"/>target="RFC9110"/> header and trailer fields.</t> <t>An HTTP field that is defined as a "Structured Header" or "Structured Trailer" (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, thereby simplifying both its definition by specification writers and handling by implementations.</t> <t>Additionally, future versions of HTTP can define alternative serializations of the abstract model of these structures, allowing fields that use that model 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 existing HTTP fields; the mechanisms described herein are only intended to be used with fields that explicitly opt into them.</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>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"> <name>Intentionally Strict Processing</name> <t>This specification intentionally defines strict parsing and serialization 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 interoperability. Therefore, an implementation that tried to be helpful by being more tolerant of input would make interoperability worse, since that would create pressure on other implementations to implement similar (but likely subtly different) workarounds.</t> <t>In other words, strict processing is an intentional feature of this specification; it allows non-conformant input to be discovered and corrected by the producer early and avoids both interoperability and security issues that might otherwise result.</t> <t>Note that as a result of this strictness, if a field is appended to by 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 anchor="notational-conventions"> <name>Notational Conventions</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>This document uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from <xref target="RFC5234"/> to specify characters and/or their corresponding ASCII bytes, depending on context. It uses the tchar and OWS rules from <xreftarget="HTTP"/>target="RFC9110"/> for the same purpose.</t> <t>This document uses algorithms to specify parsing and serialization behaviors. When parsing from HTTP fields, implementationsMUST<bcp14>MUST</bcp14> have behavior that is indistinguishable from following the algorithms.</t> <t>For serialization to HTTP fields, the algorithms define the recommended way to produce them. ImplementationsMAY<bcp14>MAY</bcp14> vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm described in <xref target="text-parse"/>.</t> </section> </section> <section anchor="specify"> <name>Defining New Structured Fields</name> <t>To specify an HTTP field as a Structured Field, its authors need to:</t> <ul spacing="normal"> <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> </li> <li> <t>Identify whether the field is a Structured Header (i.e., it can only be used in the header section -- the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both).</t> </li> <li> <t>Specify the type of the field value; either List (<xref target="list"/>), Dictionary (<xref target="dictionary"/>), or Item (<xref target="item"/>).</t> </li> <li> <t>Define the semantics of the field value.</t> </li> <li> <t>Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.</t> </li> </ul> <t>Typically, this means that a field definition will specify the top-level type -- List, Dictionary, or Item -- and then define its allowable types and constraints upon them. For example, a header defined as a List might have all Integer members, or a mix of types; a header defined as an Item might allow only Strings, and additionally only strings beginning with the letter "Q", or strings in 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 specify their allowableunicodeUnicode code points; for example, specifying the use of a profile from <xreftarget="PRECIS"/>.</t>target="RFC8264"/>.</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"Structured Header name","structured trailer"Structured Trailer name", or"structured field"Structured Field name" as appropriate. Likewise, they can refer its field value as a"structured header"Structured Header value","structured trailer"Structured Trailer value", or"structured field"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 most cases, but authors should be aware that HTTP implementations do impose various limits on the size of individual fields, the total number of fields, and/or the size of the entire header or trailer section.</t> <section anchor="example"> <name>Example</name> <t>A fictitious Foo-Example header field might be specified as:</t> <blockquote> <t>42. Foo-Example Header Field</t> <t>The Foo-Example HTTP header field conveys information about how much Foo the message has.</t> <t>Foo-Example is an Item Structured Header Field[RFCnnnn].[RFC9651]. Its valueMUST<bcp14>MUST</bcp14> be an Integer (Section 3.3.1 of[RFCnnnn]).</t>[RFC9651]).</t> <t>Its value indicates the amount of Foo in the message, and itMUST<bcp14>MUST</bcp14> be between 0 and 10, inclusive; other valuesMUST<bcp14>MUST</bcp14> cause the entire header field to be ignored.</t> <t>The following parameter is defined:</t> <ul> <li>A parameter whose key is "foourl", and whose value is a String (Section 3.3.3 of[RFCnnnn]),[RFC9651]), conveying the Foo URL for the message. See below for processing requirements.</li> </ul> <t>"foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If its value is not a valid URI-reference, the entire header fieldMUST<bcp14>MUST</bcp14> be ignored. If its value is a relative reference (Section 4.2 of [RFC3986]), itMUST<bcp14>MUST</bcp14> be resolved (Section 5 of [RFC3986]) before being used.</t> <t>For example:</t> <artwork><![CDATA[ Foo-Example: 2; foourl="https://foo.example.com/" ]]></artwork> </blockquote> </section> <section anchor="error-handling"> <name>Error Handling</name> <t>When parsing fails, the entire field is ignored (see <xref target="text-parse"/>). Field definitions cannot overridethis,this because doing so would preclude handling by generic software; they can only add additional constraints (for 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 in a List).</t> <t>When field-specific constraints are violated, the entire field is also 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 explicitly specifies otherwise.</t> </section> <section anchor="preserving-extensibility"> <name>Preserving Extensibility</name> <t>Structured Fields are designed to beextensible,extensible because experience has shownthatthat, 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 mechanism; this means that their values can later be extended to accommodate more information, if need be. To preserve forward compatibility, field specifications are discouraged from defining the presence of an unrecognized parameter as an error condition.</t> <t>Field specifications are required to be either an Item, List, or Dictionary to preserve extensibility. Fields that erroneously defined as another type (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 definition can specify that "grease" parameters be added by senders. A specification could stipulate that all parameters that fit a defined pattern are reserved for this use and then encourage them to be sent on some portion of requests. This helps to discourage recipients from writing a parser that does not account for Parameters.</t> <t>Specifications that use Dictionaries can also allow for forward compatibility by requiring that the presence of -- as well as value and type associated with -- unknown keys be ignored. Subsequent specifications can then add additional keys, specifying constraints on them as appropriate.</t> <t>An extension to a Structured Field can then require that an entire field value be ignored by a recipient that understands the extension if constraints on the value it defines are not met.</t> </section> <section anchor="using-new-structured-types-in-extensions"> <name>Using New Structured Types in Extensions</name> <t>Because a field definition needs to reference a specific RFC for Structured Fields, the types available for use in its value are limited to those defined 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 field whose definition references RFC 8941cannot,cannot because it will be treated as invalid (and therefore discarded) by implementations of that specification.</t> <t>This limitation also applies to future extensions to a field; for example, a field that is defined with a reference to RFC 8941 cannot use the Datetype,type because some recipients might still be usingana parser based on RFC 8941parserto process it.</t> <t>However, this document is designed to bebackwards-compatiblebackward compatible with RFC 8941; a parser that implements the requirements here can also parse valid Structured Fields whose definitions reference RFC 8941.</t> <t>Upgrading a Structured Fields implementation to support a newer revision of the specification (such as this document) brings the possibility that some field values that were invalid according to the earlier RFC might become valid when processed.</t> <t>For example, a field instance might contain a syntactically valid Date (<xref target="date"/>), even though that field's definition does not accommodate Dates. AnRFC8941implementation based on RFC 8941 would fail parsing such a fieldinstance,instance becausethey areit is not defined in that specification. If that implementation were upgraded to this specification, parsing would now succeed. In some cases, the resulting Date value will be rejected by field-specific logic, but values in fields that are otherwise ignored (such as extension parameters) might not bedetecteddetected, and the field might subsequently be accepted and processed.</t> </section> </section> <section anchor="types"> <name>Structured Data Types</name> <t>This section provides an overview of the abstract types that Structured Fieldsuse,use and gives a brief description and examples of how each of those types 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>In summary:</t> <ul spacing="normal"> <li> <t>There are three top-level types that an HTTP field can be defined as: Lists, Dictionaries, and Items.</t> </li> <li> <t>Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items).</t> </li> <li> <t>Both Items and Inner Lists can be Parameterized with key/value pairs.</t> </li> </ul> <section anchor="list"> <name>Lists</name> <t>Lists are arrays of zero or more members, each of which can be an Item (<xref target="item"/>) or an Inner List (<xref target="inner-list"/>), both of which can be Parameterized (<xref target="param"/>).</t> <t>An empty List is denoted by not serializing the field at all. This implies 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> <sourcecode type="http-message"><![CDATA[ Example-List: sugar, tea, rum ]]></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="of"target="HTTP"/>;target="RFC9110"/>; for example, the following are equivalent:</t> <sourcecode type="http-message"><![CDATA[ Example-List: sugar, tea, rum ]]></sourcecode> <t>and</t> <sourcecode type="http-message"><![CDATA[ Example-List: sugar, tea Example-List: rum ]]></sourcecode> <t>However, individual members of a List cannot be safely split between lines; see <xref target="text-parse"/> for details.</t> <t>ParsersMUST<bcp14>MUST</bcp14> support Lists containing at least 1024 members. Field specifications can constrain the types and cardinality of individual List values as they require.</t> <section anchor="inner-list"> <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>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 like:</t> <sourcecode type="http-message"><![CDATA[ Example-List: ("foo" "bar"), ("baz"), ("bat" "one"), () ]]></sourcecode> <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> <sourcecode type="http-message"><![CDATA[ Example-List: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1 ]]></sourcecode> <t>ParsersMUST<bcp14>MUST</bcp14> support Inner Lists containing at least 256 members. Field specifications can constrain the types and cardinality of individual Inner List members as they require.</t> </section> <section anchor="param"> <name>Parameters</name> <t>Parameters are an ordered map of key-value pairs that are associated 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, and the values are bare items (i.e., they themselves cannot be parameterized; see <xref target="item"/>).</t> <t>ImplementationsMUST<bcp14>MUST</bcp14> provide access to Parameters both by index and by key. SpecificationsMAY<bcp14>MAY</bcp14> use either means of accessing them.</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 from its Item or Inner List and other Parameters by a semicolon. For example:</t> <sourcecode type="http-message"><![CDATA[ Example-List: abc;a=1;b=2; cde_456, (ghi;jk=4 l);q="9";r=w ]]></sourcecode> <t>Parameters whose value is Boolean (see <xref target="boolean"/>) trueMUST<bcp14>MUST</bcp14> omit that value when serialized. For example, the "a" parameter here is true, while the "b" parameter is false:</t> <sourcecode type="http-message"><![CDATA[ Example-Integer: 1; a; b=?0 ]]></sourcecode> <t>Note that this requirement is only on serialization; parsers are still required to correctly handle the true value when it appears in a parameter.</t> <t>ParsersMUST<bcp14>MUST</bcp14> support at least 256 parameters on an Item or Inner List, and support parameter keys with at least 64 characters. Field specifications can constrain the order of individual parameters, as well as their values' types as required.</t> </section> </section> <section anchor="dictionary"> <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 can be zero or more members, and their keys are unique in the scope of the Dictionary they occur within.</t> <t>ImplementationsMUST<bcp14>MUST</bcp14> provide access to Dictionaries both by index and by key. SpecificationsMAY<bcp14>MAY</bcp14> use either means of accessing the members.</t> <t>As with Lists, an empty Dictionary is represented by omitting the entire field. This implies that fields defined as Dictionaries have a default empty value.</t> <t>Typically, a field specification will define the semantics of Dictionaries by specifying the allowed type(s) for individual members by their keys, as well as whether their presence is required or optional. RecipientsMUST<bcp14>MUST</bcp14> ignore members whose keys are undefined or unknown, unless the field's specification specifically disallows them.</t> <t>When serialized as a textual HTTP field,Membersmembers are ordered as serialized and separated by a comma with optional whitespace. Member keys cannot contain uppercase characters. Keys and values are separated by "=" (without whitespace). For example:</t> <sourcecode type="http-message"><![CDATA[ Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=: ]]></sourcecode> <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"/>) trueMUST<bcp14>MUST</bcp14> omit that value when serialized. For example, here both "b" and "c" are true:</t> <sourcecode type="http-message"><![CDATA[ Example-Dict: a=?0, b, c; foo=bar ]]></sourcecode> <t>Note that this requirement is only on serialization; parsers are still required to correctly handle the true Boolean value when it appears in Dictionary values.</t> <t>A Dictionary with a member whose value is an Inner List of Tokens:</t> <sourcecode type="http-message"><![CDATA[ Example-Dict: rating=1.5, feelings=(joy sadness) ]]></sourcecode> <t>A Dictionary with a mix of Items and Inner Lists, some with parameters:</t> <sourcecode type="http-message"><![CDATA[ Example-Dict: a=(1 2), b=3, c=4;aa=bb, d=(5 6);valid ]]></sourcecode> <t>Note that Dictionaries can have their members split across multiple lines of the same header or trailer section; for example, the following are equivalent:</t> <sourcecode type="http-message"><![CDATA[ Example-Dict: foo=1, bar=2 ]]></sourcecode> <t>and</t> <sourcecode type="http-message"><![CDATA[ Example-Dict: foo=1 Example-Dict: bar=2 ]]></sourcecode> <t>However, individual members of a Dictionary cannot be safely split between lines; see <xref target="text-parse"/> for details.</t> <t>ParsersMUST<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 values' types as required.</t> </section> <section anchor="item"> <name>Items</name> <t>An Item can be an Integer (<xref target="integer"/>), a Decimal (<xref 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 parameters (<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> <sourcecode type="http-message"><![CDATA[ Example-Integer: 5 ]]></sourcecode> <t>or with parameters:</t> <sourcecode type="http-message"><![CDATA[ Example-Integer: 5; foo=bar ]]></sourcecode> <section anchor="integer"> <name>Integers</name> <t>Integers have a range of -999,999,999,999,999 to 999,999,999,999,999 inclusive (i.e., up to fifteen digits, signed), for IEEE 754 compatibility <xref target="IEEE754"/>.</t> <t>For example:</t> <sourcecode type="http-message"><![CDATA[ Example-Integer: 42 ]]></sourcecode> <t>Integers larger than 15 digits can be supported in a variety of ways; for example, by using a String (<xref target="string"/>), a Byte Sequence (<xref target="binary"/>), or a parameter on an Integer that acts as a scaling factor.</t> <t>While it is possible to serialize Integers with leading zeros (e.g., "0002", "-01") and signed zero ("-0"), these distinctions may not be preserved by implementations.</t> <t>Note that commas in Integers are used in this section's prose only for readability; they are not valid in the wire format.</t> </section> <section anchor="decimal"> <name>Decimals</name> <t>Decimals are numbers with an integer and a fractional component. The integer component has at most 12 digits; the fractional component has at most three digits.</t> <t>For example, a header whose value is defined as a Decimal could look like:</t> <sourcecode type="http-message"><![CDATA[ Example-Decimal: 4.5 ]]></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>Note that the serialization algorithm (<xref target="ser-decimal"/>) rounds input with more than three digits of precision in the fractional component. If an alternative rounding strategy is desired, this should be specified by the field definition to occur before serialization.</t> </section> <section anchor="string"> <name>Strings</name> <t>Strings are zero or more printable ASCII <xref target="RFC0020"/> characters (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 inStrings,Strings because they cause a number of interoperability issues, and -- with few exceptions -- field 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 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[ Example-String: "hello world" ]]></sourcecode> <t>Note that Strings only use DQUOTE as a delimiter; single quotes do not delimit Strings. Furthermore, only DQUOTE and "\" can be escaped; other characters after "\"MUST<bcp14>MUST</bcp14> cause parsing to fail.</t> <t>ParsersMUST<bcp14>MUST</bcp14> support Strings (after any decoding) with at least 1024 characters.</t> </section> <section anchor="token"> <name>Tokens</name> <t>Tokens are short textual words that begin with an alphabetic character or "*", followed by zero to many token characters, which are the same as those allowed by the "token" ABNF rule defined in <xreftarget="HTTP"/>,target="RFC9110"/> plus the ":" and "/" characters.</t> <t>For example:</t> <sourcecode type="http-message"><![CDATA[ Example-Token: foo123/456 ]]></sourcecode> <t>ParsersMUST<bcp14>MUST</bcp14> support Tokens with at least 512 characters.</t> <t>Note that Tokens are defined largely for compatibility with the data model of existing HTTPfields,fields and may require additional steps to use in some implementations. As a result, new fields are encouraged to use Strings.</t> </section> <section anchor="binary"> <name>Byte Sequences</name> <t>Byte Sequences can be conveyed in Structured Fields.</t> <t>When serialized in a textual HTTP field, a Byte Sequence is delimited with colons and encoded using base64 (<xref section="4" sectionFormat="comma" target="RFC4648"/>). For example:</t> <sourcecode type="http-message"><![CDATA[ Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==: ]]></sourcecode> <t>ParsersMUST<bcp14>MUST</bcp14> support Byte Sequences with at least 16384 octets after decoding.</t> </section> <section anchor="boolean"> <name>Booleans</name> <t>Boolean values can be conveyed in Structured Fields.</t> <t>When serialized in a textual HTTP field, a Boolean is indicated with a leading "?" character followed by a "1" for a true value or "0" for false. For example:</t> <sourcecode type="http-message"><![CDATA[ Example-Boolean: ?1 ]]></sourcecode> <t>Note that in Dictionary (<xref target="dictionary"/>) and Parameter (<xref target="param"/>) values, Boolean true is indicated by omitting the value.</t> </section> <section anchor="date"> <name>Dates</name> <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 that of Integers, distinguished from them with a leading "@".</t> <t>For example:</t> <sourcecode type="http-message-new"><![CDATA[ Example-Date: @1659578233 ]]></sourcecode> <t>ParsersMUST<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 anchor="displaystring"> <name>Display Strings</name> <t>Display Strings are similar to Strings, in that they consist of zero or more characters, but they allow Unicode scalar values (i.e., all Unicode code points except for surrogates), unlike Strings.</t> <t>Display Strings are intended for use in cases where a value is displayed to endusers,users and therefore may need to carry non-ASCII content. It isNOT RECOMMENDED<bcp14>NOT RECOMMENDED</bcp14> that they be used in situations where a String (<xref target="string"/>) or Token (<xref target="token"/>) would beadequate,adequate because Unicode has processing considerations (e.g., normalization) and security considerations (e.g., homograph attacks) that make it more difficult to handle correctly.</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>For example:</t> <sourcecode type="http-message-new"><![CDATA[ Example-DisplayString: %"This is intended for display to %c3%bcsers." ]]></sourcecode> <t>See <xref target="security"/> for additional security considerations when handling Display Strings.</t> </section> </section> </section> <section anchor="text"> <name>Working with Structured Fields in HTTP</name> <t>This section defines how to serialize and parse the abstract types defined by <xref target="types"/> into textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 <xref target="RFC9113"/> before compression with HPACK <xreftarget="HPACK"/>).</t>target="RFC7541"/>).</t> <section anchor="text-serialize"> <name>Serializing Structured Fields</name> <t>Given a structure defined in this specification, return an ASCII string suitable for use in an HTTP field value.</t> <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> </li> <li> <t>If the structure is a List, let output_string be the result of running Serializing a List (<xref target="ser-list"/>) with the structure.</t> </li> <li> <t>Else, if the structure is a Dictionary, let output_string be the result of running Serializing a Dictionary (<xref target="ser-dictionary"/>) with the structure.</t> </li> <li> <t>Else, if the structure is an Item, let output_string be the result of running Serializing an Item (<xref target="ser-item"/>) with the structure.</t> </li> <li> <t>Else, fail serialization.</t> </li> <li> <t>Return output_string converted into an array of bytes, using ASCII encoding <xref target="RFC0020"/>.</t> </li> </ol> <section anchor="ser-list"> <name>Serializing a List</name> <t>Given an array of (member_value, parameters) tuples as input_list, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Let output be an empty string.</t> </li> <li> <t>For each (member_value, parameters) of input_list: </t> <ol spacing="normal" type="1"><li> <t>If member_value is an array, append the result of running Serializing an Inner List (<xref target="ser-innerlist"/>) with (member_value, parameters) to output.</t> </li> <li> <t>Otherwise, append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</t> </li> <li> <t>If more member_values remain in input_list: </t> <ol spacing="normal" type="1"><li> <t>Append "," to output.</t> </li> <li> <t>Append a single SP to output.</t> </li> </ol> </li> </ol> </li> <li> <t>Return output.</t> </li> </ol> <section anchor="ser-innerlist"> <name>Serializing an Inner List</name> <t>Given an array of (member_value, parameters) tuples as inner_list, and parameters as list_parameters, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Let output be the string "(".</t> </li> <li> <t>For each (member_value, parameters) of inner_list: </t> <ol spacing="normal" type="1"><li> <t>Append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</t> </li> <li> <t>If more values remain in inner_list, append a single SP to output.</t> </li> </ol> </li> <li> <t>Append ")" to output.</t> </li> <li> <t>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with list_parameters to output.</t> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-params"> <name>Serializing Parameters</name> <t>Given an ordered Dictionary as input_parameters (each member having a param_key and a param_value), return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Let output be an empty string.</t> </li> <li> <t>For each param_key with a value of param_value in input_parameters: </t> <ol spacing="normal" type="1"><li> <t>Append ";" to output.</t> </li> <li> <t>Append the result of running Serializing a Key (<xref target="ser-key"/>) with param_key to output.</t> </li> <li> <t>If param_value is not Boolean true: </t> <ol spacing="normal" type="1"><li> <t>Append "=" to output.</t> </li> <li> <t>Append the result of running Serializing a bare Item (<xref target="ser-bare-item"/>) with param_value to output.</t> </li> </ol> </li> </ol> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-key"> <name>Serializing a Key</name> <t>Given a key as input_key, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Convert input_key into a sequence of ASCII characters; if conversion fails, fail serialization.</t> </li> <li> <t>If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*", fail serialization.</t> </li> <li> <t>If the first character of input_key is not lcalpha or "*", fail serialization.</t> </li> <li> <t>Let output be an empty string.</t> </li> <li> <t>Append input_key to output.</t> </li> <li> <t>Return output.</t> </li> </ol> </section> </section> <section anchor="ser-dictionary"> <name>Serializing a Dictionary</name> <t>Given an ordered Dictionary as input_dictionary (each member having a member_key and a tuple value of (member_value, parameters)), return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Let output be an empty string.</t> </li> <li> <t>For each member_key with a value of (member_value, parameters) in input_dictionary: </t> <ol spacing="normal" type="1"><li> <t>Append the result of running Serializing a Key (<xref target="ser-key"/>) with member's member_key to output.</t> </li> <li> <t>If member_value is Boolean true: </t> <ol spacing="normal" type="1"><li> <t>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with parameters to output.</t> </li> </ol> </li> <li> <t>Otherwise: </t> <ol spacing="normal" type="1"><li> <t>Append "=" to output.</t> </li> <li> <t>If member_value is an array, append the result of running Serializing an Inner List (<xref target="ser-innerlist"/>) with (member_value, parameters) to output.</t> </li> <li> <t>Otherwise, append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</t> </li> </ol> </li> <li> <t>If more members remain in input_dictionary: </t> <ol spacing="normal" type="1"><li> <t>Append "," to output.</t> </li> <li> <t>Append a single SP to output.</t> </li> </ol> </li> </ol> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-item"> <name>Serializing an Item</name> <t>Given an Item as bare_item and Parameters as item_parameters, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Let output be an empty string.</t> </li> <li> <t>Append the result of running Serializing a Bare Item (<xref target="ser-bare-item"/>) with bare_item to output.</t> </li> <li> <t>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with item_parameters to output.</t> </li> <li> <t>Return output.</t> </li> </ol> <section anchor="ser-bare-item"> <name>Serializing a Bare Item</name> <t>Given an Item as input_item, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>If input_item is an Integer, return the result of running Serializing an Integer (<xref target="ser-integer"/>) with input_item.</t> </li> <li> <t>If input_item is a Decimal, return the result of running Serializing a Decimal (<xref target="ser-decimal"/>) with input_item.</t> </li> <li> <t>If input_item is a String, return the result of running Serializing a String (<xref target="ser-string"/>) with input_item.</t> </li> <li> <t>If input_item is a Token, return the result of running Serializing a Token (<xref target="ser-token"/>) with input_item.</t> </li> <li> <t>If input_item is a Byte Sequence, return the result of running Serializing a Byte Sequence (<xref target="ser-binary"/>) with input_item.</t> </li> <li> <t>If input_item is a Boolean, return the result of running Serializing a Boolean (<xref target="ser-boolean"/>) with input_item.</t> </li> <li> <t>If input_item is a Date, return the result of running Serializing a Date (<xref target="ser-date"/>) with input_item.</t> </li> <li> <t>If input_item is a Display String, return the result of running Serializing a Display String (<xref target="ser-display"/>) with input_item.</t> </li> <li> <t>Otherwise, fail serialization.</t> </li> </ol> </section> </section> <section anchor="ser-integer"> <name>Serializing an Integer</name> <t>Given an Integer as input_integer, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>If input_integer is not an integer in the range of -999,999,999,999,999 to 999,999,999,999,999 inclusive, fail serialization.</t> </li> <li> <t>Let output be an empty string.</t> </li> <li> <t>If input_integer is less than (but not equal to) 0, append "-" to output.</t> </li> <li> <t>Append input_integer's numeric value represented in base 10 using only decimal digits to output.</t> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-decimal"> <name>Serializing a Decimal</name> <t>Given a decimal number as input_decimal, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>If input_decimal is not a decimal number, fail serialization.</t> </li> <li> <t>If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant.</t> </li> <li> <t>If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialization.</t> </li> <li> <t>Let output be an empty string.</t> </li> <li> <t>If input_decimal is less than (but not equal to) 0, append "-" to output.</t> </li> <li> <t>Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0".</t> </li> <li> <t>Append "." to output.</t> </li> <li> <t>If input_decimal's fractional component is zero, append "0" to output.</t> </li> <li> <t>Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal digits) to output.</t> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-string"> <name>Serializing a String</name> <t>Given a String as input_string, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Convert input_string into a sequence of ASCII characters; if conversion fails, fail serialization.</t> </li> <li> <t>If input_string contains characters in the range %x00-1f or %x7f-ff (i.e., not in VCHAR or SP), fail serialization.</t> </li> <li> <t>Let output be the string DQUOTE.</t> </li> <li> <t>For each character char in input_string: </t> <ol spacing="normal" type="1"><li> <t>If char is "\" or DQUOTE: </t> <ol spacing="normal" type="1"><li> <t>Append "\" to output.</t> </li> </ol> </li> <li> <t>Append char to output.</t> </li> </ol> </li> <li> <t>Append DQUOTE to output.</t> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-token"> <name>Serializing a Token</name> <t>Given a Token as input_token, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Convert input_token into a sequence of ASCII characters; if conversion fails, fail serialization.</t> </li> <li> <t>If the first character of input_token is not ALPHA or "*", or the remaining portion contains a character not in tchar, ":", or "/", fail serialization.</t> </li> <li> <t>Let output be an empty string.</t> </li> <li> <t>Append input_token to output.</t> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-binary"> <name>Serializing a Byte Sequence</name> <t>Given a Byte Sequence as input_bytes, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>If input_bytes is not a sequence of bytes, fail serialization.</t> </li> <li> <t>Let output be an empty string.</t> </li> <li> <t>Append ":" to output.</t> </li> <li> <t>Append the result of base64-encoding input_bytes as per <xref section="4" sectionFormat="comma" target="RFC4648"/>, taking account of the requirements below.</t> </li> <li> <t>Append ":" to output.</t> </li> <li> <t>Return output.</t> </li> </ol> <t>The encoded data is required to be padded with "=", as per <xref section="3.2" sectionFormat="comma" target="RFC4648"/>.</t> <t>Likewise, encoded dataSHOULD<bcp14>SHOULD</bcp14> have pad bits set to zero, 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 anchor="ser-boolean"> <name>Serializing a Boolean</name> <t>Given a Boolean as input_boolean, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>If input_boolean is not a boolean, fail serialization.</t> </li> <li> <t>Let output be an empty string.</t> </li> <li> <t>Append "?" to output.</t> </li> <li> <t>If input_boolean is true, append "1" to output.</t> </li> <li> <t>If input_boolean is false, append "0" to output.</t> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-date"> <name>Serializing a Date</name> <t>Given a Date as input_date, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>Let output be "@".</t> </li> <li> <t>Append to output the result of running Serializing an Integer with input_date (<xref target="ser-integer"/>).</t> </li> <li> <t>Return output.</t> </li> </ol> </section> <section anchor="ser-display"> <name>Serializing a Display String</name> <t>Given a sequence of Unicodecodepointscode points as input_sequence, return an ASCII string suitable for use in an HTTP field value.</t> <ol spacing="normal" type="1"><li> <t>If input_sequence is not a sequence of Unicodecodepoints,code points, fail serialization.</t> </li> <li> <t>Let byte_array be the result of applying UTF-8 encoding (<xref section="3" sectionFormat="of"target="UTF8"/>)target="RFC3629"/>) to input_sequence. If encoding fails, fail serialization.</t> </li> <li> <t>Let encoded_string be a string containing "%" followed by DQUOTE.</t> </li> <li> <t>For each byte in byte_array: </t> <ol spacing="normal" type="1"><li> <t>If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff: </t> <ol spacing="normal" type="1"><li> <t>Append "%" to encoded_string.</t> </li> <li> <t>Let encoded_byte be the result of applying base16 encoding (<xref section="8" sectionFormat="of" target="RFC4648"/>) to byte, with any alphabetic characters converted to lowercase.</t> </li> <li> <t>Append encoded_byte to encoded_string.</t> </li> </ol> </li> <li> <t>Otherwise, decode byte as an ASCII character and append the result to encoded_string.</t> </li> </ol> </li> <li> <t>Append DQUOTE to encoded_string.</t> </li> <li> <t>Return encoded_string.</t> </li> </ol> <t>Note that <xreftarget="UTF8"/>target="RFC3629"/> prohibits the encoding ofcodepointscode points between U+D800 and U+DFFF (surrogates); if they occur in input_sequence, serialization will fail.</t> </section> </section> <section anchor="text-parse"> <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 section specifies the algorithm for doing so.</t> <t>Given an array of bytes as input_bytes that represent the chosen field's field-value (which is empty if that field is not present) and field_type (one of "dictionary", "list", or "item"), return the parsed field value.</t> <ol spacing="normal" type="1"><li> <t>Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.</t> </li> <li> <t>Discard any leading SP characters from input_string.</t> </li> <li> <t>If field_type is "list", let output be the result of running Parsing a List (<xref target="parse-list"/>) with input_string.</t> </li> <li> <t>If field_type is "dictionary", let output be the result of running Parsing a Dictionary (<xref target="parse-dictionary"/>) with input_string.</t> </li> <li> <t>If field_type is "item", let output be the result of running Parsing an Item (<xref target="parse-item"/>) with input_string.</t> </li> <li> <t>Discard any leading SP characters from input_string.</t> </li> <li> <t>If input_string is not empty, fail parsing.</t> </li> <li> <t>Otherwise, return output.</t> </li> </ol> <t>When generating input_bytes, parsersMUST<bcp14>MUST</bcp14> combine all field lines in the same section (header or trailer) that case-insensitively match the field name into one comma-separated field-value, as per <xref section="5.2" sectionFormat="of"target="HTTP"/>;target="RFC9110"/>; this assures that the entire field value is processed correctly.</t> <t>For Lists and Dictionaries, this has the effect of correctly concatenating all of the field's lines, as long as individual members of the top-level data structure are not split across multiple field instances. The parsing algorithms for both types allow tab characters, since these might be used to combine field lines by some implementations.</t> <t>Strings split across multiple field lines will have unpredictable results, 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 upstream intermediary, the results are not under the control of the serializer or the parser, 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>ParsersMAY<bcp14>MAY</bcp14> 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 allowed to fail when processing this field section:</t> <sourcecode type="http-message"><![CDATA[ Example-String: "foo Example-String: bar" ]]></sourcecode> <t>If parsing fails, either the entire field valueMUST<bcp14>MUST</bcp14> be ignored (i.e., treated as if the field were not present in the section), or alternatively the complete HTTP messageMUST<bcp14>MUST</bcp14> be treated as malformed. This is intentionally strict to improve interoperability and safety, and field specifications that use Structured Fields are not allowed to loosen this requirement.</t> <t>Note that this requirement does not apply to an implementation that is 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"> <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 value.</t> <ol spacing="normal" type="1"><li> <t>Let members be an empty array.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>Append the result of running Parsing an Item or Inner List (<xref target="parse-item-or-list"/>) with input_string to members.</t> </li> <li> <t>Discard any leading OWS characters from input_string.</t> </li> <li> <t>If input_string is empty, return members.</t> </li> <li> <t>Consume the first character of input_string; if it is not ",", fail parsing.</t> </li> <li> <t>Discard any leading OWS characters from input_string.</t> </li> <li> <t>If input_string is empty, there is a trailing comma; fail parsing.</t> </li> </ol> </li> <li> <t>No structured data has been found; return members (which is empty).</t> </li> </ol> <section anchor="parse-item-or-list"> <name>Parsing an Item or Inner List</name> <t>Given an ASCII string as input_string, return the tuple (item_or_inner_list, parameters), where item_or_inner_list can be either a single bare item or an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is "(", return the result of running Parsing an Inner List (<xref target="parse-innerlist"/>) with input_string.</t> </li> <li> <t>Return the result of running Parsing an Item (<xref target="parse-item"/>) with input_string.</t> </li> </ol> </section> <section anchor="parse-innerlist"> <name>Parsing an Inner List</name> <t>Given an ASCII string as input_string, return the tuple (inner_list, parameters), where inner_list is an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>Consume the first character of input_string; if it is not "(", fail parsing.</t> </li> <li> <t>Let inner_list be an empty array.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>Discard any leading SP characters from input_string.</t> </li> <li> <t>If the first character of input_string is ")": </t> <ol spacing="normal" type="1"><li> <t>Consume the first character of input_string.</t> </li> <li> <t>Let parameters be the result of running Parsing Parameters (<xref target="parse-param"/>) with input_string.</t> </li> <li> <t>Return the tuple (inner_list, parameters).</t> </li> </ol> </li> <li> <t>Let item be the result of running Parsing an Item (<xref target="parse-item"/>) with input_string.</t> </li> <li> <t>Append item to inner_list.</t> </li> <li> <t>If the first character of input_string is not SP or ")", fail parsing.</t> </li> </ol> </li> <li> <t>The end of the Inner List was not found; fail parsing.</t> </li> </ol> </section> </section> <section anchor="parse-dictionary"> <name>Parsing a Dictionary</name> <t>Given an ASCII string as input_string, return an ordered map whose values are (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>Let dictionary be an empty, ordered map.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>Let this_key be the result of running Parsing a Key (<xref target="parse-key"/>) with input_string.</t> </li> <li> <t>If the first character of input_string is "=": </t> <ol spacing="normal" type="1"><li> <t>Consume the first character of input_string.</t> </li> <li> <t>Let member be the result of running Parsing an Item or Inner List (<xref target="parse-item-or-list"/>) with input_string.</t> </li> </ol> </li> <li> <t>Otherwise: </t> <ol spacing="normal" type="1"><li> <t>Let value be Boolean true.</t> </li> <li> <t>Let parameters be the result of running Parsing Parameters (<xref target="parse-param"/>) with input_string.</t> </li> <li> <t>Let member be the tuple (value, parameters).</t> </li> </ol> </li> <li> <t>If dictionary already contains a key this_key (comparing character for character), overwrite its value with member.</t> </li> <li> <t>Otherwise, append key this_key with value member to dictionary.</t> </li> <li> <t>Discard any leading OWS characters from input_string.</t> </li> <li> <t>If input_string is empty, return dictionary.</t> </li> <li> <t>Consume the first character of input_string; if it is not ",", fail parsing.</t> </li> <li> <t>Discard any leading OWS characters from input_string.</t> </li> <li> <t>If input_string is empty, there is a trailing comma; fail parsing.</t> </li> </ol> </li> <li> <t>No structured data has been found; return dictionary (which is empty).</t> </li> </ol> <t>Note that when duplicate Dictionary keys are encountered, all but the last instance are ignored.</t> </section> <section anchor="parse-item"> <name>Parsing an Item</name> <t>Given an ASCII string as input_string, return a (bare_item, parameters) tuple. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>Let bare_item be the result of running Parsing a Bare Item (<xref target="parse-bare-item"/>) with input_string.</t> </li> <li> <t>Let parameters be the result of running Parsing Parameters (<xref target="parse-param"/>) with input_string.</t> </li> <li> <t>Return the tuple (bare_item, parameters).</t> </li> </ol> <section anchor="parse-bare-item"> <name>Parsing a Bare Item</name> <t>Given an ASCII string as input_string, return a bare Item. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is a "-" or a DIGIT, return the result of running Parsing an Integer or Decimal (<xref target="parse-number"/>) with input_string.</t> </li> <li> <t>If the first character of input_string is a DQUOTE, return the result of running Parsing a String (<xref target="parse-string"/>) with input_string.</t> </li> <li> <t>If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (<xref target="parse-token"/>) with input_string.</t> </li> <li> <t>If the first character of input_string is ":", return the result of running Parsing a Byte Sequence (<xref target="parse-binary"/>) with input_string.</t> </li> <li> <t>If the first character of input_string is "?", return the result of running Parsing a Boolean (<xref target="parse-boolean"/>) with input_string.</t> </li> <li> <t>If the first character of input_string is "@", return the result of running Parsing a Date (<xref target="parse-date"/>) with input_string.</t> </li> <li> <t>If the first character of input_string is "%", return the result of running Parsing a Display String (<xref target="parse-display"/>) with input_string.</t> </li> <li> <t>Otherwise, the item type is unrecognized; fail parsing.</t> </li> </ol> </section> <section anchor="parse-param"> <name>Parsing Parameters</name> <t>Given an ASCII string as input_string, return an ordered map whose values are bare Items. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>Let parameters be an empty, ordered map.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is not ";", exit the loop.</t> </li> <li> <t>Consume the ";" character from the beginning of input_string.</t> </li> <li> <t>Discard any leading SP characters from input_string.</t> </li> <li> <t>Let param_key be the result of running Parsing a Key (<xref target="parse-key"/>) with input_string.</t> </li> <li> <t>Let param_value be Boolean true.</t> </li> <li> <t>If the first character of input_string is "=": </t> <ol spacing="normal" type="1"><li> <t>Consume the "=" character at the beginning of input_string.</t> </li> <li> <t>Let param_value be the result of running Parsing a Bare Item (<xref target="parse-bare-item"/>) with input_string.</t> </li> </ol> </li> <li> <t>If parameters already contains a key param_key (comparing character for character), overwrite its value with param_value.</t> </li> <li> <t>Otherwise, append key param_key with value param_value to parameters.</t> </li> </ol> </li> <li> <t>Return parameters.</t> </li> </ol> <t>Note that when duplicate parameter keys are encountered, all but the last instance are ignored.</t> </section> <section anchor="parse-key"> <name>Parsing a Key</name> <t>Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is not lcalpha or "*", fail parsing.</t> </li> <li> <t>Let output_string be an empty string.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is not one of lcalpha, DIGIT, "_", "-", ".", or "*", return output_string.</t> </li> <li> <t>Let char be the result of consuming the first character of input_string.</t> </li> <li> <t>Append char to output_string.</t> </li> </ol> </li> <li> <t>Return output_string.</t> </li> </ol> </section> </section> <section anchor="parse-number"> <name>Parsing an Integer or Decimal</name> <t>Given an ASCII string as input_string, return an Integer or Decimal. input_string is modified to remove the parsed value.</t> <t>NOTE: This algorithm parses both Integers (<xref target="integer"/>) and Decimals (<xref target="decimal"/>), and returns the corresponding structure.</t> <ol spacing="normal" type="1"><li> <t>Let type be "integer".</t> </li> <li> <t>Let sign be 1.</t> </li> <li> <t>Let input_number be an empty string.</t> </li> <li> <t>If the first character of input_string is "-", consume it and set sign to -1.</t> </li> <li> <t>If input_string is empty, there is an empty integer; fail parsing.</t> </li> <li> <t>If the first character of input_string is not a DIGIT, fail parsing.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>Let char be the result of consuming the first character of input_string.</t> </li> <li> <t>If char is a DIGIT, append it to input_number.</t> </li> <li> <t>Else, if type is "integer" and char is ".": </t> <ol spacing="normal" type="1"><li> <t>If input_number contains more than 12 characters, fail parsing.</t> </li> <li> <t>Otherwise, append char to input_number and set type to "decimal".</t> </li> </ol> </li> <li> <t>Otherwise, prepend char to input_string, and exit the loop.</t> </li> <li> <t>If type is "integer" and input_number contains more than 15 characters, fail parsing.</t> </li> <li> <t>If type is "decimal" and input_number contains more than 16 characters, fail parsing.</t> </li> </ol> </li> <li> <t>If type is "integer": </t> <ol spacing="normal" type="1"><li> <t>Let output_number be an Integer that is the result of parsing input_number as an integer.</t> </li> </ol> </li> <li> <t>Otherwise: </t> <ol spacing="normal" type="1"><li> <t>If the final character of input_number is ".", fail parsing.</t> </li> <li> <t>If the number of characters after "." in input_number is greater than three, fail parsing.</t> </li> <li> <t>Let output_number be a Decimal that is the result of parsing input_number as a decimal number.</t> </li> </ol> </li> <li> <t>Let output_number be the product of output_number and sign.</t> </li> <li> <t>Return output_number.</t> </li> </ol> </section> <section anchor="parse-string"> <name>Parsing a String</name> <t>Given an ASCII string as input_string, return an unquoted String. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>Let output_string be an empty string.</t> </li> <li> <t>If the first character of input_string is not DQUOTE, fail parsing.</t> </li> <li> <t>Discard the first character of input_string.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>Let char be the result of consuming the first character of input_string.</t> </li> <li> <t>If char is a backslash ("\"): </t> <ol spacing="normal" type="1"><li> <t>If input_string is now empty, fail parsing.</t> </li> <li> <t>Let next_char be the result of consuming the first character of input_string.</t> </li> <li> <t>If next_char is not DQUOTE or "\", fail parsing.</t> </li> <li> <t>Append next_char to output_string.</t> </li> </ol> </li> <li> <t>Else, if char is DQUOTE, return output_string.</t> </li> <li> <t>Else, if char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.</t> </li> <li> <t>Else, append char to output_string.</t> </li> </ol> </li> <li> <t>Reached the end of input_string without finding a closing DQUOTE; fail parsing.</t> </li> </ol> </section> <section anchor="parse-token"> <name>Parsing a Token</name> <t>Given an ASCII string as input_string, return a Token. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is not ALPHA or "*", fail parsing.</t> </li> <li> <t>Let output_string be an empty string.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is not in tchar, ":", or "/", return output_string.</t> </li> <li> <t>Let char be the result of consuming the first character of input_string.</t> </li> <li> <t>Append char to output_string.</t> </li> </ol> </li> <li> <t>Return output_string.</t> </li> </ol> </section> <section anchor="parse-binary"> <name>Parsing a Byte Sequence</name> <t>Given an ASCII string as input_string, return a Byte Sequence. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is not ":", fail parsing.</t> </li> <li> <t>Discard the first character of input_string.</t> </li> <li> <t>If there is not a ":" character before the end of input_string, fail parsing.</t> </li> <li> <t>Let b64_content be the result of consuming content of input_string up to but not including the first instance of the character ":".</t> </li> <li> <t>Consume the ":" character at the beginning of input_string.</t> </li> <li> <t>If b64_content contains a character not included in ALPHA, DIGIT, "+", "/", and "=", fail parsing.</t> </li> <li> <t>Let binary_content be the result of base64-decoding <xref target="RFC4648"/> b64_content, synthesizing padding if necessary (note the requirements about recipient behavior below). If base64 decoding fails, parsing fails.</t> </li> <li> <t>Return binary_content.</t> </li> </ol> <t>Because some implementations of base64 do not allow rejection of encoded data that is not properly "=" padded (see <xref section="3.2" sectionFormat="comma" target="RFC4648"/>), parsersSHOULD NOT<bcp14>SHOULD NOT</bcp14> fail when "=" padding is not present, unless they cannot be configured to do so.</t> <t>Because some implementations of base64 do not allow rejection of encoded data that has non-zero pad bits (see <xref section="3.5" sectionFormat="comma" target="RFC4648"/>), parsersSHOULD NOT<bcp14>SHOULD NOT</bcp14> fail when non-zero pad bits are present, unless they cannot be configured to do so.</t> <t>This specification does not relax the requirements in Sections <xref target="RFC4648" section="3.1" sectionFormat="bare"/> and <xref target="RFC4648" section="3.3" sectionFormat="bare"/> of <xref target="RFC4648"/>; therefore, parsersMUST<bcp14>MUST</bcp14> fail on characters outside the base64 alphabet and on line feeds in encoded data.</t> </section> <section anchor="parse-boolean"> <name>Parsing a Boolean</name> <t>Given an ASCII string as input_string, return a Boolean. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is not "?", fail parsing.</t> </li> <li> <t>Discard the first character of input_string.</t> </li> <li> <t>If the first character of input_string matches "1", discard the first character, and return true.</t> </li> <li> <t>If the first character of input_string matches "0", discard the first character, and return false.</t> </li> <li> <t>No value has matched; fail parsing.</t> </li> </ol> </section> <section anchor="parse-date"> <name>Parsing a Date</name> <t>Given an ASCII string as input_string, return a Date. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>If the first character of input_string is not "@", fail parsing.</t> </li> <li> <t>Discard the first character of input_string.</t> </li> <li> <t>Let output_date be the result of running Parsing an Integer or Decimal (<xref target="parse-number"/>) with input_string.</t> </li> <li> <t>If output_date is a Decimal, fail parsing.</t> </li> <li> <t>Return output_date.</t> </li> </ol> </section> <section anchor="parse-display"> <name>Parsing a Display String</name> <t>Given an ASCII string as input_string, return a sequence of Unicodecodepoints.code points. input_string is modified to remove the parsed value.</t> <ol spacing="normal" type="1"><li> <t>If the first two characters of input_string are not "%" followed by DQUOTE, fail parsing.</t> </li> <li> <t>Discard the first two characters of input_string.</t> </li> <li> <t>Let byte_array be an empty byte array.</t> </li> <li> <t>While input_string is not empty: </t> <ol spacing="normal" type="1"><li> <t>Let char be the result of consuming the first character of input_string.</t> </li> <li> <t>If char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.</t> </li> <li> <t>If char is "%": </t> <ol spacing="normal" type="1"><li> <t>Let octet_hex be the result of consuming two characters from input_string. If there are not two characters, fail parsing.</t> </li> <li> <t>If octet_hex contains characters outside the range %x30-39 or %x61-66 (i.e., it is not in 0-9 or lowercase a-f), fail parsing.</t> </li> <li> <t>Let octet be the result of hex decoding octet_hex (<xref section="8" sectionFormat="of" target="RFC4648"/>).</t> </li> <li> <t>Append octet to byte_array.</t> </li> </ol> </li> <li> <t>If char is DQUOTE: </t> <ol spacing="normal" type="1"><li> <t>Let unicode_sequence be the result of decoding byte_array as a UTF-8 string (<xref section="3" sectionFormat="of"target="UTF8"/>).target="RFC3629"/>). Fail parsing if decoding fails.</t> </li> <li> <t>Return unicode_sequence.</t> </li> </ol> </li> <li> <t>Otherwise, if char is not "%" or DQUOTE: </t> <ol spacing="normal" type="1"><li> <t>Let byte be the result of applying ASCII encoding to char.</t> </li> <li> <t>Append byte to byte_array.</t> </li> </ol> </li> </ol> </li> <li> <t>Reached the end of input_string without finding a closing DQUOTE; fail parsing.</t> </li> </ol> </section> </section> </section> <section anchor="iana"> <name>IANA Considerations</name><t>Please add<t>IANA has added the following note to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":</t><ul empty="true"> <li> <t>The<!-- [rfced] IANA Considerations. FYI, at the end of AUTH48, we will ask IANA to update the following note: Original: 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 RFC 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 represented as a Structured FieldsToken,Token and therefore may be incompatible with being mapped into field values that refer to it.</t></li> </ul> <t>Then, add a</blockquote> <t>A new column, "StructuredType".</t> <t>Then, addType", has been added to the registry.</t> <t>The indicated Structured Type for each existing registry entry listed in <xreftarget="existing-fields"/>.</t>target="existing-fields"/> has also been added.</t> <table anchor="existing-fields"> <name>Existing Fields</name> <thead> <tr> <th align="left">Field Name</th> <th align="left">Structured Type</th> </tr> </thead> <tbody> <tr> <td align="left">Accept-CH</td> <td align="left">List</td> </tr> <tr> <td align="left">Cache-Status</td> <td align="left">List</td> </tr> <tr> <td align="left">CDN-Cache-Control</td> <td align="left">Dictionary</td> </tr> <tr> <td align="left">Cross-Origin-Embedder-Policy</td> <td align="left">Item</td> </tr> <tr> <td align="left">Cross-Origin-Embedder-Policy-Report-Only</td> <td align="left">Item</td> </tr> <tr> <td align="left">Cross-Origin-Opener-Policy</td> <td align="left">Item</td> </tr> <tr> <td align="left">Cross-Origin-Opener-Policy-Report-Only</td> <td align="left">Item</td> </tr> <tr> <td align="left">Origin-Agent-Cluster</td> <td align="left">Item</td> </tr> <tr> <td align="left">Priority</td> <td align="left">Dictionary</td> </tr> <tr> <td align="left">Proxy-Status</td> <td align="left">List</td> </tr> </tbody> </table> </section> <section anchor="security"> <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 consumption). Most HTTP implementations limit the sizes of individual fields as well 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 to change the meaning of a Structured Field. In some circumstances, this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances.</t> <t>The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters. Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See <xreftarget="PRECIS"/>target="RFC8264"/> and <xref target="UNICODE-SECURITY"/>.</t> </section> </middle> <back> <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> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="HTTP"> <front> <title>HTTP Semantics</title> <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/> <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/> <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/> <date month="June" year="2022"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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, 7232, 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</title> <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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</title> <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 protocol 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 data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4648"/> <seriesInfo name="DOI" value="10.17487/RFC4648"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="IEEE754" target="https://ieeexplore.ieee.org/document/8766229"> <front> <title>IEEE Standard for Floating-Point Arithmetic</title> <author> <organization>IEEE</organization> </author> <date year="2019" month="July"/> </front> <seriesInfoname="IEEE"name="IEEE Std" value="754-2019"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/> <seriesInfo name="ISBN" value="978-1-5044-5924-2"/> </reference><reference anchor="RFC9113"> <front> <title>HTTP/2</title> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/> <date month="June" year="2022"/> <abstract> <t>This specification describes an optimized expression of the semantics of<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7541.xml"/> <!-- [rfced] Informative References. FYI, because a date was provided in theHypertext Transfer Protocol (HTTP), referredfollowing reference, we have updated it toas HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources andprovide both areduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t> <t>This document obsoletes RFCs 7540versioned and8740.</t> </abstract> </front> <seriesInfo name="RFC" value="9113"/> <seriesInfo name="DOI" value="10.17487/RFC9113"/> </reference> <reference anchor="HPACK"> <front> <title>HPACK: Header Compression for HTTP/2</title> <author fullname="R. Peon" initials="R." surname="Peon"/> <author fullname="H. Ruellan" initials="H." surname="Ruellan"/> <date month="May" year="2015"/> <abstract> <t>This specification defines HPACK, a compression format for efficiently 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>versionless URL. Please let us know if any changes are necessary. Original: [UNICODE-SECURITY] Davis, M. and M. Suignard, "Unicode Security Considerations", Unicode Technical Report #16, 19 September 2014, <http://www.unicode.org/reports/tr36/>. Current: [UNICODE-SECURITY] Davis, M. and M. Suignard, "Unicode Security Considerations", Unicode Technical Report #36, 19 September 2014, <https://www.unicode.org/reports/tr36/tr36-15.html>. Latest version available at <https://www.unicode.org/reports/tr36/>. --> <reference anchor="UNICODE-SECURITY"target="http://www.unicode.org/reports/tr36/">target="https://www.unicode.org/reports/tr36/tr36-15.html"> <front> <title>Unicode Security Considerations</title> <author initials="M." surname="Davis" fullname="Mark Davis"> <organization/> </author> <author initials="M." surname="Suignard" fullname="Michel Suignard"> <organization/> </author> <date year="2014" month="September" day="19"/> </front> <seriesInfo name="Unicode Technical Report"value="#16"/> </reference> <reference anchor="PRECIS"> <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 strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). 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="Crocker"/> <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 modifiedvalue="#36"/> <annotation>Latest versionof Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [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 ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t> <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability 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 JSON 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"/>available at <eref target="https://www.unicode.org/reports/tr36/" brackets="angle"/>.</annotation> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8264.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7493.xml"/> </references> </references><?line 1069?><section anchor="faq"> <name>Frequently Asked Questions</name> <section anchor="why-not-json"> <name>Why Not JSON?</name> <t>Earlier proposals for Structured Fields were based upon JSON <xref target="RFC8259"/>. However, constraining its use to make it suitable for HTTP fields required senders and recipients to implement specific additional handling.</t> <t>For example, JSON has specification issues around large numbers and objects with duplicate members. Although advice for avoiding these issues is available (e.g., <xref target="RFC7493"/>), it cannot be relied upon.</t> <t>Likewise, JSON strings are by default Unicode strings, which have a number of potential interoperability issues (e.g., in comparison). Although implementers can be advised to avoid non-ASCII content where unnecessary, this is difficult 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 and 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 limit is specified, it's likely that some field definition will find a need to violate it.</t> <t>Because of JSON's broad adoption and implementation, it is difficult to impose such additional constraints across all implementations; some deployments 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 field values.</t> <t>Since a major goal for Structured Fields is to improve interoperability and simplify implementation, these concerns led to a format that requires a dedicated parser and serializer.</t> <t>Additionally, there were widely shared feelings that JSON doesn't "look right" in HTTP fields.</t> </section> </section> <section anchor="implementation-notes"> <name>Implementation Notes</name> <t>A generic implementation of this specification should expose the top-level serialize (<xref target="text-serialize"/>) and parse (<xref target="text-parse"/>) functions. They need not be functions; for example, it could be implemented as an object, with methods for each of the different top-level types.</t> <t>For interoperability, it's important that generic implementations be complete and follow the algorithms closely; see <xref target="strict"/>. To aid this, a common test suite is being maintained by the community at <https://github.com/httpwg/structured-field-tests>.</t> <t>Implementers should note that Dictionaries and Parameters are order-preserving maps. Some fields may not convey meaning in the ordering of these data types, but it should still be exposed so that it will be available to applications that need to use it.</t> <t>Likewise, implementations should note that it's important to preserve the 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 types 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>Implementations are allowed to limit the size of different structures, subject to the minimums defined for each type. When a structure exceeds an implementation limit, that structure fails parsing or serialization.</t> </section> <section anchor="abnf"> <name>ABNF</name> <t>This section uses the Augmented Backus-Naur Form (ABNF) notation <xref target="RFC5234"/> to illustrate the expected syntax of Structured Fields. However, it cannot be used to validate theirsyntax,syntax because it does not capture all requirements.</t> <t>This section is non-normative. If there is disagreement between the parsing algorithms and ABNF, the specified algorithms take precedence.</t> <sourcecode type="abnf"><![CDATA[ sf-list = list-member *( OWS "," OWS list-member ) list-member = sf-item / inner-list inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")" parameters parameters = *( ";" *SP parameter ) parameter = param-key [ "=" param-value ] param-key = key key = ( lcalpha / "*" ) *( lcalpha / DIGIT / "_" / "-" / "." / "*" ) lcalpha = %x61-7A ; a-z param-value = bare-item sf-dictionary = dict-member *( OWS "," OWS dict-member ) dict-member = member-key ( parameters / ( "=" member-value )) member-key = key member-value = sf-item / inner-list sf-item = bare-item parameters bare-item = sf-integer / sf-decimal / sf-string / sf-token / sf-binary / sf-boolean / sf-date / sf-displaystring sf-integer = ["-"] 1*15DIGIT sf-decimal = ["-"] 1*12DIGIT "." 1*3DIGIT sf-string = DQUOTE *( unescaped / "%" / bs-escaped ) DQUOTE sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" ) sf-binary = ":" base64 ":" sf-boolean = "?" ( "0" / "1" ) sf-date = "@" sf-integer sf-displaystring = "%" DQUOTE *( unescaped / "\" / pct-encoded ) DQUOTE base64 = *( ALPHA / DIGIT / "+" / "/" ) *"=" unescaped = %x20-21 / %x23-24 / %x26-5B / %x5D-7E bs-escaped = "\" ( DQUOTE / "\" ) pct-encoded = "%" lc-hexdig lc-hexdig lc-hexdig = DIGIT / %x61-66 ; 0-9, a-f ]]></sourcecode> </section> <section anchor="changes"> <name>Changes from RFC 8941</name> <t>This revision of theStructured"Structured Field Values forHTTPHTTP" specification has made the following changes:</t> <ul spacing="normal"> <li> <t>Added the Datestructured type.Structured Type. (<xref target="date"/>)</t> </li> <li> <t>Stopped encouraging use of ABNF in definitions of newstructured fields.Structured Fields. (<xref target="specify"/>)</t> </li> <li> <t>Moved ABNF to an informative appendix. (<xref target="abnf"/>)</t> </li> <li> <t>Added a "Structured Type" column to theHTTP"Hypertext Transfer Protocol (HTTP) Field NameRegistry.Registry". (<xref target="iana"/>)</t> </li> <li> <t>Refined parse failure handling. (<xref target="text-parse"/>)</t> </li> <li> <t>Added the Display Stringstructured type.Structured Type. (<xref target="displaystring"/>)</t> </li> </ul> </section> <section numbered="false" anchor="acknowledgements"> <name>Acknowledgements</name> <t>Many thanks toMatthew Kerwin<contact fullname="Matthew Kerwin"/> for his detailed feedback and careful consideration during the development of this specification.</t> <t>Thanks also toIan Clelland, Roy Fielding, Anne<contact fullname="Ian Clelland"/>, <contact fullname="Roy Fielding"/>, <contact fullname="Anne vanKesteren, Kazuho Oku, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and Jeffrey YasskinKesteren"/>, <contact fullname="Kazuho Oku"/>, <contact fullname="Evert Pot"/>, <contact fullname="Julian Reschke"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Mike West"/>, and <contact fullname="Jeffrey Yasskin"/> for their contributions.</t> </section></back><!--##markdown-source: H4sIAAAAAAAAA9V9+3fbxtHo7/wr8NEn11JKUqJetqQoiWzLsVo/VEtOTtr0 +IAkSCIGARYAJTOq+7ffee0TIEXacu53c9qEIoHd2dl578xsu91ulHGZREfB ZZnP+uUsjwbB8zhKBsHPYTKLimCY5cGLq6uLxiDrp+EEnhzk4bBsx1E5bI/L ctqLi3YxxH9vHzQGYQlP3D47vTr71OjDH6Msnx8FRTloxNP8KIBJinJne/tw e6cR5lF4FJxOp0kMT8ZZWgRhOgjeRmHSvoonUeMmyz+M8mw2PWIIPkRz+Gpw FJynZZSnUdl+hqA0sl6RJVEZFUfB48O9bqNRlDDQ+zDJUgBmHhWNYhLm5ft/ zzJ6KM0a0/go+GeZ9VsB/CtOB1FatoIiy8s8GhbwaT6RD2Ue9+GnfjaZhvJh Ag/DT3GaxGn0r0YD/ozL+VEjCC7PXj4/Cppvnz8NUvin2WiEs3Kc5fBbG34O 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] Terminology. We have made the following updates to terms by choosing the latter forms. Please review: codepoint / code point - 4 instances Member / member - 1 instance structured field / Structured Field - 3 instances structured header / Strctured Header - 2 instances structured trailer / Structured Trailer - 2 instances structured type / Structured Type - 2 instances unicode / Unicode - 1 instance --> <!-- [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-author-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>