Skip to content

Instantly share code, notes, and snippets.

@shogo82148

shogo82148/draft-ietf-httpbis-sfbis-03.xml

Last active August 24, 2023 12:15
Show Gist options
  • Save shogo82148/09006d33c6eb1dbe4113387889b02b2e to your computer and use it in GitHub Desktop.
Save shogo82148/09006d33c6eb1dbe4113387889b02b2e to your computer and use it in GitHub Desktop.
Download ZIP
Raw
draft-ietf-httpbis-sfbis-03.xml
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (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-03" category="std" consensus="true" obsoletes="8941" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.5 -->
<front>
<title>Structured Field Values for HTTP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-sfbis-03"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization>Cloudflare</organization>
<address>
<postal>
<city>Prahran</city>
<region>VIC</region>
<country>Australia</country>
</postal>
<email>[email protected]</email>
<uri>https://www.mnot.net/</uri>
</address>
</author>
<author initials="P.-H." surname="Kamp" fullname="Poul-Henning Kamp">
<organization>The Varnish Cache Project</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 75?>
<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:[email protected]"/>),
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 82?>
<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"/>, 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 <xref target="HTTP"/> 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", and "OPTIONAL" in this document are to be interpreted as described in BCP 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 <xref target="HTTP"/> for the same purpose.</t>
<t>This document uses algorithms to specify parsing and serialization behaviors. When parsing from HTTP fields, implementations MUST 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. Implementations MAY 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>Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect.</li>
<li>Identify whether the field is a Structured Header (i.e., it can only be used in the header section -- the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both).</li>
<li>Specify the type of the field value; either List (<xref target="list"/>), Dictionary (<xref target="dictionary"/>), or Item (<xref target="item"/>).</li>
<li>Define the semantics of the field value.</li>
<li>Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.</li>
</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>Field definitions can only use this specification for the entire field value, not a portion thereof.</t>
<t>Specifications can refer to a field name as a "structured header name", "structured trailer name", or "structured field name" as appropriate. Likewise, they can refer its field value as a "structured header value", "structured trailer value", or "structured field value" as necessary.</t>
<t>This specification defines minimums for the length or number of various structures supported by implementations. It does not specify maximum sizes in 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]. Its value
MUST be an Integer (Section 3.3.1 of [RFCnnnn]).</t>
<t>Its value indicates the amount of Foo in the message, and it MUST
be between 0 and 10, inclusive; other values MUST 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]), 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 field
MUST be ignored. If its value is a relative reference (Section 4.2
of [RFC3986]), it MUST 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 override 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 be extensible, because experience has shown that even when it is not foreseen, it is often necessary to modify and add to the allowable syntax and semantics of a field in a controlled fashion.</t>
<t>Both Items and Inner Lists allow Parameters as an extensibility 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 8941 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 reference to RFC 8941 cannot use the Date type, because some recipients might still be using an RFC 8941 parser to process it.</t>
<t>However, this document is designed to be backwards-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, field instance might contain a syntactically valid Date (<xref target="date"/>), even though that field's definition does not accommodate Dates. An RFC8941 implementation would fail parsing such a field instance, because they are 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 be detected and the field might subsequently be accepted and processed.</t>
</section>
</section>
<section anchor="types">
<name>Structured Data Types</name>
<t>This section defines the abstract types for Structured Fields, and summarizes how those types are serialized into textual HTTP fields.</t>
<t>In summary:</t>
<ul spacing="normal">
<li>There are three top-level types that an HTTP field can be defined as: Lists, Dictionaries, and Items.</li>
<li>Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items).</li>
<li>Both Items and Inner Lists can be Parameterized with key/value pairs.</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"/>; 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>Parsers MUST 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>Parsers MUST 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>Implementations MUST provide access to Parameters both by index and by key. Specifications MAY 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"/>) true MUST 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>Parsers MUST 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>Implementations MUST provide access to Dictionaries both by index and by key. Specifications MAY 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. Recipients MUST 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, Members 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"/>) true MUST 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>Parsers MUST 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>文字列は、0個以上の印刷可能なASCII <xref target="RFC0020"/> 文字（つまり、範囲%x20から%x7E）です。これには、タブ、改行、復帰などは含まれません。</t>
<t>文字列には直接的に非ASCII文字を含めることはできません。これは相互運用性の問題を引き起こすためであり、ほとんどの場合、フィールド値には必要ありません。</t>
<t>フィールド値が非ASCIIコンテンツを伝達する必要がある場合、Display Strings (<xref target="displaystring"/>)を指定できます。</t>
<t>HTTPフィールド内でテキストとしてシリアル化される場合、文字列はダブルクォートで区切られ、バックスラッシュ（「\」）を使用してダブルクォートとバックスラッシュをエスケープします。例：</t>
<sourcecode type="http-message"><![CDATA[
Example-String: "hello world"
]]></sourcecode>
<t>Stringsは、区切り記号としてDQUOTEのみを使用します。シングルクォートはStringsを区切りません。さらに、エスケープできるのはDQUOTEとバックスラッシュのみであり、バックスラッシュの後に続く他の文字は解析に失敗する必要があります。</t>
<t>パーサーは、少なくとも1024文字のStrings（デコード後）をサポートする必要があります。</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 <xref target="HTTP"/>, plus the ":" and "/" characters.</t>
<t>For example:</t>
<sourcecode type="http-message"><![CDATA[
Example-Token: foo123/456
]]></sourcecode>
<t>Parsers MUST support Tokens with at least 512 characters.</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>Parsers MUST 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 January 1, 1970 00:00:00 UTC, excluding leap seconds.</t>
<t>For example:</t>
<sourcecode type="http-message-new"><![CDATA[
Example-Date: @1659578233
]]></sourcecode>
</section>
<section anchor="displaystring">
<name>Display Strings</name>
<t>Display Stringsは、文字列と同様に、0個以上の文字で構成されていますが、文字列とは異なり、Unicodeのコンテンツを許容します。</t>
<t>Display Stringsは、値がエンドユーザーに表示される場合に使用することを意図しており、非ASCIIコンテンツを含める必要がある場合があります。Unicodeには処理上の考慮事項（正規化など）やセキュリティ上の考慮事項（同形文字攻撃など）があるため、String (<xref target="string"/>)またはToken (<xref target="token"/>)が適切な場合には使用しないことが推奨されます。</t>
<t>Display Stringsには、値で使用された言語を示すものは含まれていません。必要に応じて（例：パラメータを使用して）別途指定する必要があります。</t>
<t>For example:</t>
<sourcecode type="http-message-new"><![CDATA[
Example-DisplayString: %"This is intended for display to %C3%BCsers."
]]></sourcecode>
<t>Display Stringsを処理する際の追加のセキュリティ上の考慮事項については、<xref target="security"/>を参照してください。</t>
</section>
</section>
</section>
<section anchor="text">
<name>Working with Structured Fields in HTTP</name>
<t>This section defines how to serialize and parse Structured Fields in textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 <xref target="RFC9113"/> before compression with HPACK <xref target="HPACK"/>).</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>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).</li>
<li>If the structure is a List, let output_string be the result of running Serializing a List (<xref target="ser-list"/>) with the structure.</li>
<li>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.</li>
<li>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.</li>
<li>Else, fail serialization.</li>
<li>Return output_string converted into an array of bytes, using ASCII encoding <xref target="RFC0020"/>.</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>Let output be an empty string.</li>
<li>
<t>For each (member_value, parameters) of input_list:
</t>
<ol spacing="normal" type="1"><li>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.</li>
<li>Otherwise, append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</li>
<li>
<t>If more member_values remain in input_list:
</t>
<ol spacing="normal" type="1"><li>Append "," to output.</li>
<li>Append a single SP to output.</li>
</ol>
</li>
</ol>
</li>
<li>Return output.</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>Let output be the string "(".</li>
<li>
<t>For each (member_value, parameters) of inner_list:
</t>
<ol spacing="normal" type="1"><li>Append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</li>
<li>If more values remain in inner_list, append a single SP to output.</li>
</ol>
</li>
<li>Append ")" to output.</li>
<li>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with list_parameters to output.</li>
<li>Return output.</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>Let output be an empty string.</li>
<li>
<t>For each param_key with a value of param_value in input_parameters:
</t>
<ol spacing="normal" type="1"><li>Append ";" to output.</li>
<li>Append the result of running Serializing a Key (<xref target="ser-key"/>) with param_key to output.</li>
<li>
<t>If param_value is not Boolean true:
</t>
<ol spacing="normal" type="1"><li>Append "=" to output.</li>
<li>Append the result of running Serializing a bare Item (<xref target="ser-bare-item"/>) with param_value to output.</li>
</ol>
</li>
</ol>
</li>
<li>Return output.</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>Convert input_key into a sequence of ASCII characters; if conversion fails, fail serialization.</li>
<li>If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*", fail serialization.</li>
<li>If the first character of input_key is not lcalpha or "*", fail serialization.</li>
<li>Let output be an empty string.</li>
<li>Append input_key to output.</li>
<li>Return output.</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>Let output be an empty string.</li>
<li>
<t>For each member_key with a value of (member_value, parameters) in input_dictionary:
</t>
<ol spacing="normal" type="1"><li>Append the result of running Serializing a Key (<xref target="ser-key"/>) with member's member_key to output.</li>
<li>
<t>If member_value is Boolean true:
</t>
<ol spacing="normal" type="1"><li>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with parameters to output.</li>
</ol>
</li>
<li>
<t>Otherwise:
</t>
<ol spacing="normal" type="1"><li>Append "=" to output.</li>
<li>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.</li>
<li>Otherwise, append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</li>
</ol>
</li>
<li>
<t>If more members remain in input_dictionary:
</t>
<ol spacing="normal" type="1"><li>Append "," to output.</li>
<li>Append a single SP to output.</li>
</ol>
</li>
</ol>
</li>
<li>Return output.</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>Let output be an empty string.</li>
<li>Append the result of running Serializing a Bare Item (<xref target="ser-bare-item"/>) with bare_item to output.</li>
<li>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with item_parameters to output.</li>
<li>Return output.</li>
</ol>
<section anchor="ser-bare-item">
<name>Serializing a Bare Item</name>
<t>入力としてItemを受け取り、HTTPフィールド値で使用できるASCII文字列を返します。</t>
<ol spacing="normal" type="1">
<li>input_itemが整数の場合、Serializing an Integer (<xref target="ser-integer"/>)をinput_itemで実行した結果を返します。</li>
<li>input_itemが小数の場合、Serializing a Decimal (<xref target="ser-decimal"/>)をinput_itemで実行した結果を返します。</li>
<li>input_itemが文字列の場合、Serializing a String (<xref target="ser-string"/>)をinput_itemで実行した結果を返します。</li>
<li>input_itemがトークンの場合、Serializing a Token (<xref target="ser-token"/>)をinput_itemで実行した結果を返します。</li>
<li>input_itemがバイトシーケンスの場合、Serializing a Byte Sequence (<xref target="ser-binary"/>)をinput_itemで実行した結果を返します。</li>
<li>input_itemがブール値の場合、Serializing a Boolean (<xref target="ser-boolean"/>)をinput_itemで実行した結果を返します。</li>
<li>input_itemが日付の場合、Serializing a Date (<xref target="ser-date"/>)をinput_itemで実行した結果を返します。</li>
<li>input_itemがDisplay Stringsの場合、Serializing a Display String (<xref target="ser-display"/>)をinput_itemで実行した結果を返します。</li>
<li>それ以外の場合、シリアル化に失敗します。</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>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.</li>
<li>Let output be an empty string.</li>
<li>If input_integer is less than (but not equal to) 0, append "-" to output.</li>
<li>Append input_integer's numeric value represented in base 10 using only decimal digits to output.</li>
<li>Return output.</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>If input_decimal is not a decimal number, fail serialization.</li>
<li>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.</li>
<li>If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialization.</li>
<li>Let output be an empty string.</li>
<li>If input_decimal is less than (but not equal to) 0, append "-" to output.</li>
<li>Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0".</li>
<li>Append "." to output.</li>
<li>If input_decimal's fractional component is zero, append "0" to output.</li>
<li>Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal digits) to output.</li>
<li>Return output.</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>Convert input_string into a sequence of ASCII characters; if conversion fails, fail serialization.</li>
<li>If input_string contains characters in the range %x00-1f or %x7f-ff (i.e., not in VCHAR or SP), fail serialization.</li>
<li>Let output be the string DQUOTE.</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>Append "\" to output.</li>
</ol>
</li>
<li>Append char to output.</li>
</ol>
</li>
<li>Append DQUOTE to output.</li>
<li>Return output.</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>Convert input_token into a sequence of ASCII characters; if conversion fails, fail serialization.</li>
<li>If the first character of input_token is not ALPHA or "*", or the remaining portion contains a character not in tchar, ":", or "/", fail serialization.</li>
<li>Let output be an empty string.</li>
<li>Append input_token to output.</li>
<li>Return output.</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>If input_bytes is not a sequence of bytes, fail serialization.</li>
<li>Let output be an empty string.</li>
<li>Append ":" to output.</li>
<li>Append the result of base64-encoding input_bytes as per <xref section="4" sectionFormat="comma" target="RFC4648"/>, taking account of the requirements below.</li>
<li>Append ":" to output.</li>
<li>Return output.</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 data SHOULD 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>If input_boolean is not a boolean, fail serialization.</li>
<li>Let output be an empty string.</li>
<li>Append "?" to output.</li>
<li>If input_boolean is true, append "1" to output.</li>
<li>If input_boolean is false, append "0" to output.</li>
<li>Return output.</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>Let output be "@".</li>
<li>Append to output the result of running Serializing an Integer with input_date (<xref target="ser-integer"/>).</li>
<li>Return output.</li>
</ol>
</section>
<section anchor="ser-display">
<name>Serializing a Display String</name>
<t>Unicodeコードポイントのシーケンスinput_sequenceを受け取り、HTTPフィールド値で使用できるASCII文字列を返します。</t>
<ol spacing="normal" type="1">
<li>input_sequenceがUnicodeコードポイントのシーケンスでない場合、解析に失敗します。</li>
<li>byte_arrayを、input_sequenceにUTF-8エンコーディング (<xref target="UTF8"/>) を適用した結果とします。</li>
<li>encoded_stringを、"%"に続くDQUOTEを含む文字列とします。</li>
<li>
<t>byte_arrayの各バイトについて：</t>
<ol spacing="normal" type="1">
<li>
<t>byteが%x25 ("%")、%x22 (DQUOTE)、または範囲%x00-1fまたは%x7f-ffにある場合：</t>
<ol spacing="normal" type="1">
<li>encoded_stringに"%"を追加します。</li>
<li>byteに対してbase16エンコーディング (<xref section="8" sectionFormat="of" target="RFC4648"/>) を適用した結果をencoded_byteとします。</li>
<li>encoded_byteをencoded_stringに追加します。</li>
</ol>
</li>
<li>それ以外の場合、byteをASCII文字としてデコードし、結果をencoded_stringに追加します。</li>
</ol>
</li>
<li>encoded_stringにDQUOTEを追加します。</li>
<li>encoded_stringを返します。</li>
</ol>
</section>
</section>
<section anchor="text-parse">
<name>Parsing Structured Fields</name>
<t>受信側の実装がStructured FieldsであることがわかっているHTTPフィールドを解析する場合、相互運用性問題やセキュリティ問題が発生する可能性があるいくつかのエッジケースに注意することが重要です。このセクションでは、そのためのアルゴリズムを指定しています。</t>
<t>選択されたフィールドのフィールド値を表す入力バイトの配列（そのフィールドが存在しない場合は空）とフィールドタイプ（「dictionary」、「list」、または「item」のいずれか）を入力として受け取り、解析されたフィールド値を返します。</t>
<ol spacing="normal" type="1">
<li>input_bytesをASCII文字列input_stringに変換します。変換に失敗した場合は、解析を失敗します。</li>
<li>input_stringから先頭のSP文字を破棄します。</li>
<li>field_typeが「list」の場合、input_stringを使用してリストの解析を実行した結果を出力にします（<xref target="parse-list"/>）。</li>
<li>field_typeが「dictionary」の場合、input_stringを使用して辞書の解析を実行した結果を出力にします（<xref target="parse-dictionary"/>）。</li>
<li>field_typeが「item」の場合、input_stringを使用してアイテムの解析を実行した結果を出力にします（<xref target="parse-item"/>）。</li>
<li>input_stringから先頭のSP文字を破棄します。</li>
<li>input_stringが空でない場合、解析を失敗します。</li>
<li>それ以外の場合、出力を返します。</li>
</ol>
<t>入力バイトを生成する場合、パーサは、フィールド名が大文字小文字を区別せずに一致する同じセクション（ヘッダーまたはトレーラー）内のすべてのフィールド行を、<xref section="5.2" sectionFormat="of" target="HTTP"/>に従ってカンマで区切られたフィールド値に結合する必要があります。これにより、フィールド値全体が正しく処理されることが保証されます。</t>
<t>リストと辞書の場合、トップレベルのデータ構造の個々のメンバーが複数のフィールドインスタンスに分割されていない限り、フィールドのすべての行を正しく連結する効果があります。両方のタイプの解析アルゴリズムは、一部の実装でフィールド行を結合するために使用される可能性があるタブ文字を許可しています。</t>
<t>複数のフィールド行に分割された文字列は予測不可能な結果になります。なぜなら、1つ以上のカンマ（オプションの空白を含む）がパーサによって出力される文字列の一部になるからです。連結が上流の中間者によって行われる可能性があるため、シリアライザまたはパーサの両方が同じパーティーの制御下にある場合でも、結果は制御下にありません。</t>
<t>トークン、整数、10進数、およびバイトシーケンスは、挿入されたカンマにより解析が失敗するため、複数のフィールド行に分割することはできません。</t>
<t>複数のフィールド行にまたがるフィールド値を処理する場合、そのうちの1つがそのフィールドとして解析できない場合、パーサは失敗する場合があります。たとえば、sf-stringとして定義されたExample-Stringフィールドを処理するパーサは、次のフィールドセクションを処理する際に失敗することが許容されます。</t>
<sourcecode type="http-message"><![CDATA[
Example-String: "foo
Example-String: bar"
]]></sourcecode>
<t>解析に失敗した場合、フィールド値全体を無視する（つまり、セクションにフィールドが存在しない場合と同様に扱う）か、代替として完全なHTTPメッセージを不正な形式として扱う必要があります。これは、相互運用性と安全性を向上させるために意図的に厳格になっており、Structured Fieldsを使用するフィールド仕様では、この要件を緩和することはできません。</t>
<t>この要件は、フィールドを解析していない実装（たとえば、中継者）には適用されないことに注意してください。つまり、中継者は、メッセージを転送する前に失敗するフィールドを削除する必要はありません。</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>Let members be an empty array.</li>
<li>
<t>While input_string is not empty:
</t>
<ol spacing="normal" type="1"><li>Append the result of running Parsing an Item or Inner List (<xref target="parse-item-or-list"/>) with input_string to members.</li>
<li>Discard any leading OWS characters from input_string.</li>
<li>If input_string is empty, return members.</li>
<li>Consume the first character of input_string; if it is not ",", fail parsing.</li>
<li>Discard any leading OWS characters from input_string.</li>
<li>If input_string is empty, there is a trailing comma; fail parsing.</li>
</ol>
</li>
<li>No structured data has been found; return members (which is empty).</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>If the first character of input_string is "(", return the result of running Parsing an Inner List (<xref target="parse-innerlist"/>) with input_string.</li>
<li>Return the result of running Parsing an Item (<xref target="parse-item"/>) with input_string.</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>Consume the first character of input_string; if it is not "(", fail parsing.</li>
<li>Let inner_list be an empty array.</li>
<li>
<t>While input_string is not empty:
</t>
<ol spacing="normal" type="1"><li>Discard any leading SP characters from input_string.</li>
<li>
<t>If the first character of input_string is ")":
</t>
<ol spacing="normal" type="1"><li>Consume the first character of input_string.</li>
<li>Let parameters be the result of running Parsing Parameters (<xref target="parse-param"/>) with input_string.</li>
<li>Return the tuple (inner_list, parameters).</li>
</ol>
</li>
<li>Let item be the result of running Parsing an Item (<xref target="parse-item"/>) with input_string.</li>
<li>Append item to inner_list.</li>
<li>If the first character of input_string is not SP or ")", fail parsing.</li>
</ol>
</li>
<li>The end of the Inner List was not found; fail parsing.</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>Let dictionary be an empty, ordered map.</li>
<li>
<t>While input_string is not empty:
</t>
<ol spacing="normal" type="1"><li>Let this_key be the result of running Parsing a Key (<xref target="parse-key"/>) with input_string.</li>
<li>
<t>If the first character of input_string is "=":
</t>
<ol spacing="normal" type="1"><li>Consume the first character of input_string.</li>
<li>Let member be the result of running Parsing an Item or Inner List (<xref target="parse-item-or-list"/>) with input_string.</li>
</ol>
</li>
<li>
<t>Otherwise:
</t>
<ol spacing="normal" type="1"><li>Let value be Boolean true.</li>
<li>Let parameters be the result of running Parsing Parameters (<xref target="parse-param"/>) with input_string.</li>
<li>Let member be the tuple (value, parameters).</li>
</ol>
</li>
<li>If dictionary already contains a key this_key (comparing character for character), overwrite its value with member.</li>
<li>Otherwise, append key this_key with value member to dictionary.</li>
<li>Discard any leading OWS characters from input_string.</li>
<li>If input_string is empty, return dictionary.</li>
<li>Consume the first character of input_string; if it is not ",", fail parsing.</li>
<li>Discard any leading OWS characters from input_string.</li>
<li>If input_string is empty, there is a trailing comma; fail parsing.</li>
</ol>
</li>
<li>No structured data has been found; return dictionary (which is empty).</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>入力文字列としてASCII文字列を受け取り、（bare_item、parameters）のタプルを返します。入力文字列は解析された値を削除するために変更されます。</t>
<ol spacing="normal" type="1"><li>input_stringを使用してBare Itemの解析を実行した結果をbare_itemにします（<xref target="parse-bare-item"/>）。</li>
<li>input_stringを使用してパラメータの解析を実行した結果をparametersにします（<xref target="parse-param"/>）。</li>
<li>タプル（bare_item、parameters）を返します。</li>
</ol>
<section anchor="parse-bare-item">
<name>Parsing a Bare Item</name>
<t>ASCII文字列input_stringを受け取り、解析された値を削除するために変更されます。解析された値を含むbare Itemを返します。</t>
<ol spacing="normal" type="1">
<li>input_stringの最初の文字が「-」またはDIGITの場合、Parsing an Integer or Decimal (<xref target="parse-number"/>)をinput_stringで実行した結果を返します。</li>
<li>input_stringの最初の文字がDQUOTEの場合、Parsing a String (<xref target="parse-string"/>)をinput_stringで実行した結果を返します。</li>
<li>input_stringの最初の文字がALPHAまたは「*」の場合、Parsing a Token (<xref target="parse-token"/>)をinput_stringで実行した結果を返します。</li>
<li>input_stringの最初の文字が「:」の場合、Parsing a Byte Sequence (<xref target="parse-binary"/>)をinput_stringで実行した結果を返します。</li>
<li>input_stringの最初の文字が「?」の場合、Parsing a Boolean (<xref target="parse-boolean"/>)をinput_stringで実行した結果を返します。</li>
<li>input_stringの最初の文字が「@」の場合、Parsing a Date (<xref target="parse-date"/>)をinput_stringで実行した結果を返します。</li>
<li>input_stringの最初の文字が「%」の場合、Parsing a Display String (<xref target="parse-display"/>)をinput_stringで実行した結果を返します。</li>
<li>それ以外の場合、アイテムタイプが認識できないため、解析に失敗します。</li>
</ol>
</section>
<section anchor="parse-param">
<name>Parsing Parameters</name>
<t>入力文字列としてASCII文字列を受け取り、解析された値を削除するために変更されたordered mapを返します。ordered mapの値はbare Itemです。</t>
<ol spacing="normal" type="1"><li>parametersを空の順序付きマップとします。</li>
<li>
<t>input_stringが空でない場合：
</t>
<ol spacing="normal" type="1"><li>input_stringの最初の文字が「;」でない場合、ループを終了します。</li>
<li>input_stringの先頭から「;」文字を消費します。</li>
<li>input_stringから先頭のSP文字を破棄します。</li>
<li>param_keyを、input_stringを使用してキーの解析を実行した結果にします（<xref target="parse-key"/>）。</li>
<li>param_valueを真のブール値にします。</li>
<li>
<t>input_stringの最初の文字が「=」の場合：
</t>
<ol spacing="normal" type="1"><li>input_stringの先頭から「=」文字を消費します。</li>
<li>param_valueを、input_stringを使用してBare Itemの解析を実行した結果にします（<xref target="parse-bare-item"/>）。</li>
</ol>
</li>
<li>parametersがすでにキーparam_keyを含んでいる場合（文字単位で比較）、その値をparam_valueで上書きします。</li>
<li>そうでない場合、parametersにキーparam_keyと値param_valueを追加します。</li>
</ol>
</li>
<li>parametersを返します。</li>
</ol>
<t>パラメータキーの重複が検出された場合、最後のインスタンス以外はすべて無視されることに注意してください。</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>If the first character of input_string is not lcalpha or "*", fail parsing.</li>
<li>Let output_string be an empty string.</li>
<li>
<t>While input_string is not empty:
</t>
<ol spacing="normal" type="1"><li>If the first character of input_string is not one of lcalpha, DIGIT, "_", "-", ".", or "*", return output_string.</li>
<li>Let char be the result of consuming the first character of input_string.</li>
<li>Append char to output_string.</li>
</ol>
</li>
<li>Return output_string.</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>Let type be "integer".</li>
<li>Let sign be 1.</li>
<li>Let input_number be an empty string.</li>
<li>If the first character of input_string is "-", consume it and set sign to -1.</li>
<li>If input_string is empty, there is an empty integer; fail parsing.</li>
<li>If the first character of input_string is not a DIGIT, fail parsing.</li>
<li>
<t>While input_string is not empty:
</t>
<ol spacing="normal" type="1"><li>Let char be the result of consuming the first character of input_string.</li>
<li>If char is a DIGIT, append it to input_number.</li>
<li>
<t>Else, if type is "integer" and char is ".":
</t>
<ol spacing="normal" type="1"><li>If input_number contains more than 12 characters, fail parsing.</li>
<li>Otherwise, append char to input_number and set type to "decimal".</li>
</ol>
</li>
<li>Otherwise, prepend char to input_string, and exit the loop.</li>
<li>If type is "integer" and input_number contains more than 15 characters, fail parsing.</li>
<li>If type is "decimal" and input_number contains more than 16 characters, fail parsing.</li>
</ol>
</li>
<li>
<t>If type is "integer":
</t>
<ol spacing="normal" type="1"><li>Let output_number be an Integer that is the result of parsing input_number as an integer.</li>
</ol>
</li>
<li>
<t>Otherwise:
</t>
<ol spacing="normal" type="1"><li>If the final character of input_number is ".", fail parsing.</li>
<li>If the number of characters after "." in input_number is greater than three, fail parsing.</li>
<li>Let output_number be a Decimal that is the result of parsing input_number as a decimal number.</li>
</ol>
</li>
<li>Let output_number be the product of output_number and sign.</li>
<li>Return output_number.</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>Let output_string be an empty string.</li>
<li>If the first character of input_string is not DQUOTE, fail parsing.</li>
<li>Discard the first character of input_string.</li>
<li>
<t>While input_string is not empty:
</t>
<ol spacing="normal" type="1"><li>Let char be the result of consuming the first character of input_string.</li>
<li>
<t>If char is a backslash ("\"):
</t>
<ol spacing="normal" type="1"><li>If input_string is now empty, fail parsing.</li>
<li>Let next_char be the result of consuming the first character of input_string.</li>
<li>If next_char is not DQUOTE or "\", fail parsing.</li>
<li>Append next_char to output_string.</li>
</ol>
</li>
<li>Else, if char is DQUOTE, return output_string.</li>
<li>Else, if char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.</li>
<li>Else, append char to output_string.</li>
</ol>
</li>
<li>Reached the end of input_string without finding a closing DQUOTE; fail parsing.</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>If the first character of input_string is not ALPHA or "*", fail parsing.</li>
<li>Let output_string be an empty string.</li>
<li>
<t>While input_string is not empty:
</t>
<ol spacing="normal" type="1"><li>If the first character of input_string is not in tchar, ":", or "/", return output_string.</li>
<li>Let char be the result of consuming the first character of input_string.</li>
<li>Append char to output_string.</li>
</ol>
</li>
<li>Return output_string.</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>If the first character of input_string is not ":", fail parsing.</li>
<li>Discard the first character of input_string.</li>
<li>If there is not a ":" character before the end of input_string, fail parsing.</li>
<li>Let b64_content be the result of consuming content of input_string up to but not including the first instance of the character ":".</li>
<li>Consume the ":" character at the beginning of input_string.</li>
<li>If b64_content contains a character not included in ALPHA, DIGIT, "+", "/", and "=", fail parsing.</li>
<li>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.</li>
<li>Return binary_content.</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"/>), parsers SHOULD NOT 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"/>), parsers SHOULD NOT 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, parsers MUST 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>If the first character of input_string is not "?", fail parsing.</li>
<li>Discard the first character of input_string.</li>
<li>If the first character of input_string matches "1", discard the first character, and return true.</li>
<li>If the first character of input_string matches "0", discard the first character, and return false.</li>
<li>No value has matched; fail parsing.</li>
</ol>
</section>
<section anchor="parse-date">
<name>Parsing a Date</name>
<t>ASCII文字列input_stringを受け取り、Dateを返します。input_stringは解析された値を削除するために変更されます。</t>
<ol spacing="normal" type="1">
<li>input_stringの最初の文字が「@」でない場合、解析に失敗します。</li>
<li>input_stringの最初の文字を破棄します。</li>
<li>input_stringを引数として整数または小数の解析を実行した結果をoutput_dateとします。（<xref target="parse-number"/>）</li>
<li>output_dateが小数の場合、解析に失敗します。</li>
<li>output_dateを返します。</li>
</ol>
</section>
<section anchor="parse-display">
<name>Parsing a Display String</name>
<t>入力文字列としてASCII文字列を受け取り、Unicodeコードポイントのシーケンスを返します。入力文字列は解析された値を削除するために変更されます。</t>
<ol spacing="normal" type="1"><li>input_stringの最初の2文字が「%」に続くDQUOTEでない場合、解析に失敗します。</li>
<li>input_stringの最初の2文字を破棄します。</li>
<li>byte_arrayを空のバイト配列にします。</li>
<li>
<t>input_stringが空でない場合：</t>
<ol spacing="normal" type="1">
<li>input_stringの最初の文字をcharとする。</li>
<li>charが範囲%x00-1fまたは%x7f-ff（つまり、VCHARまたはSPではない）場合、解析に失敗します。</li>
<li>
<t>charが「%」の場合：</t>
<ol spacing="normal" type="1">
<li>input_stringから2文字を消費してoctet_hexを取得します。2文字ない場合、解析に失敗します。</li>
<li>octet_hexを大文字小文字を区別せずに16進デコード（<xref section="8" sectionFormat="of" target="RFC4648"/>）した結果をoctetとします。デコードに失敗した場合、解析に失敗します。</li>
<li>octetをbyte_arrayに追加します。</li>
</ol>
</li>
<li>
<t>charがDQUOTEの場合：</t>
<ol spacing="normal" type="1">
<li>byte_arrayをUTF-8文字列としてデコードした結果をunicode_sequenceとします。デコードに失敗した場合、解析に失敗します。</li>
<li>unicode_sequenceを返します。</li>
</ol>
</li>
<li>
<t>charが「%」またはDQUOTEでない場合：</t>
<ol spacing="normal" type="1">
<li>charをASCIIエンコードした結果をbyteとします。</li>
<li>byteをbyte_arrayに追加します。</li>
</ol>
</li>
</ol>
</li>
<li>閉じるDQUOTEが見つからずにinput_stringの終端に到達した場合、解析に失敗します。</li>
</ol>
</section>
</section>
</section>
<section anchor="iana">
<name>IANA Considerations</name>
<t>"Hypertext Transfer Protocol (HTTP) Field Name Registry"に次の注釈を追加してください：</t>
<ul empty="true">
<li>
<t>「Structured Type」列は、フィールドのタイプ（RFC nnnnに従う）を示し、「Dictionary」、「List」または「Item」になる場合があります。</t>
<t>ただし、ALPHAまたは「*」以外の文字で始まるフィールド名は、Structured Fields Tokenとして表現できないため、それに参照するフィールドにマップすることができない場合があり、互換性がない可能性があります。</t>
</li>
</ul>
<t>次に、「Structured Type」という新しい列を追加してください。</t>
<t>次に、<xref target="existing-fields"/>にリストされている既存のレジストリエントリごとに、指定されたStructured Typeを追加してください。</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>Structured Fieldsで定義されたほとんどのタイプのサイズは制限されていません。そのため、非常に大きなフィールドは攻撃ベクトルになる可能性があります（たとえば、リソース消費のため）。ほとんどのHTTP実装は、個々のフィールドのサイズだけでなく、ヘッダーまたはトレーラーセクション全体のサイズも制限して、そのような攻撃を緩和しています。</t>
<t>新しいHTTPフィールドを挿入できる権限を持つパーティは、Structured Fieldの意味を変更することができます。一部の状況では、これにより解析が失敗する可能性がありますが、すべての状況で信頼できる失敗は不可能です。</t>
<t>Display Stringタイプは、任意の形式のサニタイズなしのUnicode文字列を伝達します。これらの値を使用するアプリケーションは、その内容について独自のチェックを実行する必要があります。たとえば、エスケープシーケンスやNULを含む可能性があります。信頼できないコンテンツを表示する前に、エスケープ処理を行うなどの対策が必要です。</t>
</section>
</middle>
<back>
<displayreference target="RFC9113" to="HTTP/2"/>
<references>
<name>References</name>
<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="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>
</references>
<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>
<seriesInfo name="IEEE" value="754-2019"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
<seriesInfo name="ISBN" value="978-1-5044-5924-2"/>
</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="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 the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</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>
<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 modified version of 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"/>
</reference>
</references>
</references>
<?line 1046?>
<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>この仕様の一般的な実装は、トップレベルのserialize (<xref target="text-serialize"/>)およびparse (<xref target="text-parse"/>)関数を公開する必要があります。これらは関数である必要はありません。たとえば、異なるトップレベルタイプのそれぞれにメソッドを持つオブジェクトとして実装することもできます。</t>
<t>相互運用性のために、汎用実装が完全であり、アルゴリズムに厳密に従うことが重要です。詳細については<xref target="strict"/>を参照してください。これを支援するために、コミュニティによって共通のテストスイートが &lt;https://github.com/httpwg/structured-field-tests&gt; で維持されています。</t>
<t>実装者は、DictionaryとParameterが順序を保持するマップであることに注意する必要があります。これらのデータ型の順序に意味がない場合があるかもしれませんが、それでも使用する必要があるアプリケーションに利用可能にするために公開する必要があります。</t>
<t>同様に、実装者はTokenとStringの区別を保持することが重要であることに注意する必要があります。ほとんどのプログラミング言語には、他のタイプにマップするネイティブタイプがあるため、これらのタイプを別々に保持するためにラッパー「token」オブジェクトを作成するか、関数のパラメーターを使用する必要がある場合があります。</t>
<t>シリアル化アルゴリズムは、すべての場合で<xref target="types"/>で定義されたデータ型に厳密に限定されているわけではない方法で定義されています。たとえば、Decimalはより広い入力を受け入れて許可された値に丸めるように設計されています。</t>
<t>実装は、各タイプに定義された最小値に従うことが前提となっているが、異なる構造のサイズを制限することができます。構造が実装の制限を超える場合、その構造は解析またはシリアル化に失敗します。</t>
</section>
<section anchor="abnf">
<name>ABNF</name>
<t>このセクションでは、Structured Fieldsの期待される構文を示すために、拡張バッカス・ナウア形式（ABNF）表記法<xref target="RFC5234"/>を使用しています。</t>
<t>このセクションは非規範的です。解析アルゴリズムとABNFの間に不一致がある場合、指定されたアルゴリズムが優先されます。</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-integer = ["-"] 1*15DIGIT
sf-decimal = ["-"] 1*12DIGIT "." 1*3DIGIT
sf-string = DQUOTE *chr DQUOTE
chr = unescaped / escaped
unescaped = %x20-21 / %x23-5B / %x5D-7E
escaped = "\" ( DQUOTE / "\" )
sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )
sf-binary = ":" *(base64) ":"
base64 = ALPHA / DIGIT / "+" / "/" / "="
sf-boolean = "?" boolean
boolean = "0" / "1"
sf-date = "@" sf-integer
sf-displaystring = "%" DQUOTE *uchr DQUOTE
uchr = chr / uescaped
uescaped = "%" HEXDIG HEXDIG
]]></sourcecode>
</section>
<section anchor="changes">
<name>Changes from RFC 8941</name>
<t>このHTTP仕様の構造化フィールド値の改訂版では、以下の変更が加えられています：</t>
<ul spacing="normal">
<li>Date構造型を追加しました。(<xref target="date"/>)</li>
<li>新しい構造化フィールドの定義にABNFの使用を推奨しないようにしました。(<xref target="specify"/>)</li>
<li>ABNFを情報提供の付録に移動しました。(<xref target="abnf"/>)</li>
<li>HTTPフィールド名レジストリに「構造化タイプ」列を追加しました。(<xref target="iana"/>)</li>
<li>パース失敗処理を改良しました。(<xref target="text-parse"/>)</li>
<li>Display String構造型を追加しました。(<xref target="displaystring"/>)</li>
</ul>
</section>
<section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name>
<t>この仕様書の開発中に、Matthew Kerwin氏が詳細なフィードバックと慎重な検討を行ったことに感謝します。</t>
<t>また、Ian Clelland氏、Roy Fielding氏、Anne van Kesteren氏、Kazuho Oku氏、Evert Pot氏、Julian Reschke氏、Martin Thomson氏、Mike West氏、Jeffrey Yasskin氏にも貢献いただきました。</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA9V9aXfbRrLod/4KXPrkWcolKVGbbSlKIm+xMl40lpy8mckc
H5AEScQgwMEimdF4fvutrVeAEmnLefflzCQiCXRX117V1dXdbrdVxmUSHQbn
ZV4NyyqPRsHzOEpGwS9hUkVFMM7y4MXFxVlrlA3TcAZPjvJwXHbjqBx3p2U5
H8RFtxjjv7d3W6OwhCeun55cPPvUGsKHSZYvDoOiHLXieX4YwCRFubO9/Wh7
pxXmUXgYnMznSQxPxllaBGE6Ct5GYdK9iGdR6yrLP0zyrJofMgQfogV8NToM
TtMyytOo7D5FUFrZoMiSqIyKw+Dho71+q1WUMND7MMlSAGYRFa1iFubl+39V
GT2UZq15fBj8o8yGnQD+FaejKC07QZHlZR6NC/hrMZM/yjwewk/DbDYP5Y8Z
PAw/xWkSp9E/Wy34GJeLw1YQnD97+fwwaL99/iRI4Z92qxVW5TTL4bcu/BzA
OzD9q17wOivLOJ1Mwxl9zXh9FeYf/F+yfBKm8R+EnsPgSZJVo3ECiKMfhzht
cJaH0zxM6Zs8mtCDv5w+4SeyKi2RACeA9jxM4pC+jmZhnBwGszQrf8R/9QCX
9EOVA16QqMXh1tbV1VVP/brlrOCs+6IX/CWczS3oz7Iq6b6I0hSgN7+58F9M
I2CrPI2LafAkHMKnszz7PRqWNlTz6YcfL/mh7hAf6sEgrVaa5TMY5jJCRCM7
HAaA50f9/narFadj+9fTZ8+ePdjfO6RRyzCfRKVZVRxF0cd5kuVRD//EwbeA
tSuk6tbDBwcHOzuP+EWWCxwMhAMYKsxHJA3PkyxEGnXPsjgtg5M8LqezqIyH
9JqmOPzDKPOxgCPSDywsO9v9R93tB/RNEeVxVOByDuVVfPgwgNV08Tn58umb
08Mg6G/3YPWPtvCR84unPXygZ68A3j5//PowePTgYbff3d/e2+vuP9qBkVrw
87uL5w8P7YXCF92HnSAEGQ3TQhCapQH/FWRjGO0NTHqwd1BfKPPF817wtwjQ
HVYyP7OG97Va9vZut99fsmxYz2FwsCufgNCHwe6BIoxFUWHTfDzsRqO4zHKi
J460BTqHBmAu2eWRR3ExT8IFK5StHWSls5MnfyFeAiSD7riM0oq4yNY8MOli
DkD/ChoJ+fsn/A2+nWa4PsVa+N+rCUEAvzE3azXZvZr8eLVLvAy4y4dT814S
F2XR4x+3TuAn4ONi66wagGLcsgfAYfNonplXJ8B71aAHWklmp/90o49llBao
UreScBAlxdY0CkdR3i2Ulm/xm924KKqoSw/BqP5DrVa32w3CASoPkNLWxTQu
AiUtwSgqhnk8ACMRAgmJRYC2IeGKdXlYFKBegd7wZwKmACWlCMop8BMoMWAa
AHMEP5YZoOsDfFEGUVjEUU5vF+EY/oLfRtEYVC19N4V/JRFRRcClrwG+OIG/
x2i6QDl/SLOrFKYP2r5dK9od58sXNAh+C6Jt/3DBQxbtXnBaBrBuDS0qgaqI
gsEiKObRMB5r+wUYSKMrho5B4cVeocaDheBbIdkQEKxikZbhR34Ahp+BSgLq
ssUBDsAfUlwY8DUMHibWsMElGeeeTxFtCZGfyRj2hIazeAR4a7XuofHMsxGs
EgZttc5pAQtk6hL0scBkr0OwvGGheVMtLkYyB2BmQR5gqWHx4SiIQIJgweWU
BpxU8ShMh0jr4Pr6PKJpg/5Bb7e3g9PgFJ8+dfBZWD4yxSxMF0DxYUz8GyD/
wczzuByHSUKfEf9hMM8zxD6hysIMqyVY9hucNZRvEUnERKNOAAw7z4DZ5mEO
iocZFTUQmMc/8HM2BjrD+pkvB1FwBXwLX+GbwxBJGIFZsgkBXEkykMSTaZkA
9PEYOBcJQuyKyIWlXiGhkyz7UARJDPM7bFAjZSxksqVL3iAh00JaaH4EFNMi
4yXMKFyDqwpHI3gTuTOCFwGVgySaFcDpKaIFbFkFXkYH5ZHRhkBMIqBzDC6T
0gfAsqMooelhnBn8AB7XhGmPXJ4Oc+BFjVttTgIwwDg7M12oxgHwCdbra2aK
5fINyDpJ7YUpGRIaB0SOupS3l8h4O9iIx8SuPNwQmBroHsXIlYSF2B+QdEl7
E/FOWBSlpwCAtZRITkc/WKosLgsla7i8ASi9oWGWvEqiQmQClUw8Ax+ZhXSQ
AXLxbUPpmh4ihlWcrQeFp3CcCLmL1RWicaS0S7LoBOMKFxdcwruKgwjJiA+l
gxN0vcnVcglLTyMiPO7gb4HJDMMioyTZFQJlK0lkYYsdWPbIGZmh/I1YQ0Zj
WGYMawA5Q07LqhKeI6xFgn1YF7jRMhgTD9xY5OAsFIBsSYOJ1KueDow+gmXG
oS2FfkTPzKIhIDYuZoW2goBqIBcQHpVYlgJ4tnmDpcD6Riwc9qrRGYUF4XKy
OYl9RtIEi7i+ZrIuQBaMrZ1mVzig/ASr8rmS3iR2pPeU+KbVbAASBMvSFLKs
NcEifE+AwkJqppOUVFZYNOaX5T2tREe8DNLbqGTBZObZrEETVYUyPJZ7YBBK
NqMEZ+bTJ7Rj98h4YbjFDIsAgq3EIGIo6uT6HtvPT6JOXbmInbcVavgNghSH
sM0BvzaIpuFlnOUK3qKM5t3Boov/tQBnziDKR3kOmkaLntYKpHvHoHPoUYQF
eWUe5TwRCFcGri3wESz3VDRaEU9S5qEohXguDycRDlFOx1XiSTTBPskywj/Y
ZBx4ECcQJvYw9oKQFiSogybbe4+oD2jQvDqNkjmOD0qDhYtkrwTnAuSRbFGc
zkHyriDqG4nv5k0JvwHpIYSO0RCzG0RPg1UAjzAgE1CRrAQZrtlXTwiK/gqV
YAw2KdgYwLRoPwHNRTVwzO0mzvkhBGckJWY9VSNj2kBH82juFL+wA2PxRTAG
4AiqcYMGP0J1QsoLVUraBRtH4RHZa8QHYw+ijGEGWhQtEVBkmOU5OCrwCdCJ
hJ+zZQdDGOYAP3nKl1kMKoHVu49JZskhROfwgTx2EdgZOhy8RnAxyX2sktLR
f2QK+XuzJsID8D6mMca2kxTO50ZlLYIZvBUDBdgpgFk3ot6k12EIZxBxhRi4
oVU1Lg+mSsAjTMuCrSDqBRgy3yTGY8mIyWmkURf3C3Gi4kLRFSZnR8uSEtvd
UkIkIiu6AdYcChGfZOklU7RARRAFH6IFM0HQfvXu/AJjAPxv8PoN/f322V/f
nb599pRigxcnL1/qP9QT5y/evHv51Pxl3nzy5tWrZ6+f8svwbeB99erkb+0O
kbD95uzi9M3rk5dt7R9oIxSSeCHzEG7n6DmRH+Now8dPzoL+HijF/wL/fqff
fwQanj887D/Ygw9XU/RTcTLSQ/wRsLggyoaEeeBfQC841GGCphjYYYrBEuqH
mheq3Ztfnrw4edsJzs86wdPTn04vOsHJy7MXJzzX07++e3PxjN0WVvXX1z8A
UPs7uwiUZa3AaqLdEOdkiz3HOGcRAbc8HaFUnpw/OT0F/ivRVxhFyJLkQ6fo
VKI9oJDMuF44KgHy5tdzFwrxJMVFhYhyBlxX5XMwYs1rtcNUA/YKtqEX/ArI
1k96Bg8FzdNuxH/wcqTH0G5sDOslx6OCuDEE15yHG2fKbXItJqzkObztAgbQ
O9PXjKz2d0A3UVITxf4qJOkTBcWOSHDqQ37yNxDEfMFQEV5ZSaKGU2spsoCi
gZBpBG4a6kdSPjEyIOtE4FGO6I1uVKhWsDb5A11yK8QrCJ6SKwzvvIZwp+a0
oE8gbhRQ3HKcnAiC1KT/boc8bY4oCxURHrZa34KukXwjLADMKmo+QpdvMHrB
W/g0j0kdknXGICoss1z7yzy/CjcxcSHmmEjzrwqUH2Wc644rp1DQIwZM9hCs
U0xk4+JA8MnwmQlib4EvJKyPe1GPQpwhRfLJwvYA8XWJwgoJ3SH+xm8lFB2G
RYSKPagHVcGGOMEso/KlDLNJ6ZY6xsG8gzXbpMVIakJHVy7CyBIcSYwWvAR5
CTaurzGV9ukTjP40pnmQS+Hrkf5EP8LUp2U0w18gUJrBdzThUysGiNCox8Oi
YVIHOExWhDqIQv2EnnGM9KrmWeq/S/r2KgIBELnAF4DIyD4FqWv4Fj1seyCk
M8hUgnk01FqLOXAXBWzED7MoTFVSTeaygsMrlLbCRmU27ybRJUZYiFSgJyLP
xphBkCRfSoTLilzJAyK9ZFJ9TSsH3fGcwv0QNQiyiTCTE6cT7diTIXWI9gn9
/Ak8OIswaCmEW2YxhWU06VHzaCkDzsMRnMzUGCqkk4LtVWhFvfxzwT8D709i
3sLQGawkguAzD9p/5RShehL4GgaPcpSAHqzhQ4QeWAcgT4UfC+Iv/NgVtjSh
ITBDPGJ6N9DMignF2ZSI8Ln3ZGGklt2lWsijLF/di+pIUDzPcokBQItl457K
CeqkJk5BOo4SR0pfoSXlNEthZFgIgj+i62P9ouRffsI8jPWrGbNNg87BAM1z
TBzbqCU/xkCDnGh7hcugoV+XgKN+a4SHf8Rx0wgDBhCNXmNcqSLJGZBlVs0K
jfUkSifARvDJRN9gOWPMlloJvKKaIxXYCPpJGnR1RlnEOQwlyLPwI84EUdEf
EfHiLCtK0sbA4hghKaMFvh3GXKDTwyvyMVFNkN3z/ZERRVuoexSECYRcaHfE
i4epOPAbxZfxqMJYyfItSvC+E2uZ6jfj5ukRLH4UEuEDroHokUv/jDVHq3UC
48H3JcH1PMu68osagAnGUj+w/ZGwAHv93SDJhh9o+/f71nfl93s7PWcQsYUk
Xd9tld+38CEMG5yHrGS4pAkxylgg+s1uWTjAhBQ41K1ZNZziAJIvAvaZUKK4
p2ewR4+N7qobaRb7f4BHjdvK/0SWkKCpRV4kUjfVOnNDZdl3e7u9PiJcv7lp
JtdDEEFxq54NUjjDPWN8C2EX6y3gs/YEXwFnbQ3Qcy2vItBh2/RDfxsjw2FS
FeAYHUnoLZkegpOCulad/JLE5fBnkmaw9J5DB+P5guMHWgIVskn3HsqzVQLU
TeLvT6ynrsiaYvgHz7fHWVbliYRj/JOOPUOxEa3AxeCui8GOkF254Yild29f
wltK6AVZveA8QgyhCcKfrKyD7dbBQgHk1ndbCD2uVwFJsQ7YU4Ts3dvTrnEz
NXh7hry7jx4eAHmD03ErLq2ImnU8mxtnlE6DGBIdNEspSsCYgTMm5hMSTgE3
ArXTcoDqKI7BQUHdZcklsLZ+ft9dAjyEWaoWp53QEbUFRjsTiuZhXmLO53vA
vyVOh8HOUcB4PG6rvVL43JO3acO0DUjXr3+3ZesI0j2UqXghObxWyw3vQFkV
nbplxeCN0RZsFEB+N1wB+jRacCQS5ovyeMRG3Gw1jTLKOGaSO5tD0JRUo8hJ
68vGDDw1LlHJHxlLSa4BuDvLfNSNse2fiaYHJU7j5WE6IYUtmoUdvaegWmeh
Wr2pDhAPi565yD5EqTIM7CKiAHNQEVqupkr+sIcnk4sFQWVY8AvoTqGPTjQg
THeVBV7qKTdTBwDPFIk6QZUmsgtWd8KUUWc1ZvZmbNl13VtKpTkqzduSEgWP
GJJhlNYz6lvMt6ATRwCSRyBrFI1a9lzxmV4DkIFmvV8s8SWVVSxMxlBSZ2cg
llF+iRM+49IBzjyCL1gLpxHHdlYaN8rkHUSC3iP9OMeqDlQNU51j4h0P2iBG
Spq9GRR5kJdUbbapPVhxu6hAIBtxwEXMHPA2iRWKWNtpTvSms5spb0qWORgT
9PHCYsqOxmNMujK34du2B88RxJkyJ4WQMbKRZDaDjmoBGWe3xAaiQCJr5hpn
kmkNhxROY2EMJ9otj4LYirIDAzApFxnlzYFWJHpXWJNEtWmlANOR1XqFCUQ0
zErT/oHsx4xU3oRz0jAsUgtRlgJXYVpoktJujjGnsnxSjUPM1omv9nzZpB6f
S7guktCR0BMGs+L10lqjg+ieYkFmIwAijcAf1Fs5ImQssBTcSrpaRIvjr7Ao
QL8pgJjskgXhRKlHctQ7gPZxlTPovGkh1AVqu7yAKuYSjAOxpHhPvK3KToez
jYOqC3Vt4dSGzLGCQ6oTPC+90xQtIluZAB/Aak/yCCKBtqFbQTpmNOIIg/Px
oL1OvDhmSLqlKON5hXwqOYUksQcSPYMqSmEduA83hYXeRLiReENxwetSSQSz
doxohQYFla7AIjLMzko4CmyIvBNhaVRAMRfuSRGmDCOjblTZNWJp3Pmm7KHC
H4GrwycUNPRuEThD4XrIq/ejNVvGIr9kP5hFcJBGGUQcM9/rCgdfwjCxYhJB
Er8ikpBrraopykLAw1XKFU0fMN6wfbPzasD5o9KXPoSWcO6ZfxyioxgGAbQN
qORt/CCc6i10URnnAWqpOz2hyLywT9q0g2PZr8GCHEqho6CeGBSLLtk4m6nj
cQO8yjW1qlVgPiQ4EJgjyXdFQ4L4glwTkNJnul4OrIEYsAZJQzVccL2AcntD
jXYquUKeqJlMxw/SysGq2jHeNcJNYXckFg5DFKeoBLADE9USawzrlXmeIdaA
Fl7uGInF2Ta1pyYszwh/SuJPKvT6Gu0S5U2vMEVEaZbbp1MFaOLfGscgLjkn
ScUdUSjbXHHKMcqGqAreqyZRB/mKRpsNqRHOJYQe56sUDaFR7auj0GKhOVc/
SZ2LqZK0MltHwbgJs36FEQmmlfnP/AUHav9So9KggBSdpbo4b8EbI5R9570m
M6RSZpmKIgGLsM4X4FJfosvo0tYrG8A4PRx+QD1VdJWiAgakJagpjjyVqVFd
1DciqFRPK0N6SyLMurfos0hhIc2qUXw3n2ChI2nu+iB+tUKmMmZY1hJdAcx5
dEn1giq95Nq1jQJzMaEnA8BSHLGQcs4KbcOZp5BGbtkclTBE5J7xctGc5AS1
eKO4n4/Vq7gylYwa4kBWvlcoSKl8R4iVm4p6D7DD70sSAPUM+rdgjSj1LwMS
b9kSSr41FkVNpksjAscaKrcTR0KPgJiOeM5DOsef9rZ7wFj14DZczt6UKGJf
h3m7ZKdjj+1kUsR2RbyhFKKffO1ocBhC3D8DwIYRZS7EqZDEKHMylkLg84Q8
Vn5KIeXR77pQwwszk2yCtY8YnAk/xKlTyEW5fV2JYbIAwnrGhBlnalOIjAjC
shH4kmYXHehkNQtt6HmLDogXzdXDNk+17tkS9BRLvNjOXd/jojCVwpb8izKZ
Tu0eG6sl1oxCrGo2A6/oD1WQRmIuJi6vl4JhFqRySpilPofHWdCm6oWuAS6n
eeTvVCk0O9u2Unlm/P9DDtw6jufGIJOrT5t3EtthMsP273BmkTcgzpEEb7IF
pabigAE3yOyNnqtpjGTO2a8touSSxsvDRaFTGbzJeEOwKTNox5TQR1oafLYt
5tR5GJPDij4Nv3V9j3aXWi1ZFaFQTfxHlGcILEWVejON6pepIhmhlmlVdsJs
itKmW2qBWNvQ6nDBkj+UuwJ4iViet1nRkZzNQcvSgGSqgP1Z5GiHQzhHxaWy
PU9xiAQCVA4b2SkPJ83CeBDnBr4PsfSJ51T7t5RHsniUfJo6jwqmGG9UuxDh
SkrltaL6DLnaZi7eNeABFOk8HEY3umg6l1rfCQVkcvpMwjGsGKfCKJCR//zn
P3T0oys55pbkO7v45iEI0wSrtsso7AR5NcPH7VIww2WEHJe9C8ApmoQcDKGp
+0o4BTY21TNLd2xoa3sOn02Z/z4nz7kIx3OsSietj1yLLgbgBTTcZ64UCLHG
i94PehTtVFkbXQpJlE4iKomTh9FrOKZaRMKf2hAhvB0F9RQwIQEUPeaPgRHP
5AwCpceVUyN0Yk1E2CmDBPzuMuhv7+wpYFQuuSHs0xGSHXjgHn2I3kpITo67
k0drErvGlQkqhJUU4T1HU13fs9QAybSlJHgri3RQTQVJusXUXbA+RDAtaIx6
xB/soUtQreNV1Iwv4eRCNUm4k+2j1KZWR0WVUymp7DsBY07BrRZr4mT2+EUV
uA0WVN2o1kzagLItq2sAGyort762RtjA3aR20B6EeRu09Qb88Yf6o4TvAU76
uOnrCtq9RpZTyi9V2S57v5K1qgEW9bubAV93sWTu7HxrySaG/IDPRgBEN8f9
o8HxzuZRcpkc7zMCckIM4IO+7DMKGiXSsdINcrmzf/BVxNJifaWClkinhbLr
eywHtBaNx5wsPIQrVJY8C+c4FfgVXcuvMI6sn4Jqdg5u8Ayo4JzTVThelcb/
qjjkVEXBw8yUdJ3Z+UVYXDYcVrk8rcXNFrYB1b7VcreW82UU9NxWE0onm7qv
WnUjEh4c6kvcjEMvu6D0gAUiMSSmI9JRJOd3FrjUXuClEbFQkvZCOOvN+wJo
Q4ZDffyJ6nqM3M1dkgm9OuoshaThCa+yQhUhAqtyNZJULBXraMHQrM/1cyir
ivkpIr9Lc3J8aGU2chZ0Xm0WD7MEIzt7z/ZWaQ0HwyOR1KNgOIre7+0fgKxO
pvHR7x+O94Jk8+hfx+1H7aP8+EqLq5rZUzWPswyEM1X7sAP+iJwLEU3EZM5A
YTPeJQ508eW5cMiD7dBKq3MmBE915FhPBb5fwjmf9qDtViqMw6S4cf2yRXEY
YCbmKBgc/7BdV8m0GagTMbRPllIFm1v7e2SONqL5obSSvQ/j196yOkKkWFhA
Z5BKxmULVi9nmdfiKEOLjelYSgP7qDiS3/Z4m5WOGvFgzyocX1nBkux4CtXA
5VdiamN+X2lmjeyRxFtOsHh9zyoqbbVqgaSlaYsGVSvJVAJUa8liiqhQ8llY
G+qe+vPdKIrU3Ghz7dBMwm95rjlwNI6Pr9mbtLq9p+dr9dUVr4PZu1W92maD
2yI8J9kD7dtYayDp400c5eXhwUQ1lr3LsVqg6qzsxnjVKvkNmzZ4OYFln2G0
d8BdDC7svR+9hR7x3tNGsUkRSkPsw/X5QnpHeqxi8zg321xGW42Qk1SI7JTE
E805V6Yn0iVbisEUynDDhPfB6pUb9/2aTP2JjvrFhVtIu3IC4JVyuyyRxnIG
61UqOGjICxA/NSYGeNBbrLit8f5CyEhHtg5w5mwft4MNdRzWTLW5sv1FHjkE
Hj5uY0OeCMjT7gSj8Pjwau/v8eCnX7avDv6+GP307vjQN0teZCCRPfqzBBU6
/Xxki4M8Kg/kRH0YPF7AKOdS/65cs0HMhfpAplcOS3xF006qj5QLmm46rDVs
cz4vr1ZAXAj2GjRuJxhS3dkx+Kf/D8y3wstSM25pM91B4sT+Vs7uS9DnV0g6
Yb7OU92OnZz65Rz3exB4jaMI66iK443fM1BF4QiPIUr42QgK1/w3Zkw7nN2n
J41lX4VaG/1gB7OXx7tAsuO9ozA8HgD1Rscb+8HB5hHtrvgErNUCfI0s2h1l
yXidyIn9DgZLxzurpMist7zvrCFuzY9ZNPyaWTKXHMuSZV7mnDjoq3qY1uqN
27Sup8ncfn2P3DvOr6H/bGXqVa03ht30J2XjQ1WdSZuC/Kf8IPWE8D37lfI1
iTB+W+If8qWjlvFHpZL5V6V9bc0rJ3S8DUk6vGBKDUxSwYoP3Lxd83mh5j14
UzqJyFG/WtjhnbOVskU6/tpnLs/yddSKedtT/5I5lfJZTJsysXDvS74Ux08X
23YfPXrU8f6PS236WlfbqyxINaf6hnhconyN4klMWpJqAYBGKFbU0OzB/p5X
s3R9LW3TyPCu6DXode+JctCrSrBJF9USpEF/XyDRjSL0eRcKLfG8ScS5rysI
YTwVOFiogohlPHwTu3KrIB1cSjAq/MHprmHJZZ0QvIQJF3cPS2oh9CsF9FyR
ygUCCXky2o0wpCVmAVmgZDEGT/qsfHt7e3sHjx91t/vtTXYXuTaDYqwN+B5T
sCU1SeFzv0NWOLNwobaG57qurrGNizFS5HqSrTdF27l9oNPs/ILLjD2U5EQa
4jwH+KXnwJG7fc/lBqL2rijOoQJVlX5UReEYFovagZhYfUmjVOLKSTpRJIHr
eYMxql5Vni79AziFqJ7TX3OzpZJPPPV3hLW4+UbTMM7zvLHMryzVNjflrJV+
XSMRLa+AkPREudzOVxp1t/BVb184q7e7u0dshO5E/dn93s7uNj/a2yN+q/Gh
PAkP3CU/cjBqH0w3B7tRjqO8a+xUwJ07VG8RXDr3HaFOaBbpUFXgUQiu+VFl
to08dErlzHbbIr2ng5YcmGuhCqZyPjQQ26fmrJPtC2s/2iqnAbpxYoMPrrir
VfKhNnC4Pw1oLqqs5/RO7mVb5vB9SSWC3AeBGzwAsbfBMbIaKJjEtxiPbz7u
bCM433x88GyTmoy6dcp0cgTbtA3AJqTRFblfHdx+AIipmLascjy2EZVDImLa
ZQjsrg2qnieWGMTR5fqUrVMDpOopzdGOWocTbmrCXNntSpek6AqBjubMfdj4
zS7HGmUEiCk2NYG9nCvQpwe4YZzXQYSPcVEbF1llRm1gyIviNpGWwZHGkdru
aFOm+GOdbLtNerNtSIseZRVSnlvVdrTlwwK+IgmLKdiL334DM4J15GCv5pH7
hnQTk4ejYuX4n0E6DNpTcFTxtFGejNp+BKTg1geOpfEHaUa1kPwIW/5MDEhC
KPldDQKQcUX9jHoS0ZBqOAy/YZW6DxstdKROFNrcOKaj2fisOWCoC8KkTcyy
AEKtZoNHkbaDGaqGTS88oFDCChBEqqVO4/oeO894ToC+qOdyufcMIZGOmGsz
GCbzaTjA7rFmfDqN/G27I5Ef6x5SEdQnM8UjEui1G4A6gVOAxDEmRRvUrcuM
QpsT9HY7OHn8+jl1S7GL81TLlE4wTyrOr7UPJSOy1XZxsCJrEVIorOzv7G7t
7R/csNEqCHSxvw9Wvo58x+tDIojX12p5vwgXsbwv72y2xl6Z63CS9XCEmLa+
WBbxwAPWLrIgD8IiglAT9Alo9L2DvYegC9SxST4euBpKEQA1/2FwOHzxczL6
6Zfq708eb4c/JX+c0v9/ng9mzxfR+ePfBzv723//dX/75eRY5e8ase8hzpOB
g92He2DqyqhUgqfERZOEw0EihkSGeLrKSkp9FWrIBNI4Z2jtWmvPqf2DxbuO
XIVBu98WC2HtgaEIbvP3tHe3OmkYmsPgh35DpvSGtiTELmYX1gqL9RFJtVKC
01muvxmhNg7YOafD3eCZY1AObrmue12ZGjyC2qLAklLp0Sgxt2rOBvpJhR0d
s1nCJmxDPF0wudGEPLFNlBsYK0ZK42kyOcTzc5hWiKF+J+g/erAdbG8f0v+C
dxdPOuLH4JiAi7l681Z11AWHx7jk1IL6x/7B/qP9Bw93dneZVIQsx/TzPp9t
+nGrz32CtL1BgPaBVKkz+0CgECRr6jh7tg7H2mLrCNq7NEbdYfySKqW+scqA
NkNS61Icc5eeQjYcQyuw4dcjOZWGSsre5ZMjGOT1S3cidBUbXCbVIdnrfmYt
3+opVMQgw+zSKYga4npEUC03JSXedJYNtBQQ0XiaClsY7VlH7QnvI2mwqOMh
aiavfPRNt79e8xvTbJZN8nCOCrFE/2qTV6faVs/4tAo2J8XtO8CVJOd1tr7n
5pJdyomPpARayq/SSYV+ud2NSdoe2e06R1hspnaDsOPS2HJ9BXxRhzoRsrmm
vDC4ykn8ps3bm15PbOEnCkGe7H7z+AmyU0+8yHNK8iosS4rXOpa2DP+0i6FP
X3t4Qw3XuqfbstMqG46PqMbC96iX6JL6d9VXVcfgun1p85B1Y6R353RdDFl/
qdxzz93QKTvdTVHa0QfkF2C3esCPhJP4IjVLzsRppIb16KfhfzlpigGmVTbd
1AKNsut6bYCDn+JLaj6k29Dc3Lu4I9Eh+qws+yyq4DvEpX+eza3RV7aoL8c8
rFbA3E3CMoqZVVrk9Jzg/XDTrQzFPM1Uin2zoyTIkM8vHlcv08bgQFWd8ikP
7maUSuMfrtMAxO4ug5jrVxLsyk197d4LMgaqo55qt5lX3E3KJk+oK+YKqzWU
7jelp+q1dnrBs6TgzgI34u0LYHE9EsrHOF5JE1x7N8KlznZ/Lkim1BChURUu
TXDsKzjoWJKXeDnAQgNiWRcI8nUkYUFNik2psnScZF+duVxJsJOF0VmdOlWv
7xWmLlpkzJphgxn2vXTgso8CldU84c0gSn+9T4jH7kLqXmpCyH4JCxMPRVxG
pgCPOtwAn+r5S4DRbRos0PYbdu13R5rJrkhyp5SUCI/fONJxE/IyWWEPAYMV
vVEnsdYEYxnnrTw36wyrbOq9WIUc77ehZKWHRsbkCUPZ7rS9AXk98nOocivn
Z/Zjux6vk03wGdRBMvOpwfEXMCsMIczqFKnSr/j9e7vo7u75WXQCRXkb7fXY
WYGu2PnkT2WVHcMqDTxiofU22ive2XR4Z2+N9Zw5+7G4JAK70IvyCGnPs78C
8znl6dbwFtup6irLIGldaG8X20eysNes6vYQzt5jmy/eT+LPbMfvgOm2b1Wi
fYvrDDDidktKYWyDZRSBvcXs6oIjXxfsrMOiWDWmqAnAaFIa8NzB94gdHRD5
nLCddmjQWMc3aqxVAB2omlYFLn7hCpUNljXbTp33GjQfYYL5DhFhnF9iGMVk
8OFuWOUJexhmWPE0AtXpFTHh76wcSWsLuXxDdRhr8mzY7prRdaM4KzPO0WSQ
DCnBrJt2t397T7uA+K+e9L38jVLNDfPsaPd3HOd45s0kqO3phUtkqpuH3L1V
kIzWMjPcrGwaXDFLhzDZnVrtlVTOyPKLG1WOaHmjc8gmGllfbgbuQiOt59ZZ
sPoq6QZrpTWUwcX6hnKZFuJp7xc2bI3m0XMvm5TRWhDdauqarRy7dtqtbJi6
UREuWcX/Aic58Fb0ZzvKe76jXHeRPb5byVf+THe5rkRkjeIocyGe1hzcx68g
y/U+Vk393D5x+PVX9n2bhH4N0Xx8u901C2x0Oe9A3Dw0eR7sKtbdLIOJZVbR
QDHmrJgyFHeU0jJDuvWHeoIVhVuXdLJkq7JOQZOeRBlmb1pVM7TOrHa5qFeK
U5t0t3FSTsSuNaeV7efLJiXjX5txr3FG2hVYa0K9j4Dzmb0Ef7r9xumcPdG1
pq2VJRJvxk5izZ7/oHl+tnfrzWwqdGlOcz6iNumDZlairZV1+EjqfomJuPa3
PtfD5rmclP56s9bKdNjXo28bQXjkGLwmD7XZEohsqqyJKuI12kVVM2oF46mA
LwooDNZkGtXY2ZRRyvbQl1URLw03brc6TSCqvrQpX9qFEOOuHV7ttxlsa38D
opFm4+IMCJ6i6kvMXpR9Fg9Wj6UVQX9bkrdUTiTaTNUM3m5YlihHCSF0XauK
HtX4UtdmQgdPEd+NfVGz6abe7vQ3hXDuALh14pdVYiUo7fXgtb4aXcRRfMUY
x4FqiDnefN3hSkrcjaFnqTxTPZBgz4uOqbU0h8JoeDV6GoV45a26kSLLdSc1
RLG4y2Mp6MNKPyxIBSBdc9S8sv7ODctKonHzqqS0RQHejNa9W0Viv5lynycS
B55IyID3i4bq6CVisbFULiy//MjgGosUDDjbbbIUyu/uOdA9rC/1ftFcit0w
sD3So2XhSAMdsxWn/BJ8gO7bXklTiAFiRaELRZSekF+1fihcS3eHuSYZ4eul
m8weWi3j5Figbz5ub3f7YxTobz4+GHfHY7X9Kokpuk8Ofz4/21yqupYm+rlQ
lJSAznGY7BRdB6eDSH7F2rDinwsuG8XW0zRYQ2ITf1+Wf6VBGpPtUsS6ds6K
vVRmIVVPqjiIf9MMVDou8B3yD9eVfg32uTGLKNOyYaN7BU0WUa4F4NQALk81
iLauxzBDCnfRjYAdrFzlFOfW8gznLXrc90YY1LVdCTcWkDA1dvOR3kOa2rIr
faeOJI1pXAmb1DLdZ3uCSnoOl3h1rmPPFbFdvc1ug6f7yTUVy3aCMqSiH9XT
W4y506mWbl+xhdODqkEyL6iVAxftUqWj3caATxzOuZM6BRft43bnBkB3eztU
LmAusXLGlrtEqbASRg0GdC94RO6RGMobht5HLEgjBHOVgn2gaJTh1SFy/t7r
rWq10V7CsxJFCrfqgl7NrvK7YVQvVL0jVjXlvcysepovZtEffBZtmpR7+yiH
pe9vsTa9QhXDy5ycFXcwMKCWwIPLdhXa6RcTa9iR+h1ucLZ/bBMyldAq+NfL
ZVnx98jKEJjc1tIdvJsjfbWpw4G+Vcxm6TFTPjuKyLO3amsKP59zN6xaWEcC
6oq1DlDHu8ZYmBe133uuwqhVTGEXc+rc8u7iefehXZ4EXzzky3ZdYLSVE81j
FWOFgevPUQ3FN22nPr7J1UIAyZnWgFruFf9Y4Gm0/WADhgP/Dv7eCTZ4KD6U
a3uLRYO72OCOfdNWt2eYVVj7zfYSCYbluEOj0z8wyNswLUsf4oP/JcqWOopk
tCI1kbFjzlzNgLl1SHRaImL88D0qnlfF+4g1K9kwdpO36T9j9Iz/C1/5I4ek
lhaLcisGOYkRyi1EZKJdO0LPFXZn50C3EeRLK9hqNjSSZqOFtw7mGNSrquac
aReSk8s9E6QvtH2GMBpNpLG3qYaWGwb804XIt5d0nkRqjOd5BsI9UzeLqFJg
c0ES90VSB1WpuFku4uo1VUppf8V2XwgqHX7SkEM8j5XqjkVWtalqIa1LXWPp
iK4vkiLbzmNtmlrV93xJA/UbHQdts2OGO/y4MSgeMKY/25tOdpUIN7otJBBP
UUolHSVpx1c3BQS2fnvKFzrQaTt1OOf8zI4jueOgNbTKYlnrxehNFpfUYsS6
dVK8bipvae1u7a075W7TlA5215vYLbPl6RsKbV0g9pqAIEquOb3Zr+WZnS0+
d879z6TRQT1LIExL/OyzwgNHNeaeB0A6R67K9qKCju6OxCc+s9kAm55hgTdz
MjfbUf3osLBbifdGrevOplIdiJO0wAb9cqn3LIQY0qohpwpxkgIUNeqy0LW6
ZBpBbmyDvWO3wabier5GytwS1nRJTlyYxv7OOZLnme5Y7PWwl/PrU7ldmq8G
x8lN0ygQUjxikjJmEW/2Fdf3i0COhWP1ZqbSVk2dfqjtlG7RT/GMKQRX58Sb
GyK5V0YU3OmhdvM7X0DApfrmEkE8v+4cm4KX+Kr6Qi7NaKnTRnTKm/nD5g1s
gYd9o+p9C9RxnJug5jGo4R7FbVUKWhlFmfxFFkLrBLzdCVqac2ws6wy3qS6i
oDtDAB86qhWJUgK/MAo87wXnhACLrsBz+ipcOh00oOvuq3mBN+7M2EDOAGg6
OmB0hzneTxcwscniG/M0IOp8Ra4yMwxFx7rWT3cOIdItHyqURdKtynJjpDk+
aO6ZRCavn+lVjaVuJZXViwBZjmv/hRSE71tPjZ/8jbWXfX8Lq3VbXIs59k+5
CZQOjyDGmg9nM4z6ThY+cBTaPSNrFwkoSPWpqDAN3HP8VsOk+/4VlMW4a/Sz
7v2YNa+QtIk0nGRttlITgXGW1b7EftvSJGjs36MqXTqX6EHvQlrd+MK6PcrS
YHxpjOUtaVvAC5CmQKYhSLIQ7pSb98iTVRc2q7mtyYApsflNpLt8yjE4Fme5
TH5YSsolzy4bPFI6cRiOIzSM2pfzG47pW+jqPrqSU4t+SUa+pd9msHdjD0Jz
FxDGRgE7ef51S3LIV7Gn2c5ruC4rdZSLes1OoCF25ig60qiGl04eRajRLoff
5Ho9YladGfC8OWp3rpw5yzl3XNUb9l7McQeqRMry93btff3QQ6/m5NDNpDGv
DvCacVdA5V97xVu6naqVmiIQyM2VzkDLvKiVyi99r6/WqN34gN0sX+4EU7cJ
1SCXo9kmz/DNr+e3uIb6VIy/LvEMhRb2XHsUhuDlmDfvHFjBh8mAtjtt392E
IZc4tiuB3+zcCvil6gIemu5LZF6OPCB2sSeP8ZEkB4y+2gC7tY1xy/nIw4Yf
F27qGribyaykwqHyutJBHh5VNd8mG6qddf0x3cRFbn5VFZm6g7/cMmTEUJcc
3rH03bYLZYZsb7RvqUOykd8kW7Wy3FpA+3bV4VcN3BrYooEdmg58rc0Lt/CA
ob13FcxXI+0X6IqNmq6QXKK1jAZdvbuyrv6saFoXjq/KsZttK2O6Bjq8BKpV
h3trVsGt7GX+0i1LGhhUT/R2VY5SpoPIgXJwp5kONjNqd1dKnA0kymisTgQk
PVAW022bNa7a4yAX55L4xxLPq1Bdg04mwH3T93qcwy21TNJneED2pTBW70P2
Mv8cr8g6bWMJW8cGbR3/CIdEX5dOlayQnZMzKoxM+5TKF0rlcds+J/IZYqnk
Ug4frcz/n+vzLT3nIkjVtzfbx3D+dB2y24QUUSX1cyfWaROLzcIEo/WFXUZC
R5AU12xQxw7eHbMaR1nt5zCQvAQs5TFueOlmFdbpJqVC6kVtzlT0Br8sS6JL
zhWoygP9bO/1wQrOtzfdw7v3vx99wQq2/3z/2z7/V3fBTUhNGZMR8B437rGU
s77Bgi69x6iYLnLCBF9lXbCmL/wlh1judfd0vj6LZBm1tRX9ze7XFypwc05o
BXXrnDviJdVPHtU85q+tW3abPJNmlNW9becQkr+k9UmlT0T/KfFOSAXH3MCd
zwmvHvxwoQeWUZqjRLx+3qpdTs914ONt7lXhsg6EMCiNh4zcrb5VQUn9AsUV
QdKHkBiipmNI7rbfqj7G4eow1E4kCaM2nUlyC9lXBeaHNYAxh5QEjMZjSu7+
4qpw/Lg6HOroknjS9cNLCoIHa0HwzRoQ1I4xKa++6SCTAueh41fQ5gbFMLJP
XKV5NMwmKV966EUUju6y9KRSXawm7zqU0ErtS6MF1wp8cbSwXoTXPmpjE8pY
THiWzVVgYHtM2LvD8hvRq8Gvqfkvkb/J4d/9/GzBnoWZu4969u3Rl8cA68no
8bKUBR6kt4qiyhUw50UfBsav4Ipoj9piwyXRhCHHl4UT1qKUe94cU5gJraDC
RgmIlwHb9nnsb5e7t/qpL/du73mcqHSP06FlZYeJ7gD8E1yl5Z1O/PxhrfVd
09mCr6KhZH955d4vTvWNl+zAldBZl5osDUliY70ZeHs+Y3fJ6Rnb8Wlq2VdL
gTX6nYp/xO38DONVH/RzWeo1Hiji3WFTRTjnQkkqitCXszgXOHE5j7r6w7/C
CX6TGxpkvzoHYswzfZeF6oqorCR5AljKLRO0NWvicTr8pa8b8vAypbhySVue
NVQ78thQNHrM3TwLNS8grtt3D0jeENIrOGQNviezlsXhkmyRhlo52hqpxbsS
iB3nPJoGLVQpaVPMzZRRUmSab+qiQCExoVofcOvZFlZjW6isTZVzYtYurKql
cGolzaErzs74iugEI/zYFmZuK3/FGmeeRw0DKQmlPvo1h0sCk0YM3LrQ/ZsX
euCOrSBfbeyDG8Z+2Ay0zVyi+hxZdC6siguP8VRRhov+wmoP4B6trVkVOjFb
51QZiTmpAUsmhjdV2fXLOXrtQJ/FNCNOqJ5GLgijs+MNE+wuw4hW+msixDsz
33PPvVgzkE7Ps1HF1ZPu7+rqJCpodg2WGtffszlX51acfMRn2KgqpVtVRjLi
FwZSt/soa+VpUFmqTE0t9aoim5WU497/Cn3s37rTpE1t0K6aa52d+CSNPpbv
7wpgXVljRnXIwD7eb03C6+x+mtfrTplnctQkXkau/tJew0srnhE3WwnNJ8W9
sp5nSYMt8gCi0zDhcBqNpMpwVGNgdX3yOGaXKgyGSUbyy2u9bV9WHeC2E3zr
BzI0yp8Wyni5zP9lgcySk9z/38UrtePfTt51fR5xhvvTeIVoUOOQtdS6TrXn
1hlJPJNt3pHKzyVC2lBVQbtPB3vv5S6SmwivHvEXyLemqoYs1A5p5DKKTmNI
7YaBF6An7eIksA7XS2Cxu2kv4obmBnSLH/UyIeE14f1/Y2CP8hFyM8qGGIdw
RVy3HF1yIl/d7SSN7/k4pA1jJygWKbxa8BldPBRPzOLcPpJmpRrfOpYfDlDP
4v2N85hhwK6qeNYDz+tvMjb4qiwNhlSKK9duzFdDP9QS6C4L+PuxlP03HfUw
61T3RvDRkjz6Xc7s4AFD+6S+UwRNpdzJghKV0gxArqJvbgCwaQ4tyYl/vCnH
FNyrcSxhk9p1fb6/5IsU1akHWOY4nlRSUk3H/L/OkvmejbRLlxbpFgXLV7t/
+2rrw4V59HkLvqjdU2Iq2vMoCT/WeY/uuPMBLwDyPsnNbm+Xz2jJ9UfecTNa
RWZfvYeqH++rYRlnBKtL/WjEjO85x4vv+eIYG8kNpkJ3XXB3xT7DSvCbf559
+OHu7MOtc9L5PKB0uw+TjpbPYefNZKNi9VSWnmR7jUn4ujg0Ca8zScBTXzIa
6/biPu77YG1Grk94HOPPo/qPd0F1y8+kRhErFbp9bu0BM4A9nds/1V2N36+D
3miqyvQ6VLh7uOtT8ebWEZ9L322PvuVV5igzj8jqnFFzV4gbznevOoOOMtym
FzrE4G4J69Zcf72kwFeIYHfdrmTftL2aS7py8/00+njjalws1zeJjeOtaOq+
cmPSgkCoT48waQfNgHlDOw267CysHbiGuYsp9u+hIk3P5WuCy4RmDJp06Xgv
nKILPt1shYfYiqXKtG2pLVCDYnEn5RG5+4pwoOq90gueW6CiJ+wupV4C70PQ
UDBqZU+UIDb1rFMidEPXE+9Cq5KpX7+xQzU0sRG691XSJ8HpyesTipysC/+u
78VhGoLCPMN7Z/GqR9EmpH5wPA4quI9n+8Vijid6P5bBBQhlMQYpPsuzMhtm
YA7wKOcmn5kMXuNx47cQhAG8C5Cx1vdUkN8+N/WgFzBWG2/vrWaYsea7GDm5
TCl7+6B8sMGH/P/P+bOXz5mz8aZ5Oc85IzUGU7SfOh05sBybCNjGmgOIHL+H
Z8xuu+k1UFjxIt8pbKnQcqoy5yZ/822bDzOLvxxKBzACwu6BGUrXbu9AqXTV
rl/9ieduU//2wkHE7hEwDF+jBpPYvV/gfa5ijqWlGg49wn78aXQlCO7UUe88
SxVN+oJb71E+dYq9iKKPgFKEJhfS4gli+DeWuKsrrdUzXYaROrL922aLW/75
d236f7f+3V39n/qz8H5wMsS77btPXtw2PcxPZfz2N/D+E5TH7jnEd1XxWe8/
fd3lMZ7Iwfzl71tlzeZ9POfefZPHwKfdZ+BvQSCcd8+yJB4u/Pepwsaf/4b3
u28jbArUfYP9WVd5/80cu4U0zr7+++7sy96XN08mwHDdJ0lVoAexBH9N75/l
cUbdiG79pxn/oOY+Lj6b/teH8ei47UlGOyjjMomO28+UVLF6aH8idX2u+ifV
VLa+15UbKBZ4AWeGt3sUpfTuUE0IBoum61SlsIYvUT9iJcUmDGvtSgzegRRJ
mE8ipWiG+i7gVO7kDS7B6wC9INeqooqAMbIq5+4Y4ClRy43NXvAK4aJz/n6W
hEAg3YNrEHdVdz+RqbFxRAS6VrqsYNkWFj7V2suYxlJ0IWkWwNjxBAOOohrq
m4RBGfH1ybpzI0IOdrKM1SXsOItqHUDb45izIV3qtN0ii46OKT4/g9gfKNhC
F6CGcnCOUk4TDeN8WM2kEYu0j1neFYMvqW5uNplHSRzi/d5k59HPg1Fooc4c
0mPTi5fIvvI15ORfScDj+RZYFYm9F5AsBSyvVH0f0XdJdOOESvUoMPWn6gZr
MNo0APwYA6muMJUTARECanSA30kG0WtsQOkobqoiudkggkhnHuk4raANitfv
XgJ7MZmJ8iV2CJrE1JKIUrf8HqWdQetWBXcjUcnYMd8jTbghJxINKBgM2osk
IXye04TYyuek+AAv/xXWp+RwHP7rE7V3+3W6QL8i+Pn8zesfWq1nYZ7EwJCY
uswKrC7C1dUFkXpnYBZrFFRzAB9fBwP6A3jwD3f2H6GP+wJiwEvMeegGogxn
Qa0qkMnlSmynh6LNp7obRIF3R+eFZE8kG1w4vUp1ds++K1o1PnEvse4wtJhs
cVOCcVFwCTK1q2clwgkCuat5gOIkomZqHVU/guAkQe6bgMCOLuMhrye8zOKR
4TKZAvMIl8D9tGxRQ4y9B3uPdtlLLK2sJoqMoNppEksLYd6X0mnsUj4O0aV3
RYN6yuDpJOpFZPfHm2fUkwT7zvvdRwRac/20FKcWpBz1cjUREFFyjB9RIK2V
CAX1y+DlFHiV6m0A0Spx4V6QHqWASIx5WiepXJfNhMQnEQP3C1vppXhPgJoD
p88HMbBfjpiZl9NC9UEy0Q/5qNEsyxd0HiwuiaF0Z6Qq1RxqMBGxHzIKzCXe
YpWw9RHwPc6WZAtKJhM58WIKveGBfVjIgsQU+ZOGldj2CG8YZ8nRPivR2TdB
RMk0Y9VJo0kPJOqwhFGGmkMzOpbeEiQJsBD1swEnnCcnJ5eML0kP63aM0cgZ
Z0pexllCaTB73wRYSIgwyDPsazTijlVcBOXArPIdDnmxrWOhLJ2RXavtsGqV
hHbCQ8IRQ2/hOrgie0+2xTAPUnsm9YIgIxAjUTbE53g2d1Pw6TpyVDHJsg+M
LlplBwxDNqfwhhpwBSXmkxg7iIyQScV7AVt2E6zUufsde4gRF4agBn8HPTHJ
0G1o1LWx0nQ3tAhCtMTjRQ3frHWw5VeE9aCJSCQZx7BUQRipWS57UnEUr0CK
89QqUAQ1hRJdf0nG4Ar8POxpBKjFRndRlJBSohkIJ7jhkt4vgzailK8LoYov
S+NLsO+2FcKot4CJuc8fKHiv7RAF27XtHSAiskH0kZiLInPdgs7c/b5xfe1d
eC/FtbR8/TN9wp/GVcr7QHRIf8GCITpa/+Z5BKjIlQtqNKXqssU2paNOA4NG
HRUmaJVEAsoL4Jj0mVoEecti2HyeECH3GqY246/gXTPpaUU9pjJunzeN7BZ7
mKQBAoPA0ZYeWpVhiXb+AvgpHhENsOkYalD0kVALo94kLa3yADF5ROzdc23y
bFalxMVl8Nt32CysONzamsCU1aAHv27hV1eTLV22POIIpIvjF799jz6xbX2E
7KnOlNhNDwP/7r084qNAXUp75JeSrEAToXViQdkNpDF7ncpfVhleGkB261na
eFMUyaO9YAELlDlrDWbLETZd5w3jUisU4xegoNreKj2pVDH1ry0dZ8Cnaw0X
PlNkgaw7Ei5DY8OByCAqr/CsM7fbI8SxA16o3DqFbKCSJoBO0qUJRBRViF2a
2TBRzzQJ6mh6POsl2TjJTNFvGCGRlEgWyTGSQyr/BLa6yjGJlAdtqpdqi9wE
0nU7tA6coKZVokg4pA6agWqgWSiY5BJJ1ZxTwg2nTbxVlB+byJQy01fhQpNO
YhwWCQw/xRGQxRp+sIcA1YJfffpE3gSY+wVlu70mfrrIH3l1FGE1qQyMzjMZ
XLrUa17xJjK7rrhq2YPR5ubU4w5qk2x1hXPiWcppa6WjhQ+baFaMeFkbUD6e
QcimV6ZVF64OeYX7ret+n9HHIe1v19vHEQQdcUn085QQ19FlljdcwxacPH79
HGKacJCOP6m9fgmoq0LysifVRPTuYwiQqqL7OqxyxPUs2MD3N5GEDAg74vs7
u3vSJj3BnA3yCMotDIyCuwCwPyKaava654EQc2FEShYXRMItbQKhCyd5xDGM
kjq1H0fpcaOCkcAIK5/i1C6d/QixxRx7cI94n4CaMCJmWsWY2nlIYueYEp9d
6SPx7Qb1V8CLUvG/9k+bLfsTvggD0QnSrYBavdCorZb5m4dvb7SDb8/Pgn/o
52GSPn6jPm/S7//EJjgtPxNlTpm1WtbxORoZxsFTk/iykfpN85isjz7jKTEA
gQtn8DNvtP+zZX7lp+GvlvqkMLShT3BtUd58swbmt/YjVF+Fj75v47+79O9e
W7+snlTDf/PxoN99cBIcBWH3j5YNHv6qTxe2kHJWlwn4DT8tIZ3902bL/kSj
8t+07g37XOIWfEQkye8MxuZmy3re4Ml5aDlHqG+d1diUNV/yELJPv4UfVAH+
ltWHlP4m/e8Qgr7msi75W0pjeCCQW4ZFhj8O/gG0+SfwYn+fSMYIlvnsn3eY
okjD/re75lkB51gVT387nKqdthb+qQhcpZz6GQEk8lfLfIcMsLPd3enDr/DX
bnf/Mf21/7T74FlLPUWi9FsbyCOTbdHHTQKELxlCRuX9HeE05Amqh8UvDokB
t9Qrgqdj+uHbDS5E2sRPLSlKoinVeJqn/1sNs4V8wkMJmo/pghT51FLfMuTb
9EKfX6ASimOsBLHILexNiSyNWNy9VMitLOxWBr0KyfjNVlBp/BrEqSdwsBfP
/i8sRf7D3WXBcDyZ8rUStAsOOj94+GivD5aEs6OFMiZ5dBkXOtSot1kNfuHc
oc5fuaEIV/VI5ZfZnZRJDlutb4MTSiXg71TXY7xdMaN4xI8bDsDD5xAE4Arp
QG0eTihFyIE4WULwJ0wcT5lpTABbY0qwRbesEKQLHvgVxJdsYVSD13SsrJaU
zccf6TUytfQOQx4u3x4VR4Hw0rDBSsPRRi4N91bcCI6/0PijE6DzeLWIzMWd
mypuxKLNaPg++Q9DvH8iwYsiKIXQuj7k9Fg0Om5TmRbua7zCpDJupn4gt/JV
WMKcV8FfcAM+JdpPyUksMaVPEfAIc7F80g403bjipIbeDwlGVa4KTEYY02Xz
WaQuqPIDWvIqaG6AJ0MAToFATxJwnmGCTvA2WzB6qTjoBNQwuH4pQIe7TbhV
+pfwj2qaBW8+VJ3gGd3bcJaBu/VzlQD2Ae/FcPoBHM5XuJ0Afv80mxWYQHiF
mY9fI2zmhgv5ORqPczAGfwOv+oMs26TD8xjiHW6R/j8TJtIrMvIAAA==
-->
</rfc>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment