<?xml version='1.0' encoding='utf-8'?> 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.7.8 (Ruby 3.2.2) -->
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-sfbis-06" number="9651" submissionType="IETF" category="std" consensus="true" obsoletes="8941" updates="" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 --> version="3" xml:lang="en">

  <front>
    <title>Structured Field Values for HTTP</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-sfbis-06"/> name="RFC" value="9651"/>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization>Cloudflare</organization>
      <address>
        <postal>
          <city>Prahran</city>
          <region>VIC</region>
          <country>Australia</country>
        </postal>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <author initials="P.-H." initials="P-H." surname="Kamp" fullname="Poul-Henning Kamp">
      <organization>The Varnish Cache Project</organization>
      <address>
        <email>phk@varnish-cache.org</email>
      </address>
    </author>
    <date/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>Internet-Draft</keyword>
    <date month="September" year="2024"/>

    <area>WIT</area>
    <workgroup>httpbis</workgroup>

<keyword>trailer</keyword>
<keyword>header</keyword>

    <abstract>
      <?line 86?>
<t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t> fields.</t>
      <t>This document obsoletes RFC 8941.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpbis-sfbis/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.org"/>),
        which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
        Working Group information can be found at <eref target="https://httpwg.org/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/httpwg/http-extensions/labels/header-structure"/>.</t>
    </note>
  </front>
  <middle>
    <?line 93?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Specifying the syntax of new HTTP header (and trailer) fields is an onerous task; even with the guidance in <xref section="16.3.2" sectionFormat="of" target="HTTP"/>, target="RFC9110"/>, there are many decisions -- and pitfalls -- for a prospective HTTP field author.</t>
      <t>Once a field is defined, bespoke parsers and serializers often need to be written, because each field value has a slightly different handling of what looks like common syntax.</t>
      <t>This document introduces a set of common data structures for use in definitions of new HTTP field values to address these problems. In particular, it defines a generic, abstract model for them, along with a concrete serialization for expressing that model in HTTP <xref target="HTTP"/> target="RFC9110"/> header and trailer fields.</t>
      <t>An HTTP field that is defined as a "Structured Header" or "Structured Trailer" (if the field can be either, it is a "Structured Field") uses the types defined in this specification to define its syntax and basic handling rules, thereby simplifying both its definition by specification writers and handling by implementations.</t>
      <t>Additionally, future versions of HTTP can define alternative serializations of the abstract model of these structures, allowing fields that use that model to be transmitted more efficiently without being redefined.</t>
      <t>Note that it is not a goal of this document to redefine the syntax of existing HTTP fields; the mechanisms described herein are only intended to be used with fields that explicitly opt into them.</t>
      <t><xref target="specify"/> describes how to specify a Structured Field.</t>
      <t><xref target="types"/> defines a number of abstract data types that can be used in Structured Fields.</t>
      <t>Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in <xref target="text"/>.</t>
      <section anchor="strict">
        <name>Intentionally Strict Processing</name>
        <t>This specification intentionally defines strict parsing and serialization behaviors using step-by-step algorithms; the only error handling defined is to fail the entire operation altogether.</t>
        <t>It is designed to encourage faithful implementation and good interoperability. Therefore, an implementation that tried to be helpful by being more tolerant of input would make interoperability worse, since that would create pressure on other implementations to implement similar (but likely subtly different) workarounds.</t>
        <t>In other words, strict processing is an intentional feature of this specification; it allows non-conformant input to be discovered and corrected by the producer early and avoids both interoperability and security issues that might otherwise result.</t>
        <t>Note that as a result of this strictness, if a field is appended to by multiple parties (e.g., intermediaries or different components in the sender), an error in one party's value is likely to cause the entire field value to fail parsing.</t>
      </section>
      <section anchor="notational-conventions">
        <name>Notational Conventions</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 BCP&nbsp;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"/> target="RFC9110"/> for the same purpose.</t>
        <t>This document uses algorithms to specify parsing and serialization behaviors. When parsing from HTTP fields, implementations MUST <bcp14>MUST</bcp14> have behavior that is indistinguishable from following the algorithms.</t>
        <t>For serialization to HTTP fields, the algorithms define the recommended way to produce them. Implementations MAY <bcp14>MAY</bcp14> vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm described in <xref target="text-parse"/>.</t>
      </section>
    </section>
    <section anchor="specify">
      <name>Defining New Structured Fields</name>
      <t>To specify an HTTP field as a Structured Field, its authors need to:</t>
      <ul spacing="normal">
        <li>
          <t>Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect.</t>
        </li>
        <li>
          <t>Identify whether the field is a Structured Header (i.e., it can only be used in the header section -- the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both).</t>
        </li>
        <li>
          <t>Specify the type of the field value; either List (<xref target="list"/>), Dictionary (<xref target="dictionary"/>), or Item (<xref target="item"/>).</t>
        </li>
        <li>
          <t>Define the semantics of the field value.</t>
        </li>
        <li>
          <t>Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.</t>
        </li>
      </ul>
      <t>Typically, this means that a field definition will specify the top-level type -- List, Dictionary, or Item -- and then define its allowable types and constraints upon them. For example, a header defined as a List might have all Integer members, or a mix of types; a header defined as an Item might allow only Strings, and additionally only strings beginning with the letter "Q", or strings in lowercase. Likewise, Inner Lists (<xref target="inner-list"/>) are only valid when a field definition explicitly allows them.</t>
      <t>Fields that use the Display String type are advised to carefully specify their allowable unicode Unicode code points; for example, specifying the use of a profile from <xref target="PRECIS"/>.</t> target="RFC8264"/>.</t>
      <t>Field definitions can only use this specification for the entire field value, not a portion thereof.</t>
      <t>Specifications can refer to a field name as a "structured header "Structured Header name", "structured trailer "Structured Trailer name", or "structured field "Structured Field name" as appropriate. Likewise, they can refer its field value as a "structured header "Structured Header value", "structured trailer "Structured Trailer value", or "structured field "Structured Field value" as necessary.</t>
      <t>This specification defines minimums for the length or number of various structures supported by implementations. It does not specify maximum sizes in most cases, but authors should be aware that HTTP implementations do impose various limits on the size of individual fields, the total number of fields, and/or the size of the entire header or trailer section.</t>
      <section anchor="example">
        <name>Example</name>
        <t>A fictitious Foo-Example header field might be specified as:</t>
        <blockquote>
          <t>42. Foo-Example Header Field</t>
          <t>The Foo-Example HTTP header field conveys information about how
much Foo the message has.</t>
          <t>Foo-Example is an Item Structured Header Field [RFCnnnn]. [RFC9651]. Its value
MUST
<bcp14>MUST</bcp14> be an Integer (Section 3.3.1 of [RFCnnnn]).</t> [RFC9651]).</t>
          <t>Its value indicates the amount of Foo in the message, and it MUST <bcp14>MUST</bcp14>
be between 0 and 10, inclusive; other values MUST <bcp14>MUST</bcp14> cause
the entire header field to be ignored.</t>
          <t>The following parameter is defined:</t>
          <ul>
            <li>A parameter whose key is "foourl", and whose value is a String
  (Section 3.3.3 of [RFCnnnn]), [RFC9651]), conveying the Foo URL
  for the message. See below for processing requirements.</li>
          </ul>
          <t>"foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
its value is not a valid URI-reference, the entire header field
MUST
<bcp14>MUST</bcp14> be ignored. If its value is a relative reference (Section 4.2
of [RFC3986]), it MUST <bcp14>MUST</bcp14> be resolved (Section 5 of [RFC3986]) before
being used.</t>
          <t>For example:</t>
          <artwork><![CDATA[
  Foo-Example: 2; foourl="https://foo.example.com/"
]]></artwork>
        </blockquote>
      </section>
      <section anchor="error-handling">
        <name>Error Handling</name>
        <t>When parsing fails, the entire field is ignored (see <xref target="text-parse"/>). Field definitions cannot override this, 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, extensible because experience has shown that 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, cannot because it will be treated as invalid (and therefore discarded) by implementations of that specification.</t>
        <t>This limitation also applies to future extensions to a field; for example, a field that is defined with a reference to RFC 8941 cannot use the Date type, type because some recipients might still be using an a parser based on RFC 8941 parser to process it.</t>
        <t>However, this document is designed to be backwards-compatible backward compatible with RFC 8941; a parser that implements the requirements here can also parse valid Structured Fields whose definitions reference RFC 8941.</t>
        <t>Upgrading a Structured Fields implementation to support a newer revision of the specification (such as this document) brings the possibility that some field values that were invalid according to the earlier RFC might become valid when processed.</t>
        <t>For example, a field instance might contain a syntactically valid Date (<xref target="date"/>), even though that field's definition does not accommodate Dates. An RFC8941 implementation based on RFC 8941 would fail parsing such a field instance, instance because they are it is not defined in that specification. If that implementation were upgraded to this specification, parsing would now succeed. In some cases, the resulting Date value will be rejected by field-specific logic, but values in fields that are otherwise ignored (such as extension parameters) might not be detected detected, and the field might subsequently be accepted and processed.</t>
      </section>
    </section>
    <section anchor="types">
      <name>Structured Data Types</name>
      <t>This section provides an overview of the abstract types that Structured Fields use, use and gives a brief description and examples of how each of those types are serialized into textual HTTP fields. <xref target="text"/> specifies the details of how they are parsed from and serialized into textual HTTP fields.</t>
      <t>In summary:</t>
      <ul spacing="normal">
        <li>
          <t>There are three top-level types that an HTTP field can be defined as: Lists, Dictionaries, and Items.</t>
        </li>
        <li>
          <t>Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items).</t>
        </li>
        <li>
          <t>Both Items and Inner Lists can be Parameterized with key/value pairs.</t>
        </li>
      </ul>
      <section anchor="list">
        <name>Lists</name>
        <t>Lists are arrays of zero or more members, each of which can be an Item (<xref target="item"/>) or an Inner List (<xref target="inner-list"/>), both of which can be Parameterized (<xref target="param"/>).</t>
        <t>An empty List is denoted by not serializing the field at all. This implies that fields defined as Lists have a default empty value.</t>
        <t>When serialized as a textual HTTP field, each member is separated by a comma and optional whitespace. For example, a field whose value is defined as a List of Tokens could look like:</t>
        <sourcecode type="http-message"><![CDATA[
Example-List: sugar, tea, rum
]]></sourcecode>
        <t>Note that Lists can have their members split across multiple lines of the same header or trailer section, as per <xref section="5.3" sectionFormat="of" target="HTTP"/>; target="RFC9110"/>; for example, the following are equivalent:</t>
        <sourcecode type="http-message"><![CDATA[
Example-List: sugar, tea, rum
]]></sourcecode>
        <t>and</t>
        <sourcecode type="http-message"><![CDATA[
Example-List: sugar, tea
Example-List: rum
]]></sourcecode>
        <t>However, individual members of a List cannot be safely split between lines; see <xref target="text-parse"/> for details.</t>
        <t>Parsers MUST <bcp14>MUST</bcp14> support Lists containing at least 1024 members. Field specifications can constrain the types and cardinality of individual List values as they require.</t>
        <section anchor="inner-list">
          <name>Inner Lists</name>
          <t>An Inner List is an array of zero or more Items (<xref target="item"/>). Both the individual Items and the Inner List itself can be Parameterized (<xref target="param"/>).</t>
          <t>When serialized in a textual HTTP field, Inner Lists are denoted by surrounding parenthesis, and their values are delimited by one or more spaces. A field whose value is defined as a List of Inner Lists of Strings could look like:</t>
          <sourcecode type="http-message"><![CDATA[
Example-List: ("foo" "bar"), ("baz"), ("bat" "one"), ()
]]></sourcecode>
          <t>Note that the last member in this example is an empty Inner List.</t>
          <t>A header field whose value is defined as a List of Inner Lists with Parameters at both levels could look like:</t>
          <sourcecode type="http-message"><![CDATA[
Example-List: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1
]]></sourcecode>
          <t>Parsers MUST <bcp14>MUST</bcp14> support Inner Lists containing at least 256 members. Field specifications can constrain the types and cardinality of individual Inner List members as they require.</t>
        </section>
        <section anchor="param">
          <name>Parameters</name>
          <t>Parameters are an ordered map of key-value pairs that are associated with an Item (<xref target="item"/>) or Inner List (<xref target="inner-list"/>). The keys are unique within the scope of the Parameters they occur within, and the values are bare items (i.e., they themselves cannot be parameterized; see <xref target="item"/>).</t>
          <t>Implementations MUST <bcp14>MUST</bcp14> provide access to Parameters both by index and by key. Specifications MAY <bcp14>MAY</bcp14> use either means of accessing them.</t>
          <t>Note that parameters are ordered, and parameter keys cannot contain uppercase letters.</t>
          <t>When serialized in a textual HTTP field, a Parameter is separated from its Item or Inner List and other Parameters by a semicolon. For example:</t>
          <sourcecode type="http-message"><![CDATA[
Example-List: abc;a=1;b=2; cde_456, (ghi;jk=4 l);q="9";r=w
]]></sourcecode>
          <t>Parameters whose value is Boolean (see <xref target="boolean"/>) true MUST <bcp14>MUST</bcp14> omit that value when serialized. For example, the "a" parameter here is true, while the "b" parameter is false:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Integer: 1; a; b=?0
]]></sourcecode>
          <t>Note that this requirement is only on serialization; parsers are still required to correctly handle the true value when it appears in a parameter.</t>
          <t>Parsers MUST <bcp14>MUST</bcp14> support at least 256 parameters on an Item or Inner List, and support parameter keys with at least 64 characters. Field specifications can constrain the order of individual parameters, as well as their values' types as required.</t>
        </section>
      </section>
      <section anchor="dictionary">
        <name>Dictionaries</name>
        <t>Dictionaries are ordered maps of key-value pairs, where the keys are short textual strings and the values are Items (<xref target="item"/>) or arrays of Items, both of which can be Parameterized (<xref target="param"/>). There can be zero or more members, and their keys are unique in the scope of the Dictionary they occur within.</t>
        <t>Implementations MUST <bcp14>MUST</bcp14> provide access to Dictionaries both by index and by key. Specifications MAY <bcp14>MAY</bcp14> use either means of accessing the members.</t>
        <t>As with Lists, an empty Dictionary is represented by omitting the entire field. This implies that fields defined as Dictionaries have a default empty value.</t>
        <t>Typically, a field specification will define the semantics of Dictionaries by specifying the allowed type(s) for individual members by their keys, as well as whether their presence is required or optional. Recipients MUST <bcp14>MUST</bcp14> ignore members whose keys are undefined or unknown, unless the field's specification specifically disallows them.</t>
        <t>When serialized as a textual HTTP field, Members 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 <bcp14>MUST</bcp14> omit that value when serialized. For example, here both "b" and "c" are true:</t>
        <sourcecode type="http-message"><![CDATA[
Example-Dict: a=?0, b, c; foo=bar
]]></sourcecode>
        <t>Note that this requirement is only on serialization; parsers are still required to correctly handle the true Boolean value when it appears in Dictionary values.</t>
        <t>A Dictionary with a member whose value is an Inner List of Tokens:</t>
        <sourcecode type="http-message"><![CDATA[
Example-Dict: rating=1.5, feelings=(joy sadness)
]]></sourcecode>
        <t>A Dictionary with a mix of Items and Inner Lists, some with parameters:</t>
        <sourcecode type="http-message"><![CDATA[
Example-Dict: a=(1 2), b=3, c=4;aa=bb, d=(5 6);valid
]]></sourcecode>
        <t>Note that Dictionaries can have their members split across multiple lines of the same header or trailer section; for example, the following are equivalent:</t>
        <sourcecode type="http-message"><![CDATA[
Example-Dict: foo=1, bar=2
]]></sourcecode>
        <t>and</t>
        <sourcecode type="http-message"><![CDATA[
Example-Dict: foo=1
Example-Dict: bar=2
]]></sourcecode>
        <t>However, individual members of a Dictionary cannot be safely split between lines; see <xref target="text-parse"/> for details.</t>
        <t>Parsers MUST <bcp14>MUST</bcp14> support Dictionaries containing at least 1024 key/value pairs and keys with at least 64 characters. Field specifications can constrain the order of individual Dictionary members, as well as their values' types as required.</t>
      </section>
      <section anchor="item">
        <name>Items</name>
        <t>An Item can be an Integer (<xref target="integer"/>), a Decimal (<xref target="decimal"/>), a String (<xref target="string"/>), a Token (<xref target="token"/>), a Byte Sequence (<xref target="binary"/>), a Boolean (<xref target="boolean"/>), or a Date (<xref target="date"/>). It can have associated parameters (<xref target="param"/>).</t>
        <t>For example, a header field that is defined to be an Item that is an Integer might look like:</t>
        <sourcecode type="http-message"><![CDATA[
Example-Integer: 5
]]></sourcecode>
        <t>or with parameters:</t>
        <sourcecode type="http-message"><![CDATA[
Example-Integer: 5; foo=bar
]]></sourcecode>
        <section anchor="integer">
          <name>Integers</name>
          <t>Integers have a range of -999,999,999,999,999 to 999,999,999,999,999 inclusive (i.e., up to fifteen digits, signed), for IEEE 754 compatibility <xref target="IEEE754"/>.</t>
          <t>For example:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Integer: 42
]]></sourcecode>
          <t>Integers larger than 15 digits can be supported in a variety of ways; for example, by using a String (<xref target="string"/>), a Byte Sequence (<xref target="binary"/>), or a parameter on an Integer that acts as a scaling factor.</t>
          <t>While it is possible to serialize Integers with leading zeros (e.g., "0002", "-01") and signed zero ("-0"), these distinctions may not be preserved by implementations.</t>
          <t>Note that commas in Integers are used in this section's prose only for readability; they are not valid in the wire format.</t>
        </section>
        <section anchor="decimal">
          <name>Decimals</name>
          <t>Decimals are numbers with an integer and a fractional component. The integer component has at most 12 digits; the fractional component has at most three digits.</t>
          <t>For example, a header whose value is defined as a Decimal could look like:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Decimal: 4.5
]]></sourcecode>
          <t>While it is possible to serialize Decimals with leading zeros (e.g., "0002.5", "-01.334"), trailing zeros (e.g., "5.230", "-0.40"), and signed zero (e.g., "-0.0"), these distinctions may not be preserved by implementations.</t>
          <t>Note that the serialization algorithm (<xref target="ser-decimal"/>) rounds input with more than three digits of precision in the fractional component. If an alternative rounding strategy is desired, this should be specified by the field definition to occur before serialization.</t>
        </section>
        <section anchor="string">
          <name>Strings</name>
          <t>Strings are zero or more printable ASCII <xref target="RFC0020"/> characters (i.e., the range %x20 to %x7E). Note that this excludes tabs, newlines, carriage returns, etc.</t>
          <t>Non-ASCII characters are not directly supported in Strings, Strings because they cause a number of interoperability issues, and -- with few exceptions -- field values do not require them.</t>
          <t>When it is necessary for a field value to convey non-ASCII content, a Display String (<xref target="displaystring"/>) can be specified.</t>
          <t>When serialized in a textual HTTP field, Strings are delimited with double quotes, using a backslash ("\") to escape double quotes and backslashes. For example:</t>
          <sourcecode type="http-message"><![CDATA[
Example-String: "hello world"
]]></sourcecode>
          <t>Note that Strings only use DQUOTE as a delimiter; single quotes do not delimit Strings. Furthermore, only DQUOTE and "\" can be escaped; other characters after "\" MUST <bcp14>MUST</bcp14> cause parsing to fail.</t>
          <t>Parsers MUST <bcp14>MUST</bcp14> support Strings (after any decoding) with at least 1024 characters.</t>
        </section>
        <section anchor="token">
          <name>Tokens</name>
          <t>Tokens are short textual words that begin with an alphabetic character or "*", followed by zero to many token characters, which are the same as those allowed by the "token" ABNF rule defined in <xref target="HTTP"/>, target="RFC9110"/> plus the ":" and "/" characters.</t>
          <t>For example:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Token: foo123/456
]]></sourcecode>
          <t>Parsers MUST <bcp14>MUST</bcp14> support Tokens with at least 512 characters.</t>
          <t>Note that Tokens are defined largely for compatibility with the data model of existing HTTP fields, fields and may require additional steps to use in some implementations. As a result, new fields are encouraged to use Strings.</t>
        </section>
        <section anchor="binary">
          <name>Byte Sequences</name>
          <t>Byte Sequences can be conveyed in Structured Fields.</t>
          <t>When serialized in a textual HTTP field, a Byte Sequence is delimited with colons and encoded using base64 (<xref section="4" sectionFormat="comma" target="RFC4648"/>). For example:</t>
          <sourcecode type="http-message"><![CDATA[
Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:
]]></sourcecode>
          <t>Parsers MUST <bcp14>MUST</bcp14> support Byte Sequences with at least 16384 octets after decoding.</t>
        </section>
        <section anchor="boolean">
          <name>Booleans</name>
          <t>Boolean values can be conveyed in Structured Fields.</t>
          <t>When serialized in a textual HTTP field, a Boolean is indicated with a leading "?" character followed by a "1" for a true value or "0" for false. For example:</t>
          <sourcecode type="http-message"><![CDATA[
Example-Boolean: ?1
]]></sourcecode>
          <t>Note that in Dictionary (<xref target="dictionary"/>) and Parameter (<xref target="param"/>) values, Boolean true is indicated by omitting the value.</t>
        </section>
        <section anchor="date">
          <name>Dates</name>
          <t>Date values can be conveyed in Structured Fields.</t>
          <t>Dates have a data model that is similar to Integers, representing a (possibly negative) delta in seconds from 1970-01-01T00:00:00Z, excluding leap seconds. Accordingly, their serialization in textual HTTP fields is similar to that of Integers, distinguished from them with a leading "@".</t>
          <t>For example:</t>
          <sourcecode type="http-message-new"><![CDATA[
Example-Date: @1659578233
]]></sourcecode>
          <t>Parsers MUST <bcp14>MUST</bcp14> support Dates whose values include all days in years 1 to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from 1970-01-01T00:00:00Z).</t>
        </section>
        <section anchor="displaystring">
          <name>Display Strings</name>
          <t>Display Strings are similar to Strings, in that they consist of zero or more characters, but they allow Unicode scalar values (i.e., all Unicode code points except for surrogates), unlike Strings.</t>
          <t>Display Strings are intended for use in cases where a value is displayed to end users, users and therefore may need to carry non-ASCII content. It is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> that they be used in situations where a String (<xref target="string"/>) or Token (<xref target="token"/>) would be adequate, adequate because Unicode has processing considerations (e.g., normalization) and security considerations (e.g., homograph attacks) that make it more difficult to handle correctly.</t>
          <t>Note that Display Strings do not indicate the language used in the value; that can be done separately if necessary (e.g., with a parameter).</t>
          <t>In textual HTTP fields, Display Strings are represented in a manner similar to Strings, except that non-ASCII characters are percent-encoded; there is a leading "%" to distinguish them from Strings.</t>
          <t>For example:</t>
          <sourcecode type="http-message-new"><![CDATA[
Example-DisplayString: %"This is intended for display to %c3%bcsers."
]]></sourcecode>
          <t>See <xref target="security"/> for additional security considerations when handling Display Strings.</t>
        </section>
      </section>
    </section>
    <section anchor="text">
      <name>Working with Structured Fields in HTTP</name>
      <t>This section defines how to serialize and parse the abstract types defined by <xref target="types"/> into textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 <xref target="RFC9113"/> before compression with HPACK <xref target="HPACK"/>).</t> target="RFC7541"/>).</t>
      <section anchor="text-serialize">
        <name>Serializing Structured Fields</name>
        <t>Given a structure defined in this specification, return an ASCII string suitable for use in an HTTP field value.</t>
        <ol spacing="normal" type="1"><li>
            <t>If the structure is a Dictionary or List and its value is empty (i.e., it has no members), do not serialize the field at all (i.e., omit both the field-name and field-value).</t>
          </li>
          <li>
            <t>If the structure is a List, let output_string be the result of running Serializing a List (<xref target="ser-list"/>) with the structure.</t>
          </li>
          <li>
            <t>Else, if the structure is a Dictionary, let output_string be the result of running Serializing a Dictionary (<xref target="ser-dictionary"/>) with the structure.</t>
          </li>
          <li>
            <t>Else, if the structure is an Item, let output_string be the result of running Serializing an Item (<xref target="ser-item"/>) with the structure.</t>
          </li>
          <li>
            <t>Else, fail serialization.</t>
          </li>
          <li>
            <t>Return output_string converted into an array of bytes, using ASCII encoding <xref target="RFC0020"/>.</t>
          </li>
        </ol>
        <section anchor="ser-list">
          <name>Serializing a List</name>
          <t>Given an array of (member_value, parameters) tuples as input_list, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let output be an empty string.</t>
            </li>
            <li>
              <t>For each (member_value, parameters) of input_list:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>If member_value is an array, append the result of running Serializing an Inner List (<xref target="ser-innerlist"/>) with (member_value, parameters) to output.</t>
                </li>
                <li>
                  <t>Otherwise, append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</t>
                </li>
                <li>
                  <t>If more member_values remain in input_list:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Append "," to output.</t>
                    </li>
                    <li>
                      <t>Append a single SP to output.</t>
                    </li>
                  </ol>
                </li>
              </ol>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
          <section anchor="ser-innerlist">
            <name>Serializing an Inner List</name>
            <t>Given an array of (member_value, parameters) tuples as inner_list, and parameters as list_parameters, return an ASCII string suitable for use in an HTTP field value.</t>
            <ol spacing="normal" type="1"><li>
                <t>Let output be the string "(".</t>
              </li>
              <li>
                <t>For each (member_value, parameters) of inner_list:
                </t>
                <ol spacing="normal" type="1"><li>
                    <t>Append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</t>
                  </li>
                  <li>
                    <t>If more values remain in inner_list, append a single SP to output.</t>
                  </li>
                </ol>
              </li>
              <li>
                <t>Append ")" to output.</t>
              </li>
              <li>
                <t>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with list_parameters to output.</t>
              </li>
              <li>
                <t>Return output.</t>
              </li>
            </ol>
          </section>
          <section anchor="ser-params">
            <name>Serializing Parameters</name>
            <t>Given an ordered Dictionary as input_parameters (each member having a param_key and a param_value), return an ASCII string suitable for use in an HTTP field value.</t>
            <ol spacing="normal" type="1"><li>
                <t>Let output be an empty string.</t>
              </li>
              <li>
                <t>For each param_key with a value of param_value in input_parameters:
                </t>
                <ol spacing="normal" type="1"><li>
                    <t>Append ";" to output.</t>
                  </li>
                  <li>
                    <t>Append the result of running Serializing a Key (<xref target="ser-key"/>) with param_key to output.</t>
                  </li>
                  <li>
                    <t>If param_value is not Boolean true:
                    </t>
                    <ol spacing="normal" type="1"><li>
                        <t>Append "=" to output.</t>
                      </li>
                      <li>
                        <t>Append the result of running Serializing a bare Item (<xref target="ser-bare-item"/>) with param_value to output.</t>
                      </li>
                    </ol>
                  </li>
                </ol>
              </li>
              <li>
                <t>Return output.</t>
              </li>
            </ol>
          </section>
          <section anchor="ser-key">
            <name>Serializing a Key</name>
            <t>Given a key as input_key, return an ASCII string suitable for use in an HTTP field value.</t>
            <ol spacing="normal" type="1"><li>
                <t>Convert input_key into a sequence of ASCII characters; if conversion fails, fail serialization.</t>
              </li>
              <li>
                <t>If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*", fail serialization.</t>
              </li>
              <li>
                <t>If the first character of input_key is not lcalpha or "*", fail serialization.</t>
              </li>
              <li>
                <t>Let output be an empty string.</t>
              </li>
              <li>
                <t>Append input_key to output.</t>
              </li>
              <li>
                <t>Return output.</t>
              </li>
            </ol>
          </section>
        </section>
        <section anchor="ser-dictionary">
          <name>Serializing a Dictionary</name>
          <t>Given an ordered Dictionary as input_dictionary (each member having a member_key and a tuple value of (member_value, parameters)), return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let output be an empty string.</t>
            </li>
            <li>
              <t>For each member_key with a value of (member_value, parameters) in input_dictionary:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>Append the result of running Serializing a Key (<xref target="ser-key"/>) with member's member_key to output.</t>
                </li>
                <li>
                  <t>If member_value is Boolean true:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with parameters to output.</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>Otherwise:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Append "=" to output.</t>
                    </li>
                    <li>
                      <t>If member_value is an array, append the result of running Serializing an Inner List (<xref target="ser-innerlist"/>) with (member_value, parameters) to output.</t>
                    </li>
                    <li>
                      <t>Otherwise, append the result of running Serializing an Item (<xref target="ser-item"/>) with (member_value, parameters) to output.</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>If more members remain in input_dictionary:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Append "," to output.</t>
                    </li>
                    <li>
                      <t>Append a single SP to output.</t>
                    </li>
                  </ol>
                </li>
              </ol>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
        </section>
        <section anchor="ser-item">
          <name>Serializing an Item</name>
          <t>Given an Item as bare_item and Parameters as item_parameters, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let output be an empty string.</t>
            </li>
            <li>
              <t>Append the result of running Serializing a Bare Item (<xref target="ser-bare-item"/>) with bare_item to output.</t>
            </li>
            <li>
              <t>Append the result of running Serializing Parameters (<xref target="ser-params"/>) with item_parameters to output.</t>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
          <section anchor="ser-bare-item">
            <name>Serializing a Bare Item</name>
            <t>Given an Item as input_item, return an ASCII string suitable for use in an HTTP field value.</t>
            <ol spacing="normal" type="1"><li>
                <t>If input_item is an Integer, return the result of running Serializing an Integer (<xref target="ser-integer"/>) with input_item.</t>
              </li>
              <li>
                <t>If input_item is a Decimal, return the result of running Serializing a Decimal (<xref target="ser-decimal"/>) with input_item.</t>
              </li>
              <li>
                <t>If input_item is a String, return the result of running Serializing a String (<xref target="ser-string"/>) with input_item.</t>
              </li>
              <li>
                <t>If input_item is a Token, return the result of running Serializing a Token (<xref target="ser-token"/>) with input_item.</t>
              </li>
              <li>
                <t>If input_item is a Byte Sequence, return the result of running Serializing a Byte Sequence (<xref target="ser-binary"/>) with input_item.</t>
              </li>
              <li>
                <t>If input_item is a Boolean, return the result of running Serializing a Boolean (<xref target="ser-boolean"/>) with input_item.</t>
              </li>
              <li>
                <t>If input_item is a Date, return the result of running Serializing a Date (<xref target="ser-date"/>) with input_item.</t>
              </li>
              <li>
                <t>If input_item is a Display String, return the result of running Serializing a Display String (<xref target="ser-display"/>) with input_item.</t>
              </li>
              <li>
                <t>Otherwise, fail serialization.</t>
              </li>
            </ol>
          </section>
        </section>
        <section anchor="ser-integer">
          <name>Serializing an Integer</name>
          <t>Given an Integer as input_integer, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If input_integer is not an integer in the range of -999,999,999,999,999 to 999,999,999,999,999 inclusive, fail serialization.</t>
            </li>
            <li>
              <t>Let output be an empty string.</t>
            </li>
            <li>
              <t>If input_integer is less than (but not equal to) 0, append "-" to output.</t>
            </li>
            <li>
              <t>Append input_integer's numeric value represented in base 10 using only decimal digits to output.</t>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
        </section>
        <section anchor="ser-decimal">
          <name>Serializing a Decimal</name>
          <t>Given a decimal number as input_decimal, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If input_decimal is not a decimal number, fail serialization.</t>
            </li>
            <li>
              <t>If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant.</t>
            </li>
            <li>
              <t>If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialization.</t>
            </li>
            <li>
              <t>Let output be an empty string.</t>
            </li>
            <li>
              <t>If input_decimal is less than (but not equal to) 0, append "-" to output.</t>
            </li>
            <li>
              <t>Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0".</t>
            </li>
            <li>
              <t>Append "." to output.</t>
            </li>
            <li>
              <t>If input_decimal's fractional component is zero, append "0" to output.</t>
            </li>
            <li>
              <t>Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal digits) to output.</t>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
        </section>
        <section anchor="ser-string">
          <name>Serializing a String</name>
          <t>Given a String as input_string, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Convert input_string into a sequence of ASCII characters; if conversion fails, fail serialization.</t>
            </li>
            <li>
              <t>If input_string contains characters in the range %x00-1f or %x7f-ff (i.e., not in VCHAR or SP), fail serialization.</t>
            </li>
            <li>
              <t>Let output be the string DQUOTE.</t>
            </li>
            <li>
              <t>For each character char in input_string:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>If char is "\" or DQUOTE:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Append "\" to output.</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>Append char to output.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>Append DQUOTE to output.</t>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
        </section>
        <section anchor="ser-token">
          <name>Serializing a Token</name>
          <t>Given a Token as input_token, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Convert input_token into a sequence of ASCII characters; if conversion fails, fail serialization.</t>
            </li>
            <li>
              <t>If the first character of input_token is not ALPHA or "*", or the remaining portion contains a character not in tchar, ":", or "/", fail serialization.</t>
            </li>
            <li>
              <t>Let output be an empty string.</t>
            </li>
            <li>
              <t>Append input_token to output.</t>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
        </section>
        <section anchor="ser-binary">
          <name>Serializing a Byte Sequence</name>
          <t>Given a Byte Sequence as input_bytes, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If input_bytes is not a sequence of bytes, fail serialization.</t>
            </li>
            <li>
              <t>Let output be an empty string.</t>
            </li>
            <li>
              <t>Append ":" to output.</t>
            </li>
            <li>
              <t>Append the result of base64-encoding input_bytes as per <xref section="4" sectionFormat="comma" target="RFC4648"/>, taking account of the requirements below.</t>
            </li>
            <li>
              <t>Append ":" to output.</t>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
          <t>The encoded data is required to be padded with "=", as per <xref section="3.2" sectionFormat="comma" target="RFC4648"/>.</t>
          <t>Likewise, encoded data SHOULD <bcp14>SHOULD</bcp14> have pad bits set to zero, as per <xref section="3.5" sectionFormat="comma" target="RFC4648"/>, unless it is not possible to do so due to implementation constraints.</t>
        </section>
        <section anchor="ser-boolean">
          <name>Serializing a Boolean</name>
          <t>Given a Boolean as input_boolean, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If input_boolean is not a boolean, fail serialization.</t>
            </li>
            <li>
              <t>Let output be an empty string.</t>
            </li>
            <li>
              <t>Append "?" to output.</t>
            </li>
            <li>
              <t>If input_boolean is true, append "1" to output.</t>
            </li>
            <li>
              <t>If input_boolean is false, append "0" to output.</t>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
        </section>
        <section anchor="ser-date">
          <name>Serializing a Date</name>
          <t>Given a Date as input_date, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let output be "@".</t>
            </li>
            <li>
              <t>Append to output the result of running Serializing an Integer with input_date (<xref target="ser-integer"/>).</t>
            </li>
            <li>
              <t>Return output.</t>
            </li>
          </ol>
        </section>
        <section anchor="ser-display">
          <name>Serializing a Display String</name>
          <t>Given a sequence of Unicode codepoints code points as input_sequence, return an ASCII string suitable for use in an HTTP field value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If input_sequence is not a sequence of Unicode codepoints, code points, fail serialization.</t>
            </li>
            <li>
              <t>Let byte_array be the result of applying UTF-8 encoding (<xref section="3" sectionFormat="of" target="UTF8"/>) target="RFC3629"/>) to input_sequence. If encoding fails, fail serialization.</t>
            </li>
            <li>
              <t>Let encoded_string be a string containing "%" followed by DQUOTE.</t>
            </li>
            <li>
              <t>For each byte in byte_array:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Append "%" to encoded_string.</t>
                    </li>
                    <li>
                      <t>Let encoded_byte be the result of applying base16 encoding (<xref section="8" sectionFormat="of" target="RFC4648"/>) to byte, with any alphabetic characters converted to lowercase.</t>
                    </li>
                    <li>
                      <t>Append encoded_byte to encoded_string.</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>Otherwise, decode byte as an ASCII character and append the result to encoded_string.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>Append DQUOTE to encoded_string.</t>
            </li>
            <li>
              <t>Return encoded_string.</t>
            </li>
          </ol>
          <t>Note that <xref target="UTF8"/> target="RFC3629"/> prohibits the encoding of codepoints code points between U+D800 and U+DFFF (surrogates); if they occur in input_sequence, serialization will fail.</t>
        </section>
      </section>
      <section anchor="text-parse">
        <name>Parsing Structured Fields</name>
        <t>When a receiving implementation parses HTTP fields that are known to be Structured Fields, it is important that care be taken, as there are a number of edge cases that can cause interoperability or even security problems. This section specifies the algorithm for doing so.</t>
        <t>Given an array of bytes as input_bytes that represent the chosen field's field-value (which is empty if that field is not present) and field_type (one of "dictionary", "list", or "item"), return the parsed field value.</t>
        <ol spacing="normal" type="1"><li>
            <t>Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.</t>
          </li>
          <li>
            <t>Discard any leading SP characters from input_string.</t>
          </li>
          <li>
            <t>If field_type is "list", let output be the result of running Parsing a List (<xref target="parse-list"/>) with input_string.</t>
          </li>
          <li>
            <t>If field_type is "dictionary", let output be the result of running Parsing a Dictionary (<xref target="parse-dictionary"/>) with input_string.</t>
          </li>
          <li>
            <t>If field_type is "item", let output be the result of running Parsing an Item (<xref target="parse-item"/>) with input_string.</t>
          </li>
          <li>
            <t>Discard any leading SP characters from input_string.</t>
          </li>
          <li>
            <t>If input_string is not empty, fail parsing.</t>
          </li>
          <li>
            <t>Otherwise, return output.</t>
          </li>
        </ol>
        <t>When generating input_bytes, parsers MUST <bcp14>MUST</bcp14> combine all field lines in the same section (header or trailer) that case-insensitively match the field name into one comma-separated field-value, as per <xref section="5.2" sectionFormat="of" target="HTTP"/>; target="RFC9110"/>; this assures that the entire field value is processed correctly.</t>
        <t>For Lists and Dictionaries, this has the effect of correctly concatenating all of the field's lines, as long as individual members of the top-level data structure are not split across multiple field instances. The parsing algorithms for both types allow tab characters, since these might
be used to combine field lines by some implementations.</t>
        <t>Strings split across multiple field lines will have unpredictable results, because one or more commas (with optional whitespace) will become part of the string output by the parser. Since concatenation might be done by an upstream intermediary, the results are not under the control of the serializer or the parser, even when they are both under the control of the same party.</t>
        <t>Tokens, Integers, Decimals, and Byte Sequences cannot be split across multiple field lines because the inserted commas will cause parsing to fail.</t>
        <t>Parsers MAY <bcp14>MAY</bcp14> fail when processing a field value spread across multiple field lines, when one of those lines does not parse as that field. For example, a parsing handling an Example-String field that's defined as an sf-string is allowed to fail when processing this field section:</t>
        <sourcecode type="http-message"><![CDATA[
Example-String: "foo
Example-String: bar"
]]></sourcecode>
        <t>If parsing fails, either the entire field value MUST <bcp14>MUST</bcp14> be ignored (i.e., treated as if the field were not present in the section), or alternatively the complete HTTP message MUST <bcp14>MUST</bcp14> be treated as malformed. This is intentionally strict to improve interoperability and safety, and field specifications that use Structured Fields are not allowed to loosen this requirement.</t>
        <t>Note that this requirement does not apply to an implementation that is not parsing the field; for example, an intermediary is not required to strip a failing field from a message before forwarding it.</t>
        <section anchor="parse-list">
          <name>Parsing a List</name>
          <t>Given an ASCII string as input_string, return an array of (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let members be an empty array.</t>
            </li>
            <li>
              <t>While input_string is not empty:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>Append the result of running Parsing an Item or Inner List (<xref target="parse-item-or-list"/>) with input_string to members.</t>
                </li>
                <li>
                  <t>Discard any leading OWS characters from input_string.</t>
                </li>
                <li>
                  <t>If input_string is empty, return members.</t>
                </li>
                <li>
                  <t>Consume the first character of input_string; if it is not ",", fail parsing.</t>
                </li>
                <li>
                  <t>Discard any leading OWS characters from input_string.</t>
                </li>
                <li>
                  <t>If input_string is empty, there is a trailing comma; fail parsing.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>No structured data has been found; return members (which is empty).</t>
            </li>
          </ol>
          <section anchor="parse-item-or-list">
            <name>Parsing an Item or Inner List</name>
            <t>Given an ASCII string as input_string, return the tuple (item_or_inner_list, parameters), where item_or_inner_list can be either a single bare item or an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.</t>
            <ol spacing="normal" type="1"><li>
                <t>If the first character of input_string is "(", return the result of running Parsing an Inner List (<xref target="parse-innerlist"/>) with input_string.</t>
              </li>
              <li>
                <t>Return the result of running Parsing an Item (<xref target="parse-item"/>) with input_string.</t>
              </li>
            </ol>
          </section>
          <section anchor="parse-innerlist">
            <name>Parsing an Inner List</name>
            <t>Given an ASCII string as input_string, return the tuple (inner_list, parameters), where inner_list is an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.</t>
            <ol spacing="normal" type="1"><li>
                <t>Consume the first character of input_string; if it is not "(", fail parsing.</t>
              </li>
              <li>
                <t>Let inner_list be an empty array.</t>
              </li>
              <li>
                <t>While input_string is not empty:
                </t>
                <ol spacing="normal" type="1"><li>
                    <t>Discard any leading SP characters from input_string.</t>
                  </li>
                  <li>
                    <t>If the first character of input_string is ")":
                    </t>
                    <ol spacing="normal" type="1"><li>
                        <t>Consume the first character of input_string.</t>
                      </li>
                      <li>
                        <t>Let parameters be the result of running Parsing Parameters (<xref target="parse-param"/>) with input_string.</t>
                      </li>
                      <li>
                        <t>Return the tuple (inner_list, parameters).</t>
                      </li>
                    </ol>
                  </li>
                  <li>
                    <t>Let item be the result of running Parsing an Item (<xref target="parse-item"/>) with input_string.</t>
                  </li>
                  <li>
                    <t>Append item to inner_list.</t>
                  </li>
                  <li>
                    <t>If the first character of input_string is not SP or ")", fail parsing.</t>
                  </li>
                </ol>
              </li>
              <li>
                <t>The end of the Inner List was not found; fail parsing.</t>
              </li>
            </ol>
          </section>
        </section>
        <section anchor="parse-dictionary">
          <name>Parsing a Dictionary</name>
          <t>Given an ASCII string as input_string, return an ordered map whose values are (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let dictionary be an empty, ordered map.</t>
            </li>
            <li>
              <t>While input_string is not empty:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>Let this_key be the result of running Parsing a Key (<xref target="parse-key"/>) with input_string.</t>
                </li>
                <li>
                  <t>If the first character of input_string is "=":
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Consume the first character of input_string.</t>
                    </li>
                    <li>
                      <t>Let member be the result of running Parsing an Item or Inner List (<xref target="parse-item-or-list"/>) with input_string.</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>Otherwise:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Let value be Boolean true.</t>
                    </li>
                    <li>
                      <t>Let parameters be the result of running Parsing Parameters (<xref target="parse-param"/>) with input_string.</t>
                    </li>
                    <li>
                      <t>Let member be the tuple (value, parameters).</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>If dictionary already contains a key this_key (comparing character for character), overwrite its value with member.</t>
                </li>
                <li>
                  <t>Otherwise, append key this_key with value member to dictionary.</t>
                </li>
                <li>
                  <t>Discard any leading OWS characters from input_string.</t>
                </li>
                <li>
                  <t>If input_string is empty, return dictionary.</t>
                </li>
                <li>
                  <t>Consume the first character of input_string; if it is not ",", fail parsing.</t>
                </li>
                <li>
                  <t>Discard any leading OWS characters from input_string.</t>
                </li>
                <li>
                  <t>If input_string is empty, there is a trailing comma; fail parsing.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>No structured data has been found; return dictionary (which is empty).</t>
            </li>
          </ol>
          <t>Note that when duplicate Dictionary keys are encountered, all but the last instance are ignored.</t>
        </section>
        <section anchor="parse-item">
          <name>Parsing an Item</name>
          <t>Given an ASCII string as input_string, return a (bare_item, parameters) tuple. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let bare_item be the result of running Parsing a Bare Item (<xref target="parse-bare-item"/>) with input_string.</t>
            </li>
            <li>
              <t>Let parameters be the result of running Parsing Parameters (<xref target="parse-param"/>) with input_string.</t>
            </li>
            <li>
              <t>Return the tuple (bare_item, parameters).</t>
            </li>
          </ol>
          <section anchor="parse-bare-item">
            <name>Parsing a Bare Item</name>
            <t>Given an ASCII string as input_string, return a bare Item. input_string is modified to remove the parsed value.</t>
            <ol spacing="normal" type="1"><li>
                <t>If the first character of input_string is a "-" or a DIGIT, return the result of running Parsing an Integer or Decimal (<xref target="parse-number"/>) with input_string.</t>
              </li>
              <li>
                <t>If the first character of input_string is a DQUOTE, return the result of running Parsing a String (<xref target="parse-string"/>) with input_string.</t>
              </li>
              <li>
                <t>If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (<xref target="parse-token"/>) with input_string.</t>
              </li>
              <li>
                <t>If the first character of input_string is ":", return the result of running Parsing a Byte Sequence (<xref target="parse-binary"/>) with input_string.</t>
              </li>
              <li>
                <t>If the first character of input_string is "?", return the result of running Parsing a Boolean (<xref target="parse-boolean"/>) with input_string.</t>
              </li>
              <li>
                <t>If the first character of input_string is "@", return the result of running Parsing a Date (<xref target="parse-date"/>) with input_string.</t>
              </li>
              <li>
                <t>If the first character of input_string is "%", return the result of running Parsing a Display String (<xref target="parse-display"/>) with input_string.</t>
              </li>
              <li>
                <t>Otherwise, the item type is unrecognized; fail parsing.</t>
              </li>
            </ol>
          </section>
          <section anchor="parse-param">
            <name>Parsing Parameters</name>
            <t>Given an ASCII string as input_string, return an ordered map whose values are bare Items. input_string is modified to remove the parsed value.</t>
            <ol spacing="normal" type="1"><li>
                <t>Let parameters be an empty, ordered map.</t>
              </li>
              <li>
                <t>While input_string is not empty:
                </t>
                <ol spacing="normal" type="1"><li>
                    <t>If the first character of input_string is not ";", exit the loop.</t>
                  </li>
                  <li>
                    <t>Consume the ";" character from the beginning of input_string.</t>
                  </li>
                  <li>
                    <t>Discard any leading SP characters from input_string.</t>
                  </li>
                  <li>
                    <t>Let param_key be the result of running Parsing a Key (<xref target="parse-key"/>) with input_string.</t>
                  </li>
                  <li>
                    <t>Let param_value be Boolean true.</t>
                  </li>
                  <li>
                    <t>If the first character of input_string is "=":
                    </t>
                    <ol spacing="normal" type="1"><li>
                        <t>Consume the "=" character at the beginning of input_string.</t>
                      </li>
                      <li>
                        <t>Let param_value be the result of running Parsing a Bare Item (<xref target="parse-bare-item"/>) with input_string.</t>
                      </li>
                    </ol>
                  </li>
                  <li>
                    <t>If parameters already contains a key param_key (comparing character for character), overwrite its value with param_value.</t>
                  </li>
                  <li>
                    <t>Otherwise, append key param_key with value param_value to parameters.</t>
                  </li>
                </ol>
              </li>
              <li>
                <t>Return parameters.</t>
              </li>
            </ol>
            <t>Note that when duplicate parameter keys are encountered, all but the last instance are ignored.</t>
          </section>
          <section anchor="parse-key">
            <name>Parsing a Key</name>
            <t>Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value.</t>
            <ol spacing="normal" type="1"><li>
                <t>If the first character of input_string is not lcalpha or "*", fail parsing.</t>
              </li>
              <li>
                <t>Let output_string be an empty string.</t>
              </li>
              <li>
                <t>While input_string is not empty:
                </t>
                <ol spacing="normal" type="1"><li>
                    <t>If the first character of input_string is not one of lcalpha, DIGIT, "_", "-", ".", or "*", return output_string.</t>
                  </li>
                  <li>
                    <t>Let char be the result of consuming the first character of input_string.</t>
                  </li>
                  <li>
                    <t>Append char to output_string.</t>
                  </li>
                </ol>
              </li>
              <li>
                <t>Return output_string.</t>
              </li>
            </ol>
          </section>
        </section>
        <section anchor="parse-number">
          <name>Parsing an Integer or Decimal</name>
          <t>Given an ASCII string as input_string, return an Integer or Decimal. input_string is modified to remove the parsed value.</t>
          <t>NOTE: This algorithm parses both Integers (<xref target="integer"/>) and Decimals (<xref target="decimal"/>), and returns the corresponding structure.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let type be "integer".</t>
            </li>
            <li>
              <t>Let sign be 1.</t>
            </li>
            <li>
              <t>Let input_number be an empty string.</t>
            </li>
            <li>
              <t>If the first character of input_string is "-", consume it and set sign to -1.</t>
            </li>
            <li>
              <t>If input_string is empty, there is an empty integer; fail parsing.</t>
            </li>
            <li>
              <t>If the first character of input_string is not a DIGIT, fail parsing.</t>
            </li>
            <li>
              <t>While input_string is not empty:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>Let char be the result of consuming the first character of input_string.</t>
                </li>
                <li>
                  <t>If char is a DIGIT, append it to input_number.</t>
                </li>
                <li>
                  <t>Else, if type is "integer" and char is ".":
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>If input_number contains more than 12 characters, fail parsing.</t>
                    </li>
                    <li>
                      <t>Otherwise, append char to input_number and set type to "decimal".</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>Otherwise, prepend char to input_string, and exit the loop.</t>
                </li>
                <li>
                  <t>If type is "integer" and input_number contains more than 15 characters, fail parsing.</t>
                </li>
                <li>
                  <t>If type is "decimal" and input_number contains more than 16 characters, fail parsing.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>If type is "integer":
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>Let output_number be an Integer that is the result of parsing input_number as an integer.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>Otherwise:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>If the final character of input_number is ".", fail parsing.</t>
                </li>
                <li>
                  <t>If the number of characters after "." in input_number is greater than three, fail parsing.</t>
                </li>
                <li>
                  <t>Let output_number be a Decimal that is the result of parsing input_number as a decimal number.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>Let output_number be the product of output_number and sign.</t>
            </li>
            <li>
              <t>Return output_number.</t>
            </li>
          </ol>
        </section>
        <section anchor="parse-string">
          <name>Parsing a String</name>
          <t>Given an ASCII string as input_string, return an unquoted String. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>Let output_string be an empty string.</t>
            </li>
            <li>
              <t>If the first character of input_string is not DQUOTE, fail parsing.</t>
            </li>
            <li>
              <t>Discard the first character of input_string.</t>
            </li>
            <li>
              <t>While input_string is not empty:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>Let char be the result of consuming the first character of input_string.</t>
                </li>
                <li>
                  <t>If char is a backslash ("\"):
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>If input_string is now empty, fail parsing.</t>
                    </li>
                    <li>
                      <t>Let next_char be the result of consuming the first character of input_string.</t>
                    </li>
                    <li>
                      <t>If next_char is not DQUOTE or "\", fail parsing.</t>
                    </li>
                    <li>
                      <t>Append next_char to output_string.</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>Else, if char is DQUOTE, return output_string.</t>
                </li>
                <li>
                  <t>Else, if char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.</t>
                </li>
                <li>
                  <t>Else, append char to output_string.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>Reached the end of input_string without finding a closing DQUOTE; fail parsing.</t>
            </li>
          </ol>
        </section>
        <section anchor="parse-token">
          <name>Parsing a Token</name>
          <t>Given an ASCII string as input_string, return a Token. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If the first character of input_string is not ALPHA or "*", fail parsing.</t>
            </li>
            <li>
              <t>Let output_string be an empty string.</t>
            </li>
            <li>
              <t>While input_string is not empty:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>If the first character of input_string is not in tchar, ":", or "/", return output_string.</t>
                </li>
                <li>
                  <t>Let char be the result of consuming the first character of input_string.</t>
                </li>
                <li>
                  <t>Append char to output_string.</t>
                </li>
              </ol>
            </li>
            <li>
              <t>Return output_string.</t>
            </li>
          </ol>
        </section>
        <section anchor="parse-binary">
          <name>Parsing a Byte Sequence</name>
          <t>Given an ASCII string as input_string, return a Byte Sequence. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If the first character of input_string is not ":", fail parsing.</t>
            </li>
            <li>
              <t>Discard the first character of input_string.</t>
            </li>
            <li>
              <t>If there is not a ":" character before the end of input_string, fail parsing.</t>
            </li>
            <li>
              <t>Let b64_content be the result of consuming content of input_string up to but not including the first instance of the character ":".</t>
            </li>
            <li>
              <t>Consume the ":" character at the beginning of input_string.</t>
            </li>
            <li>
              <t>If b64_content contains a character not included in ALPHA, DIGIT, "+", "/", and "=", fail parsing.</t>
            </li>
            <li>
              <t>Let binary_content be the result of base64-decoding <xref target="RFC4648"/> b64_content, synthesizing padding if necessary (note the requirements about recipient behavior below). If base64 decoding fails, parsing fails.</t>
            </li>
            <li>
              <t>Return binary_content.</t>
            </li>
          </ol>
          <t>Because some implementations of base64 do not allow rejection of encoded data that is not properly "=" padded (see <xref section="3.2" sectionFormat="comma" target="RFC4648"/>), parsers SHOULD NOT <bcp14>SHOULD NOT</bcp14> fail when "=" padding is not present, unless they cannot be configured to do so.</t>
          <t>Because some implementations of base64 do not allow rejection of encoded data that has non-zero pad bits (see <xref section="3.5" sectionFormat="comma" target="RFC4648"/>), parsers SHOULD NOT <bcp14>SHOULD NOT</bcp14> fail when non-zero pad bits are present, unless they cannot be configured to do so.</t>
          <t>This specification does not relax the requirements in Sections <xref target="RFC4648" section="3.1" sectionFormat="bare"/> and <xref target="RFC4648" section="3.3" sectionFormat="bare"/> of <xref target="RFC4648"/>; therefore, parsers MUST <bcp14>MUST</bcp14> fail on characters outside the base64 alphabet and on line feeds in encoded data.</t>
        </section>
        <section anchor="parse-boolean">
          <name>Parsing a Boolean</name>
          <t>Given an ASCII string as input_string, return a Boolean. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If the first character of input_string is not "?", fail parsing.</t>
            </li>
            <li>
              <t>Discard the first character of input_string.</t>
            </li>
            <li>
              <t>If the first character of input_string matches "1", discard the first character, and return true.</t>
            </li>
            <li>
              <t>If the first character of input_string matches "0", discard the first character, and return false.</t>
            </li>
            <li>
              <t>No value has matched; fail parsing.</t>
            </li>
          </ol>
        </section>
        <section anchor="parse-date">
          <name>Parsing a Date</name>
          <t>Given an ASCII string as input_string, return a Date. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If the first character of input_string is not "@", fail parsing.</t>
            </li>
            <li>
              <t>Discard the first character of input_string.</t>
            </li>
            <li>
              <t>Let output_date be the result of running Parsing an Integer or Decimal (<xref target="parse-number"/>) with input_string.</t>
            </li>
            <li>
              <t>If output_date is a Decimal, fail parsing.</t>
            </li>
            <li>
              <t>Return output_date.</t>
            </li>
          </ol>
        </section>
        <section anchor="parse-display">
          <name>Parsing a Display String</name>
          <t>Given an ASCII string as input_string, return a sequence of Unicode codepoints. code points. input_string is modified to remove the parsed value.</t>
          <ol spacing="normal" type="1"><li>
              <t>If the first two characters of input_string are not "%" followed by DQUOTE, fail parsing.</t>
            </li>
            <li>
              <t>Discard the first two characters of input_string.</t>
            </li>
            <li>
              <t>Let byte_array be an empty byte array.</t>
            </li>
            <li>
              <t>While input_string is not empty:
              </t>
              <ol spacing="normal" type="1"><li>
                  <t>Let char be the result of consuming the first character of input_string.</t>
                </li>
                <li>
                  <t>If char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.</t>
                </li>
                <li>
                  <t>If char is "%":
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Let octet_hex be the result of consuming two characters from input_string. If there are not two characters, fail parsing.</t>
                    </li>
                    <li>
                      <t>If octet_hex contains characters outside the range %x30-39 or %x61-66 (i.e., it is not in 0-9 or lowercase a-f), fail parsing.</t>
                    </li>
                    <li>
                      <t>Let octet be the result of hex decoding octet_hex (<xref section="8" sectionFormat="of" target="RFC4648"/>).</t>
                    </li>
                    <li>
                      <t>Append octet to byte_array.</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>If char is DQUOTE:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Let unicode_sequence be the result of decoding byte_array as a UTF-8 string (<xref section="3" sectionFormat="of" target="UTF8"/>). target="RFC3629"/>). Fail parsing if decoding fails.</t>
                    </li>
                    <li>
                      <t>Return unicode_sequence.</t>
                    </li>
                  </ol>
                </li>
                <li>
                  <t>Otherwise, if char is not "%" or DQUOTE:
                  </t>
                  <ol spacing="normal" type="1"><li>
                      <t>Let byte be the result of applying ASCII encoding to char.</t>
                    </li>
                    <li>
                      <t>Append byte to byte_array.</t>
                    </li>
                  </ol>
                </li>
              </ol>
            </li>
            <li>
              <t>Reached the end of input_string without finding a closing DQUOTE; fail parsing.</t>
            </li>
          </ol>
        </section>
      </section>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>Please add
      <t>IANA has added the following note to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":</t>
      <ul empty="true">
        <li>
          <t>The
<!-- [rfced] IANA Considerations. FYI, at the end of AUTH48, we will ask IANA to update the following note:

Original:

      The "Structured Type" column indicates the type of the field (per
      RFC nnnn), if any, and may be "Dictionary", "List" or "Item".

      Note that field names beginning with characters other than ALPHA
      or "*" will not be able to be represented as a Structured Fields
      Token, and therefore may be incompatible with being mapped into
      field values that refer to it.

Current (two comma updates):

   |  The "Structured Type" column indicates the type of the field (per
   |  RFC 9651), if any, and may be "Dictionary", "List", or "Item".
   |
   |  Note that field names beginning with characters other than ALPHA
   |  or "*" will not be able to be represented as a Structured Fields
   |  Token and therefore may be incompatible with being mapped into
   |  field values that refer to it.
-->
      <blockquote>
          <t>The "Structured Type" column indicates the type of the field (per RFC 9651), if any, and may be
"Dictionary", "List", or "Item".</t>
          <t>Note that field names beginning with characters other than ALPHA or "*" will not be able to be
represented as a Structured Fields Token, Token and therefore may be incompatible with being mapped into
field values that refer to it.</t>
        </li>
      </ul>
      <t>Then, add a
      </blockquote>
      <t>A new column, "Structured Type".</t>
      <t>Then, add Type", has been added to the registry.</t>
      <t>The indicated Structured Type for each existing registry entry listed in <xref target="existing-fields"/>.</t> target="existing-fields"/> has also been added.</t>
      <table anchor="existing-fields">
        <name>Existing Fields</name>
        <thead>
          <tr>
            <th align="left">Field Name</th>
            <th align="left">Structured Type</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Accept-CH</td>
            <td align="left">List</td>
          </tr>
          <tr>
            <td align="left">Cache-Status</td>
            <td align="left">List</td>
          </tr>
          <tr>
            <td align="left">CDN-Cache-Control</td>
            <td align="left">Dictionary</td>
          </tr>
          <tr>
            <td align="left">Cross-Origin-Embedder-Policy</td>
            <td align="left">Item</td>
          </tr>
          <tr>
            <td align="left">Cross-Origin-Embedder-Policy-Report-Only</td>
            <td align="left">Item</td>
          </tr>
          <tr>
            <td align="left">Cross-Origin-Opener-Policy</td>
            <td align="left">Item</td>
          </tr>
          <tr>
            <td align="left">Cross-Origin-Opener-Policy-Report-Only</td>
            <td align="left">Item</td>
          </tr>
          <tr>
            <td align="left">Origin-Agent-Cluster</td>
            <td align="left">Item</td>
          </tr>
          <tr>
            <td align="left">Priority</td>
            <td align="left">Dictionary</td>
          </tr>
          <tr>
            <td align="left">Proxy-Status</td>
            <td align="left">List</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>The size of most types defined by Structured Fields is not limited; as a result, extremely large fields could be an attack vector (e.g., for resource consumption). Most HTTP implementations limit the sizes of individual fields as well as the overall header or trailer section size to mitigate such attacks.</t>
      <t>It is possible for parties with the ability to inject new HTTP fields to change the meaning
of a Structured Field. In some circumstances, this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances.</t>
      <t>The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters. Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See <xref target="PRECIS"/> target="RFC8264"/> and <xref target="UNICODE-SECURITY"/>.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9113" to="HTTP/2"/>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC7541" to="HPACK"/>
    <displayreference target="RFC8264" to="PRECIS"/>
    <displayreference target="RFC3629" to="UTF8"/>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="UTF8" target="http://www.rfc-editor.org/info/std63">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author initials="F." surname="Yergeau" fullname="F. Yergeau">
              <organization/>
            </author>
            <date year="2003" month="November"/>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC0020">
          <front>
            <title>ASCII format for network interchange</title>
            <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
            <date month="October" year="1969"/>
          </front>
          <seriesInfo name="STD" value="80"/>
          <seriesInfo name="RFC" value="20"/>
          <seriesInfo name="DOI" value="10.17487/RFC0020"/>
        </reference>
        <reference anchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

        <reference anchor="IEEE754" target="https://ieeexplore.ieee.org/document/8766229">
          <front>
            <title>IEEE Standard for Floating-Point Arithmetic</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2019" month="July"/>
          </front>
          <seriesInfo name="IEEE" name="IEEE Std" value="754-2019"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
          <seriesInfo name="ISBN" value="978-1-5044-5924-2"/>
        </reference>
        <reference anchor="RFC9113">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This specification describes an optimized expression of the semantics of 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>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7541.xml"/>
        <reference anchor="UNICODE-SECURITY" target="http://www.unicode.org/reports/tr36/"> target="https://www.unicode.org/reports/tr36/tr36-15.html">
          <front>
            <title>Unicode Security Considerations</title>
            <author initials="M." surname="Davis" fullname="Mark Davis">
              <organization/>
            </author>
            <author initials="M." surname="Suignard" fullname="Michel Suignard">
              <organization/>
            </author>
            <date year="2014" month="September" day="19"/>
          </front>
          <seriesInfo name="Unicode Technical Report" value="#16"/>
        </reference>
        <reference anchor="PRECIS">
          <front>
            <title>PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="M. Blanchet" initials="M." surname="Blanchet"/>
            <date month="October" year="2017"/>
            <abstract>
              <t>Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8264"/>
          <seriesInfo name="DOI" value="10.17487/RFC8264"/>
        </reference>
        <reference anchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified value="#36"/>
          <annotation>Latest 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"/> available at <eref target="https://www.unicode.org/reports/tr36/" brackets="angle"/>.</annotation>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8264.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7493.xml"/>

      </references>
    </references>
    <?line 1069?>

<section anchor="faq">
      <name>Frequently Asked Questions</name>
      <section anchor="why-not-json">
        <name>Why Not JSON?</name>
        <t>Earlier proposals for Structured Fields were based upon JSON <xref target="RFC8259"/>. However, constraining its use to make it suitable for HTTP fields required senders and recipients to implement specific additional handling.</t>
        <t>For example, JSON has specification issues around large numbers and objects with duplicate members. Although advice for avoiding these issues is available (e.g., <xref target="RFC7493"/>), it cannot be relied upon.</t>
        <t>Likewise, JSON strings are by default Unicode strings, which have a number of potential interoperability issues (e.g., in comparison). Although implementers can be advised to avoid non-ASCII content where unnecessary, this is difficult to enforce.</t>
        <t>Another example is JSON's ability to nest content to arbitrary depths. Since the resulting memory commitment might be unsuitable (e.g., in embedded and other limited server deployments), it's necessary to limit it in some fashion; however, existing JSON implementations have no such limits, and even if a limit is specified, it's likely that some field definition will find a need to violate it.</t>
        <t>Because of JSON's broad adoption and implementation, it is difficult to impose such additional constraints across all implementations; some deployments would fail to enforce them, thereby harming interoperability. In short, if it looks like JSON, people will be tempted to use a JSON parser/serializer on field values.</t>
        <t>Since a major goal for Structured Fields is to improve interoperability and simplify implementation, these concerns led to a format that requires a dedicated parser and serializer.</t>
        <t>Additionally, there were widely shared feelings that JSON doesn't "look right" in HTTP fields.</t>
      </section>
    </section>
    <section anchor="implementation-notes">
      <name>Implementation Notes</name>
      <t>A generic implementation of this specification should expose the top-level serialize (<xref target="text-serialize"/>) and parse (<xref target="text-parse"/>) functions. They need not be functions; for example, it could be implemented as an object, with methods for each of the different top-level types.</t>
      <t>For interoperability, it's important that generic implementations be complete and follow the algorithms closely; see <xref target="strict"/>. To aid this, a common test suite is being maintained by the community at &lt;https://github.com/httpwg/structured-field-tests&gt;.</t>
      <t>Implementers should note that Dictionaries and Parameters are order-preserving maps. Some fields may not convey meaning in the ordering of these data types, but it should still be exposed so that it will be available to applications that need to use it.</t>
      <t>Likewise, implementations should note that it's important to preserve the distinction between Tokens and Strings. While most programming languages have native built-in types that map to the other types well, it may be necessary to create a wrapper "token" object or use a parameter on functions to assure that these types remain separate.</t>
      <t>The serialization algorithm is defined in a way that it is not strictly limited to the data types defined in <xref target="types"/> in every case. For example, Decimals are designed to take broader input and round to allowed values.</t>
      <t>Implementations are allowed to limit the size of different structures, subject to the minimums defined for each type. When a structure exceeds an implementation limit, that structure fails parsing or serialization.</t>
    </section>
    <section anchor="abnf">
      <name>ABNF</name>
      <t>This section uses the Augmented Backus-Naur Form (ABNF) notation <xref target="RFC5234"/> to illustrate the expected syntax of Structured Fields. However, it cannot be used to validate their syntax, syntax because it does not capture all requirements.</t>
      <t>This section is non-normative. If there is disagreement between the parsing algorithms and ABNF, the specified algorithms take precedence.</t>
      <sourcecode type="abnf"><![CDATA[
sf-list       = list-member *( OWS "," OWS list-member )
list-member   = sf-item / inner-list

inner-list    = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")"
                parameters

parameters    = *( ";" *SP parameter )
parameter     = param-key [ "=" param-value ]
param-key     = key
key           = ( lcalpha / "*" )
                *( lcalpha / DIGIT / "_" / "-" / "." / "*" )
lcalpha       = %x61-7A ; a-z
param-value   = bare-item

sf-dictionary = dict-member *( OWS "," OWS dict-member )
dict-member   = member-key ( parameters / ( "=" member-value ))
member-key    = key
member-value  = sf-item / inner-list

sf-item   = bare-item parameters
bare-item = sf-integer / sf-decimal / sf-string / sf-token
            / sf-binary / sf-boolean / sf-date / sf-displaystring

sf-integer       = ["-"] 1*15DIGIT
sf-decimal       = ["-"] 1*12DIGIT "." 1*3DIGIT
sf-string        = DQUOTE *( unescaped / "%" / bs-escaped ) DQUOTE
sf-token         = ( ALPHA / "*" ) *( tchar / ":" / "/" )
sf-binary        = ":" base64 ":"
sf-boolean       = "?" ( "0" / "1" )
sf-date          = "@" sf-integer
sf-displaystring = "%" DQUOTE *( unescaped / "\" / pct-encoded )
                   DQUOTE

base64       = *( ALPHA / DIGIT / "+" / "/" ) *"="

unescaped    = %x20-21 / %x23-24 / %x26-5B / %x5D-7E
bs-escaped   = "\" ( DQUOTE / "\" )

pct-encoded  = "%" lc-hexdig lc-hexdig
lc-hexdig = DIGIT / %x61-66 ; 0-9, a-f
]]></sourcecode>
    </section>
    <section anchor="changes">
      <name>Changes from RFC 8941</name>
      <t>This revision of the Structured "Structured Field Values for HTTP HTTP" specification has made the following changes:</t>
      <ul spacing="normal">
        <li>
          <t>Added the Date structured type. Structured Type. (<xref target="date"/>)</t>
        </li>
        <li>
          <t>Stopped encouraging use of ABNF in definitions of new structured fields. Structured Fields. (<xref target="specify"/>)</t>
        </li>
        <li>
          <t>Moved ABNF to an informative appendix. (<xref target="abnf"/>)</t>
        </li>
        <li>
          <t>Added a "Structured Type" column to the HTTP "Hypertext Transfer Protocol (HTTP) Field Name Registry. Registry". (<xref target="iana"/>)</t>
        </li>
        <li>
          <t>Refined parse failure handling. (<xref target="text-parse"/>)</t>
        </li>
        <li>
          <t>Added the Display String structured type. Structured Type. (<xref target="displaystring"/>)</t>
        </li>
      </ul>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Many thanks to Matthew Kerwin <contact fullname="Matthew Kerwin"/> for his detailed feedback and careful consideration during the development of this specification.</t>
      <t>Thanks also to Ian Clelland, Roy Fielding, Anne <contact fullname="Ian Clelland"/>, <contact fullname="Roy Fielding"/>, <contact fullname="Anne van Kesteren, Kazuho Oku, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and Jeffrey Yasskin Kesteren"/>, <contact fullname="Kazuho Oku"/>, <contact fullname="Evert Pot"/>, <contact fullname="Julian Reschke"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Mike West"/>, and <contact fullname="Jeffrey Yasskin"/> for their contributions.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9V9+3fbxtHo7/wr8NEn11JKUqJetqQoiWzLsVo/VEtOTtr0
+IAkSCIGARYAJTOq+7ffee0TIEXacu53c9qEIoHd2dl578xsu91ulHGZREfB
ZZnP+uUsjwbB8zhKBsHPYTKLimCY5cGLq6uLxiDrp+EEnhzk4bBsx1E5bI/L
ctqLi3YxxH9vHzQGYQlP3D47vTr71OjDH6Msnx8FRTloxNP8KIBJinJne/tw
e6cR5lF4FJxOp0kMT8ZZWgRhOgjeRmHSvoonUeMmyz+M8mw2PWIIPkRz+Gpw
FJynZZSnUdl+hqA0sl6RJVEZFUfB48O9bqNRlDDQ+zDJUgBmHhWNYhLm5ft/
zzJ6KM0a0/go+GeZ9VsB/CtOB1FatoIiy8s8GhbwaT6RD2Ue9+GnfjaZhvJh
Ag/DT3GaxGn0r0YD/ozL+VEjCC7PXj4/Cppvnz8NUvin2WiEs3Kc5fBbG34O
4B2Y/lUneJ2VZZyOxuGEvma8vgrzD/4vWT4K0/gPQs9R8DTJZoNhAoijH/s4
bXCRh+M8TOmbPBrRgz+fP+Unslla4gacAtrzMIlD+jqahHFyFEzSrPwR/9UB
XNIPsxzwgptaHG1t3dzcdNSvW84KLtovOsHfwsnUgv4imyXtF1GaAvTmNxf+
q3EEZJWncTEOnoZ9+Osiz36P+qUN1XT84cdrfqjdx4c6MEijkWb5BIa5jhDR
SA5HAeD5sNvdbsAX766ePz6iUYSc4Yv241YQAsWFaTHkl7M04E9BNgzOL98E
3e2DvQN6TW8U/NPmVT7vBL9G+SgKZ/StWqj3NVM8kPRuu9ulb4ooj6MiTofZ
kbx4efXsKDjYlb8A7KNg92DnkOENYaySsS5Iz4f9djSIyyzHpW/hSFvAQTBA
Az9beDg/Ozt7tL93VBkJ9y+OoujjNMnyqIMfaSxg4hnS79bjRwcHOwoERhkO
BmIAWCfMB8T3z5MsRGpsX2RxWganeVyOJ1EZ96sok7W5+40jOkjqHra3Hy1A
Ej58FMBq2vicfPnszflRANvUgX0+3MJHAJcdfKBjrwDevnzy+ig4fPS43W3v
b+/ttfcPd2AkpA0mk12eZxAX0yScs0TZ2kFaujh9+jciJpgbd/Dd6/Onb56d
tS/Pnr57e371q0tXadzPBlFwGfWBWcp58BTkVjyIcpZgNbRkMfez8Dou3K9j
IPAkuJzFoxSw7iJrr7192BZUVPH1UIFyFfXH8DFMQHROQYQ9PAoePugePFxE
XjN+j+ghpzeKrTLfPQAeDy7enj09vyRsPN452Gs0rqN0RqRmC2IYdj4FGH8B
AY3s/hP+Bt+OM1yToj/8782IpoHfmLm11mjfjH682SXWBoTl/bF5L4mLsujw
j1un8BMQe7F1MeuBntiyB8BhcQHm1REQ6KzXASEts9N/2tHHMoJdgv3ZSsJe
lBRb4yiEPWsXSuk1+M12XBSzqE0Pwaj+Q41Gu90Owh7KUhBajatxXASKpYJB
VPTzuAc6M4TtIhkDWxkSrli1hUUB2ga2Fz4moBmRnYqgHINAApkOUgfAHMCP
ZQbo+gBflEEUFnGU09tFOIRP8NsgGoLmoe/G8K8kol0RcOlrgC9O4PMQNTno
qg9pdpPC9EHTV/NFs+V8+YIGwW+B/+0frnjIotkJzssA1q2hRUkxK6KgNw+K
adSPh1qdAwbS6IahY1B4sTeoAGAh+FZIKhUkczFPy/AjPwDDT0Buwe6yAgYK
wB9SXBgIRhgcqN0MG1yTrdLxd0QbBkjPZBt0ZA8n8QDw1mg8QFsizwawShi0
0bikBcyRqEtQTwKTvQ7B8oaF5k21uBi3OQCrA/gBlhoWH46DCDgIFlyOacDR
LB6EaR/3Ori9BSFCSql70Nnt7OA0OMWnTy18FpaPRDEJ0znseD8m+g2Q/mDm
aVwOwyShvxH/YTDNM8Q+ocrCDMsiWPYbnDWUbxFJRESDVgAEO82A2KZhDkKG
CRWlDVgLf+Df2RD2GdbPdNmLghugW/gK3+yHuIURaGl7I4AqiQeSeDQuE4A+
HgLl4oYQuSJyYak3uNFJln0ogiSG+R0yqGxlLNtkc5e8QUymmbTQ9AgopkXG
C4hRqAZXFQ4G8CZSZwQvAip7STQpgNJTRAsovBkYXS3kR0YbAjGKYJ9jsCCV
PACSHYAsx+lhnAn8AAboiPceqTzt50CLGrfaHglAS+PsTHShGgfAJ1hvb5ko
FvM3IOs0tRemeEj2OKDtqHJ5cwGPN4ONeEjkysP1gahh36MYqZKwEPsDkixp
biLeCYsi9BQAsJYSt9ORD5Yoi8tC8RourwdCr2+IJZ8lUSE8gUImnoDLwEza
ywC5+LbZ6YocIoJVlK0HhadwnAipi8UVonGgpEsybwXDGS4uuIZ3FQURkhEf
SgYn6ImQPeZuLD2NiPCog78FIjMEi4SSZDcIlC0kkYQtcmDeI2t2gvw3YAkZ
DWGZMawB+AwpLZuV8BxhLRLsw7rAq5DBePPAqkcKzkIByOY0mEi96snA6CNo
ZhzaEujH9MwETBCw+4pJobUgoBq2CzYehViWAni2eoOlwPoGzBz2qtFihQXh
crIpsX1G3ASLuL3lbZ0DLxhdO85ucED5CVblUyW9SeRI7yn2TWeTHnAQLEvv
kKWtCRahewIUFlJRnSSkssLaY35Z3tNCdMDLILmNQhZUZp5NaiTRrFCKxzIP
DEJJZ5RgzHz6hHrsASkv9D6ZYBFA0JXoU/VFnNw+YP35ScSpyxex87ZCDb9B
kOIQtjrg13rRGOzYLFfwFmU0bffmbfyvBThTBu18lOcgaTTraalAsncIMoce
RViQVqZiTCNzZWC8Ah3Bcs9FohVgKTMNRSm4t3k4inCIcjycJR5HE+yjLCP8
g07GgXtxAlZ7B11R8PCBg1qosr33aPcBDZpWwUaf4vggNJi5iPdKMC6AH0kX
xekUOO8GnOCB2G7elPAbbH0LpBcqYjaD6GnQCmARBqQCZsQrQYZr9sUTgqK/
QiEYg04KNnowLepPQHMx6znqdhPn/BCCMZISsZ6rkTGKooMbqO4UvbABY9FF
MATgCKphjQQ/RnFCwgtFStoGHUfuKelrxAdjD3yufgZSFDUR7Eg/y3MwVOAv
QCdu/JQ1OyjCMAf4yVK+zmIQCSzefUwySYr/RRa7MOwEDQ5eI5iYZD7OktKR
f6QK+XuzJsID0D5GdYa2kRROp0ZkzYMJvBXDDrBRALNuRJ1Rp8UQTsBlD9FJ
Q61qTB6MHIFFmJYFa0GUCzBkvkmEx5wRk9FIo84fFmJExYXaV5icDS2LS2xz
SzGRsKzIBlhzKJsIPuo172iBgiAKPkRzJoKg+erd5RX6APjf4PUb+vz27O/v
zt+ePSPf4MXpy5f6g3ri8sWbdy+fmU/mzadvXr06e/2MX4ZvA++rV6e/Nlu0
hc03F1fnb16fvmxq+0AroZDYC4mHcDtFy4nsGEcaPnl6EXT3QCj+D9j3O93u
IUh4/uNx99Ee/HEzRjsVJyM5xH8CFue0syFhHugX0AsGdZigKgZyGKOzhPKh
YoVq8+bnpy9O37aCy4tW8Oz8p/OrVnD68uLFKc/17O/v3lydsdnCov729gcA
an9nF4GytBVoTdQbYpxsseUY58wiYJanA+TK08un5+dAfyXaCoMISZJs6BSN
StQH5JIZ0wtHJUDe/HLpQiGWpJio4FFOgOpm+RSUWP1abTfVgL2CbugEvwCy
9ZOewkNG86Qb0R+8HOkxtBkbw3rJ8JiB3xiCac7DDTNlNrkaE1byHN52AQPo
nekrSlbbOyCbKMaLbH8TEveJgGJDJDj3IT/9FRgxnzNUhFcWkijh1FqKLCBv
IOQ9AjMN5SMJnxgJkGUi0Ch79EY2KlQrWOvsgTaZFWIVBM/IFIZ3XoO7UzFa
0CYQMwp23DKcHA+CxKT/bossbfYoC+URHjUa34KskaAkLADUKko+QpevMDrB
W/hrGpM4JO2MTlRYZrm2l3l+5W5i4ELUMW3Nv2cg/CgAXzVcOYSCFjFgsoNg
nWNcHxcHjE+Kz0wQewt8IW593Ik65OL0yZNP5rYFiK+LF1aI6w7+N34rrmg/
LCIU7EHVqQo2xAhmHpUvZZhNCrdUMQ7qHbTZJi1GQhPau3IRRprgWHy04CXw
S7Bxe4uhtE+fYPRnMc2DVApfD/Rf9CNMfV5GE/wFHKUJfEcTPrN8gAiVetwv
aiZ1gMNgRaidKJRPaBnHuF+zaZb675K8vYmAAYQv8AXYZCSfgsQ1fIsWtj0Q
7jPwVIJxNJRa8ykGP9FhI3qYRGGqgmoyl+Uc3iC3FTYqs2k7ia7Rw0Kkwn4i
8myMGQRJ8KVEuCzPlSwgkksm1Fe3cpAdz8ndD1GCIJkIMTl+Ou0dWzIkDlE/
oZ0/ggcnETothVDLJCa3jCY9rh8tZcB5OIKTiRpdhXRUsL4KLa+Xfy74Z6D9
UcwnOjqClUTgfOZB8+8cIlRPAl3D4FGOHNCBNXyI0AJrAeSp0GNB9IV/toUs
jWsIxBAPeL9r9szyCcXYFI/wecVdjmDfKMAvK+RNxXnCwXVcsFDpw99gzSdz
mxBA65p9lBB5QP+a4uEHIHho713hBgpxdnQlUVUMY6Whbm85nk6S+bm3rMKI
GIa94p8pNV01+VriwWPwnh0WELnZsKMCmDoCi1OQQKYolxKuqPY5JlQYgSPU
gz+inWb9ooSV/IRBI+tXM2aTBp0CCqY5RrltOiCjy0CDbGObsIugoV8XgKN+
q4WHf8Rx0wi9G+DjTq0TrNzeCWzLZDYpNNaTKB0BzcNfJlQAaj7G0K4VbSxm
U9wF1th+RAntskEWccBFEdsk/IgzgQv3R0SMM8mKklQH8CO6c0rDgiGKDiIo
oPCGDGKkc1LSvvE0INcQBaWCMAH/EJWkuBwwFXupg/g6HszQsbMMoRJchcRa
pvrN2KR6BIseZYvwAVebdcj/OGNWaTROYTz4viS4nmdZW35RA/CGsYjq2cZT
WIBx8V0vyfof6Oj++8Z35fd7Ox1nEFHcxF3fbZXfN/Ah9HGch6zIvcQ00SWa
I/rN2XDYw+gZWP+Nyaw/xgEkuAXkM6KodkfPYI8eG0FbtSiY7f8J5j+mBPwL
SUI8vAaZvLi7qRbwG+pIYLez2+kiwvWbm2ZyPQRtKKZZsPYMJ3jej28h7GJq
CPgs6sGwwVkbPTSzy5sIBO42/dDdRje2n8wKsOKOJU4gYSmCkzzQRnX7JeLM
vtoozWDpHWcfjJkOVipICdQeJjZ9JM/OEtjdJP7+1HrqhlQ/+qrwfHOYZbM8
Ed+Rf9KOcijivhG4GNx1MdiSbVdSG7H07u1LeEsxvSCrE1xGiCHUl/iTFSKx
bVBYKIDc+G4Locf1KiDJMQPlj5C9e3veNjaxBm/PbO/u4eMD2N7gfNiIS8v9
ZxnPutEZpVXDhrQPmqTUTsCYgTMmBj8SjlfXArXTcIBqKYrBQUHcZck1kLZ+
ft9dAjyEIbUGx8jQarYZRmtPtedhXmKA6nvAv8VOR8EO6lrE40lTHezC3x15
m053m4B0/fp3W7aMINlDYZUXEnBsNFxfFIRV0apqVvQ0GW3BRgHb7/pWsD+1
Ghw3CYNbeTxgJW7OxQYZhUczCfRNwcNLZoPIOYOQUyR4aliikD82mpJMA7DN
FhnUG45BIpIehDiNl4fpiAS2SBa2Sp+BaJ2EavUmF0bMQXrmKvsQpUoxsD2L
DMweUGjZxSpSxeaoTC4aBIVhwS+g7YcOBe0BYbqtNPBCs75+dwDwTG1RC2y0
RI7sqhajUuosxsxBks27ri1OcT9HpHnnZyLgEUMyjJJ6RnyL+la2J4wAWx4B
r5HrbOlzRWd6DbANNOvDYoHhq7RiYcKbEue7ALaM8muc8IzzHDhMCrZgxfdH
HNshdDzVk3cQCfpA9+MU001QNIx1QIyPZ+g0G3fSHCQhywO/pOpkUB0Yi9lF
2QzZgL1DIuaAz3Qse9s6+3NcTR2KTfkEtcxBmaCNFxZjNjSeYISYqQ3ftt0N
dnculDopZBsjG0nm5Oq44j2yUyA6EBkSSTPXOJOwcNgn3x+TdvhUwLIoiKwo
lNEDlXKVUZAf9opY7wazrCivsBRgWrJaL4uCNg1D6HTYIYdHAxXk4QA6DIu7
hShLgaowhjVK6ejJqFNZPonGPoYWxVZ7vmhSj84ltiCc0BI/GQazggultUYH
0Z3AdtYQiDQCe1CfOwmTMcOS0yaxdWEtdhbDogD5pgDibZeQDUd1vS1HuQNo
H85yBp1PWGR3YbddWkARcw3KgUhSrCc+A2ajwzlzQtGFsrZwElmmmG4iqRSe
ld6qc22RrIwTCmA1R3kEnkDT7FtBMmYwYA+DDw9Aep16fkyfZEtRxtMZ0qkE
QJLEHkjkDIoohXWgPjzBlv2mjRuINRQXvC4V8TBrR/db9qCgPBtYRIahZHFH
gQyRdiLM4wrI58IDNMKUIWSUjSoUSCSNx/QU6lT4I3C1+4SMhtYtAmd2uOry
6miAJstY+Jf0B5MIDlLLg4hjpnudjuFzGEaBTNRK/FdEEoUaTIoXhUzg4VnK
6Vcf0N+wbbPLWY+DXaXPfQgt4dxT/ziEE3uwFagEmXwnnJJDdAYcxwEqcUY9
ofC8kE9ad9xk6a/enAxK2UdBPREoppGycjZTx8MaeJVpaqXWwHy44bDB7Em+
K2qi2VdkmgCXnunkPtAGosBqOA3FcMHJDcrsDTXaKT8MaaKiMh07SAsHK8XI
WNcIN7ndkWg4dFGcDBjADkxUiQIyrDfmeYZYA1p4gW7cLA4NqgNAIXlG+DNi
fxKht7eolyjIe4MhIgqz3D2dypYT+9YYBnHJAVTKRIlCOZOLU/ZRNkRU8ME6
sTrwVzTYrAmNcCwh9ChfhWgIjSoJAJkWiwQ4VUuSckxKpxXZ8mJ0aql+OhQx
pnVMkfkLNsFEhUqDAhJ0lujiuAWf4tBRAR+MmSGVMMuUFwlYhHW+AJP6Gk1G
d2+9HAf008P+B5RTRVsJKiBAWoKa4tgTmRrVRfXUhPIKtTCkt8TDrFqLPokU
FtKshMp30xFmZZLkrg7ip1ZkKmKGOTjRDcCcR9eU3KjCS65e2ygwFhN6PAAk
xR4LCees0DqcaQr3yM3xo3yLiMwzXi6qk5ygFmsUkw8w1RZXpoJRfRzICk7L
DtK5g8PEykxFuQfY4fclCIByBu1b0EZ0TiEDEm3ZHEq2NWZwjcYLPQJHGyqz
E0dCi4CIjmjOQzr7n3aOQMBY9eA2VM7WlAhiX4Z5R3rnQ4/sZFLE9oxoQwlE
P/ja0uAwhHjYB4D1I4pciFEhgVGmZMzbwOcJeSz8lEDKo991VonnZibZCBM1
0TkTeohTJ+uMDiJ02oiJAgjpGRVmjKlN2WREEOa4wJc0u8hAJ6pZaEXP54mw
edFUPWzTVOOBzUHPMB+N9dztA85gUyFsib/Au9fxIOK042v0AkFJ+omHVkZb
lT1nhRi3I8yyB4oAvoqGcsg81VlUQugktjHjjlJ+aSIUEaIe82rOG0ZQZk6u
NhCqSmKznFoEGFCIkRk1hSZBO2fOSU5eMgclO4F9PgGnhE6or3RCdTnOI//Y
T5GBcwYuaXzGPzlix7LlWJaMPXJF6CRUfE8Mttj2J84s8gCI51icSznPU1Ox
Q4Onjfap2c04RjLM2e4uooQ2Ks/DeaFDLXxiu8QZlhm04UzoIy0CNuUWc9I0
jMmgRpuL37p9QEd1jYasilCoJv4jyjMElrxefTKpKIOhlmlV9MScMNMJZmqB
WDkdbHH2lz+UuwJ4iViSz6zR0J1MQQvQgKRKgT1ZJNAJjFCO8psl14H8JHFU
KLc4skMyThiI8SDGF3wfYh4Zz6kOwynOZdEo2VxVGhVMMd4oESTClZTKqkbx
HnLq0lSsf8ADCPpp2I+WmpA61ls9VgZkcnhP3EVMv6csM+CR//73v1RH05YY
eEPisW188wiYaYQp8GUUtoJ8NsHH7bw6Q2WEHJe8C8ApqqwcFLVJoks4RCdK
H88kF54oUZ7AFP42NRP7HNznjCbP8CudYwekWjSBAC8ggT9zpbARa7zo/aBH
0UafdRCnkEThLtolMULRuw6HlNhJ+FMHNoS346AaoiYkiBQFQryQgg4K3yuj
S/aJJRFhpwwS8AvKoLu9s6eAUbHuGrdUe3C2Y4QJDyFaUyEZYe5JI61J9C6n
eSgXW0KYDxxJdfvAEgPE05aQ4KM2kkEVESThIJPEwvIQwbSgMeIRf7CHLkG0
DlcRMz6Hk4lXx+FONJJCr1ocFbOc8nLlXAwIcwxmv2gTJ/LILyrHsjenVFG1
ZpIGFA1aXQLYUFmx/7UlwgaedjWDZi/MmyCtN+DDH+pDCd8DnPTnpi8r6HQd
SU4Jv1RF4+zzVJaqBliU726Eft3Fkrqz48ElqxiyAz4bAeB9nXSPeyc7m8fJ
dXKyzwjICTGAD/qyyyio5UhHS9fw5c7+wVdhS4v0lQhawJ0Wym4fMB/QWjQe
c9Lw4E5RjvcknOJUYFe0LbvCGNp+iKzeOFhiGVD2PofTcLxZGv97xi6xyrDu
ZyY/7sKOf8Lisn5/lsvTmt1sZutRImEltmwZX0ZAT20xoWSySaKrpIrixovR
Tl5AQeELC0QiSAyXpINIiqHmuNRO4IU5MeuUzmo4Ks/nFqhD+n1dS0ZJUobv
pu6WyX61VGGKHBMQXmWFyoMFUuXULkn/KtaRgqFZn2vnkEWP8TPafnfPyfCh
ldnImVPx3yTuZwl6nvaZ8p3cGvb6x8Kpx0F/EL3f2z8AXh2N4+PfP5zsBcnm
8b9PmofN4/zkRrOrmtkTNU+yDJgzVefEPf4TKRccrIi3OQOBzXgXP9XFl2fC
IQ02Qyvsz5EaLJHJMd8LbL+EY1LNXtPNpBiGSbF0/XKEchRgpOg46J38sF0V
yXRYqQNFdI6XUjqgm0h9bOpEUf1Q2Ms+J/ITmVkcIVIsLKAxSPn3ckSsl7PI
anGEoUXG5J3WkA/TtHrbo20WOmrEgz0rC39lAUu84wlUA5ef1qqV+UMlmTWy
B+JvOc7i7QMrQ7fRqDiSlqQtakStBHsJUC0lizGiQvFnYR34e+LPN6PIU3O9
zbVdM3G/5bl6x9EYPr5kr5Pq9pmjL9VXF7wOZu9X9GqdDWaL0JxED7RtY62B
uI8PmZSVh1Weaiz7FGY1R9VZ2VJ/1cqfDusOoDnAZheE2if0Lgbnfl6sSh1B
st8oNslDqfF9enNr6x3usTL349wcwxlpNUBKUi6yU19Ae86xPD2RTilTBKZQ
hgc6fE5XzSx56OeM6r+objIu3KzklQMAr5TZZbE0pltYr1K4qyYuQPRUGxjg
Qe/Q4rbE+xshIx3YMsCZs3nSDDZUbbGZanNl/Ys0cgQ0fNLEZk8RbE+zFQzC
k6ObvX/EvZ9+3r45+Md88NO7kyNfLXmegXj2aM8SVGj0c/0bO3mUvsgHCWHw
ZF5imxYuJlCmWS/mqgfYplcOSXxF1U6ij4QLqm6qfOs3OZ6Xz1ZAXAj6GiRu
K+hTXtwJ2Kf/D9S3wstCNW5JM92O49T+VhohiNPnZ3A6br6OU92NnZw6FJ10
O+B4DaMI87yKk43fMxBF4QBrOsX9rAWFCyhqI6YtPn2gJ41mX2W3NrrBDkYv
T3Zhy072jsPwpAe7NzjZ2A8ONo/p9MffwEquwteIot1TlIzXiZTYbaGzdLKz
SojMesv7zhrizviYtYdfM0rmbseiYJkXOScK+qoWprV6Yzata2kytd8+IPOO
42toP1uRepWLjm43faRofKiyR+nQkj/KD5LvCN+zXSlfEwvjtyV+kC8dsYw/
KpHMvyrpa0teKXfyDkypuMKkQpigguUfuHG7+uKr+hwBk9qJyFG/Wtjhk72V
okXa/9pnKs/ydcSKedsT/xI5lfReDJvyZuHZl3wphp9OBm4fHh62vP/jUuu+
1tUAKgoym1L+RTwskb8G8SgmKUm5CrBHyFbUQu7R/p6XU3V7K43quBBqNatB
r3tPhINeVYI9zSjXIQ26+wKJ7rqh63HItcR6mIhjXzfgwngisDdXCRuLaHgZ
uXLfJe1cijMq9MHhrn7JaafgvIQJJ5/3S+rH9As59JwxywkMCVky2owwW0vE
ArxAwWJ0nnTjgeb29vYOlke1t7vNTTYXOXeEfKwN+B5DsCV1nOEi6j4LnEk4
V0fXU533V9sTxygpMj1J15uk8tyujjUn02AyY0MqKe9DnOcAvzRwOHbTCzgd
QsTeDfk5lECrwo8qaR3dYhE74BOrL2mUmZhyEk4UTuB842CIolelz0szBg4h
quf019y5quSKrO6OkBZ3MqkbxnmeD5b5lYXSZlnMWsnXNQLR8gowSUeEy910
pVF3B1119oWyOru7e0RGaE5Un93v7Oxu86OdPaK3Ch3Kk/DAfdIjO6N2lb+p
kkc+jvK20VMBt0FRjVpw6dzEhdrKWVuHogJLNTgnSaUB19LQOaVb2z2g9JkO
anIgrrlK6Mq5qCG2q/qsNgFz6zzaSveBfePABhfWuKtV/KEOcLjZD0guyvzn
8E7uRVum8H1JKYzcVIK7ZcBmb4NhZHWjMIFvUR7ffNzZRnC++fjobJMa2Lp5
1FTZgj3veqAT0uiGzK8WHj8AxJTsW85yLCuJyj5tYtpmCOwWGCrfKBYfxJHl
umTZyVFS+Z6m9KTSLoY7xDBVttvSciq6QaCjKVMfdtGz08UGGQFikmGNYy91
D7q6gbvvee1YuMyMeuLIKjPqqUNWlFugTOX49I3WO1qVKfpYJ9pub705NqRF
D7IZ7jy3QW5pzYcJhkUSFmPQF7/9BmoE89xBX00j9w1pzSYPR8XK/j+DdBQ0
x2CoYjVUngyavgek4NYF0dJFhSSjWkh+jP2TRgYk2Sj5XQ0CkHHG/4QaPNGQ
ajh0v2GVuqkdLXSgKh5tahxSnTs+awogdcKa9NxZ5ECo1WzwKNLDMUPRsOm5
B+RKWA6CcLXkadw+YOMZ6xjoi2oslxv5EBKpXl+rwTCZjsMe9us141O19LfN
lnh+LHtIRFDT0RRLONBqNwC1AicBiX1M8jao9ZkZhQ4n6O1mcPrk9XNqPWMn
D6r+M61gmsw4vtY8kojIVtPFwYqkRUght7K7s7u1t3+w5KBVEOhifx+0vDOx
oUgL4WoRZHmKQeOauLo/AjWR073+6lrmsSRChafki5Xhj03UdElJLCmQlbLy
U9PFiqStCgCTE5/qSiEZRnGFUJZj0iKFiUnbaHi/CIuwMIsW9sBb4yDQtaZJ
NToSis71WNDgMjBxlKVULywi8KNBWIK62jvYe9wKdM0q12auRi8IgJr/KDjq
v/hrMvjp59k/nj7ZDn9K/jin//912ps8n0eXT37v7exv/+OX/e2XoxMVnKwl
LQ9xHoMf7D7eAz1eRqWSKkoW6C1hX5c2Q9xeLG2zIm5fZTdkAmmx1LeO5LVZ
2PzBYkxHaIRBs9sU9Wcd8KF82ebv6WBy9a1haI6CH7o1YeAlDWyIXMwRs+Xz
6/pUtVKC01muf9KiTkXY86DKenA7MOIAPodOOl55N3gEdf5iRIMKKKg2fsCp
yqdqmZMg1s8bYsaDPRGNyMzcRL6BsVA+RFjKJxVU3cNH22Cvw/+utreP6H//
aIlxhmMBDqbqDRAiKgOeW+dg7Mi1ptH2rebWemDTSqw641ZgNetSh/xUl+RT
1o/NO+V8G2Sb8XWoL/qP3YP9w/1Hj3d2d5cwJOPdcrYKjmcMuJ/OIKTWD8Gc
gtddCYEcKrO3fbDT6u7ut/YPD1qPt8nu3dnfbe1t77R2unvw323ZgDuxv6lJ
ybH6+IjXtvrwlNd9ghS9wbM2f1UWPpu/2H2eA+aOnW+rb0x7t6ojVdt4jEiE
OstMVo7IeVdtfiO2MnE1Za6NEL+bdFSGvZuNhqlbRaVTeMydsgo5pw4tf5hf
j6TYEsW/fTgslUXkLEa6mU9eY2mrLuVeB0ILdVZfryIGImdPQEFUEw5C5FZC
mlK5QCWaIP8BLcZBUYjEIIHVQaLv3BignGO630Kx3qbb47L+jXE2yUZ5OEVV
U6JZvsmrU63jJ1yEhQ2C8dQXcCVnOvqQp+MeQbg7J6a1EpWStQd8je6c3RFN
Wo/ZLXMHmKOoDhGx69nQ8pgEfBEHOn62yUn7NRKnVYGNq1XNeTkpObBe8fSm
jmeEfAnEdJHriYejMFxbLI9jJjhumqGF1jdNqWJVIo5lGwkAwwXrSDVemvKR
vmny6b7XX1/4gjzw/u43vT6yRUecqEs641DUIicctk25gI7oEE83R/BwjIKr
8UBf8UC7VVPdpZqUP6CSDq88RVV0qh7NOgSlWyHXVaooY7uHgWPVuHlBpYc+
tNbpYrR7ktDqlsvRRumOrXIBSEAWJd4PApNIlAVfpIbsmfhSdEUIui/4Xz5L
wLiLVU1Q12aRDp30mgE3P8XX1OBMd49a3h+9JUETdOWYYFkUgQSOS78M1S1d
UVZMV6qzrHbjTM+WOZVZGXdOqxhOEzEdEVGMpZk6eQLhLxLCbKtfU6FepvPy
nkrG5uIsbkKWSr8uTl8CxO4ugpjTuhLs/E+9M98LMnqqa6dq6ZvPuGOdvT2h
TiQtrPZz2mfTU3UaO53gLCm4IchSvH0BLK4tS2FKx56tg2tvKVyqJcPngmQy
cBEalfhVB8e+goOqCb145AHm3xDJukCQlSxxPGqEbjL4paste3lM5YqDneCk
DnZWd/X2QWHKBYTHrBk2mGDfS+M8u4KvnFFNWyhR4fcJ0dh9cN1LvRFyjMjM
xEMRlZGKwAqgJfCpvuIEGN37wwxtv2GXRLSkYfWKW+5kWNPG4zcOdyxDXiYr
7CBgsKI3qoByTTAWUd7Kc7PMsLIJ34tWyPFKMfJjPDQyJk8Zymar6Q3I65Gf
QxVyvLywH9v1aJ10gk+gDpKZTg2Ov4BYYQghVid3m37F79/buaj3T88iE8gg
2miuR84KdEXOp38qqewYUqmhEQutd+29op1Nh3b21ljPhZOmgEsisAu9KG8j
7Xn2VyA+p2rDGt4iO5V0aCkkLQvtLAq7UhH7WasmLeHkPXbn42NW/pv1+D0Q
3fadQrRrUZ0BRtwKCUYNbbCMILAzL1xZcOzLgp11SBSTKdVuAjB6Kw147uB7
RI4OiFzebwesaiTWyVKJtQqgPZXqrcDFL1ymssGyZtup0l6N5CNMMN0hIozx
SwSjiAz+uB9SecoWhhlWLI1AdZNGTPhe37F0pJELflRjwDrLhvWuGV33d7R8
SPaWg6RP5y76YoDmb+/pcBz/1ZF2tb/RCUzNPDva/B3GOZaCmnMbe3qhEplq
+ZC7dzKSkVpmhuXCpsYUs2QIb7tTwrCSyBlYdnGtyBEpb2QO6UTD64vVwH1I
pPXMOgtWXyQt0VZaQhlcrK8oF0khnvZhYcNWqx4987JOGK0F0Z2qrl7LsWmn
zcqaqWsF4YJV/C8wkgNvRX+2obznG8pVE9mju5Vs5c80l6tCRNYohjLnp2rJ
we03C9Jc72PVi9Nt74hff2Xbt47p12DNJ3frXbPAWpPzHtjNQ5Nnwa6i3c0y
eLPMKmp2jCkrpgjFPYW0zJBuWq6eYEXm1pnOzNkq21nQpCdRitmbVqXSrTOr
nUXtZahVJt2tnZQDtGvNaZ1m8IW2cqJRmXGvdkY69VhrQn1OgvOZsxJ/uv3a
6ZzT9LWmrWTrEm3GTmDNnv+gfn7Wd+vNbBLXaU5TNlSZ9FE9KdHR0Tp0JOnw
REScEl+d63H9XE6of71ZK9lrbOvRt7UgHDoKr85CrdcEwpsqaqJy2410UUm+
WsB4IuCLHAqDNZlG9WM32cVy/PVlyfUL3Y27tU4diKqddMoXAyLEeCqJ14du
Btva3gBvpF65OAOCpajaibMV5R25YVJO0N2W4C1l2Yk0U6m0dyuWBcJRXAid
7q28RzW+pHsa18ETxPejX9Rsuhe/O/0yF84dAI9O/GxjTJCmsx68OlyjiyiK
rzFkP1ANQQfxLU4wxtMYepayltUDCbaCaZkUZFMrScOr0dMoxGu11UUyWa4b
ICKKxVweSp4rJqjhYScA6aqj+pV1d5YsK4mG9auSpCgFeD1a9+5kif36nfs8
ljjwWEIGfFjUFA0sYIuNhXxh2eXHBteYwGHA2W6SplB2d8eB7nF1qQ+L+gqF
moHtkQ4XuSM1+5itOOWX4ANk3/ZKkkIUEAsKnUSj5IT8quVD4Wq6e4w1yQhf
L9xkztAqESdHA33zcXu73R0iQ3/z8dGwPRyq41cJTNGdlfjz5cXmQtG1MNDP
+dMkBHSMw0Sn6MpJ7UTyK9aBFf9ccDY1doynwWoCm/j7ovgrDVIbbJfc7rVj
VmylMgmpNGtFQfybJqDSMYHvkX443fprkM/SKKJMy4qN7i41UUS5zYNDA7g8
1dfdutXGDCnURbeOtjChm0OcW4sjnHfIcd8aYVDXNiVcX0Dc1NiNR3oP6d2W
U+l7NSRpTGNK2Fst0322Jai452iBVeca9pxL3dbH7DZ4us1iXZp1KyhDSgZS
rfhFmTsNpunSJJs5PahqOPNqHOl0b8qRtbt7cCHulC9AIOeiedJsLQF0t7ND
6QLm7jlnbLmvmFJyYdSgh5qtiMg8EkW5ZOh9xIL0BzE3oNh1doMMb/yRthRe
S2Sr+/0CmhUvUqhVp4JrcpXfDaF6ruo9kapJDGdi1dN8MYn+4JNo3aTc8koZ
LF3/iLXuFco1X2TkrHiCgQ61OB6c8K3QTr8YX8P21O/xgJMSoq2wuoJ/vViW
5X8PrAiBiW0tPMFb7umrQx129K1kNkuO2ZnDkjhsLDA/nnM/pFpYxSRVwVoF
aCkJowx8z7kYlbwpvIKA2hq9u3refmySlDZMS1pqSAs/P6ZuMZkHIQGtX1ui
vUVDitSyErnCwLUFY0lItasy6sw0XBYZ4np5lmnGPxZY4LkfbMBwYBvC551g
g4fiOnfb0ixqTM0aU44zZd1VWGfV9hIJhsUYR4XVPahF+WN88H9EUAvacTSV
XozXEddUwRVWSlqZWTfXNvQhjSzDAbF+PW7qE5X2RIxWvnHJM+T46LKimGvG
rjNw/WeMaPN/sVK7b2+ZKjELfRyTxiuVziWXbGizrOqg8u4vz7D4AcGFj8+f
P8eG+Dr3/1gyEVXrNWP8a0Z3q0mojZjUTDa4qyj5gwtTZ7lfi1Q0hXKVGhks
rlal5wqnREX3GuWbd9iGqLnbhVU4Xp2aY4hD5bDnTI0hmfzcWEWax9uFxtFg
JLcTmNx3uSbFL0FGTrymuizJxIaNAFE3UdcjqYRptyG+qWanFHC5TbBTlzem
rTfbmCOotDNOQ/axIibVbc2s3FvVZ14n/sZyrYO+DY8sHR5r02TuvuebZqgp
8TBomvNDzHfAY1LxBzAY3Nx0Ys2qsf9yB0nsZkkcdVSG7W0uc4+kaJfk/DO+
lYZEg8rqv7ywRQO3JbWGVjE9a73oy8rikorHXNXVitZNHjKt3c1EdqfcrZvS
we56E7tJxzx9TdqxC8ReHRC0k2tOb06veWbnwNOdc/8z9+igGjMRoiV69knh
kSO1c88eIplDd3NSezHXLZzaFWf9bNLDzoiY7s6UzB25VNNKTHNX7L1Rac21
qUQH4iQt8JYRLPBL8JZo8KitjHrKlycuQFajVixtq5WuYeTaXvk7dq98KjXg
u/DMVYd1N33FhbmdxKkaep7ptubeRRfS5GIciooZDuEdVjCqsxwwKRYUpYxZ
xFs2NAt9WATSOwJzWTMVxKtrB0a96fQ9HuTdmbR41Uyivmuae+9Nwe1gVG2/
lrt8GTgXLpibULHJhVNgBy/1iQMKufmnoWrLqBUE04dNG9gns66u2zTuWAY1
j0HqlLzYWQpSGVmZrGdmQqtNht0uXjr4bCxqH7mpbtOhi48AH9rHF45SDD83
AjzvBJeEAGtfgeb0fd5UC4b1wtiAssBrwyasICcANBVSGNlheoDQLXKssvja
Tw2IqjbJVZyKoWhZd5Pq9kK0dYuHCmWRdDW8XHtr6ljNZblI5NXaeNV97s6t
shqWIMmx2SlbQfi+s7XE6a8svexLqFis2+xaTLHJ0jJQWjyCKGvu4MAw6oul
uCwrtBvLVm4bUZDq2rEwDdxmH1ZXtYf+PbrFsG3ks24Qm9WvkKSJdKVlabZS
p5FhllW+xKb80kls6F8GLa18F8hB71Zt3R3HugLPkmB885VlLWldwAuQzmGm
a1AyF+qU60PJklW3zqu5rcmAKLFDVqRbAUuxILNzwnGXfikBqDy7rrFIqb40
HEaoGLUt53cl1FdpVm10xafW/iUZ2ZZ+L9LO0kal5kIz9PYCNvL8O+OkWF6R
pzncrLnzL3WEi3rNDicidqbIOtLNipfO10tptEspoNwRSsSq4ySeNUd3Iihj
zjLOHVN1yUmUKf6gvKwsf29XIlRLQDoVI4euV455dYDXjFuHKvvaS2XTPZet
QB2BQGautA9bZEWtlIzqW32V2xyMDdjO8sVGMLWkUV202dGuswzf/HJ5h2mo
a4T8dYllKHthz7VHbgje8Lv8HMVyPkw8uNlq+uYmDLnAsF0J/HrjVsC36pR1
izZSL8ceELvYuMvYSBIRR1uthw7/EA/gjz1s+H7hps4IXL7NiiucXV6XO8jC
oxzvu3hD9byvPqY7Pcn11So/VV/zIVeRGTbUCZj3zH13ncmZIZsbzTuysmzk
1/FWJUm54tC+XXX4VR23GrKoIYe68re1aeEOGjB7790X9dW29gtkxUZFVkh0
1FpGjazeXVlWf5Y3rdPoV6XYzaYVA14DHV5I2MpKvjOq4OY5M33p1j81BKon
ersqRSnVQduBfHCvkQ5WM+qsWxK+DSRKaay+Cbj1sLMYbtusUNUeO7k4l/g/
FnvehPy2qAD3Td/qcUp9KpGkz7CA7JujnJ49KKL/HKvIqj2ymK1lg7aOfYRD
oq1LNTYrROekYoeRadfsfCFXnjTtqpnPYEvFl1KKtTL9f67Nt7DqR5Cqr6C3
i5L+dBmyW4cUESXVKhyr9sYiszBBb31uJ9VQQZaimg3qX8LnfVYDNqtHJTqS
14ClPMYjPN26w6r1UiKkmuLnTEVv8MuyJOpxo0BVFuhnW6+PVjC+veke37/9
ffgFK9j+8+1vuxqyaoIbl5oiJgOgPW7TZAlnfc0NtYREr5hue8MA38y6hVHf
Wk4GMYc4Op7M15VZllJbW9AvN7++UICbqqkVxK1ThcVLqtZhVSzmry1bduss
k3qUVa1tpyTLX9L6W6Xrw/8Ufyek9Gu+5YGrpld3fjjtBZNKTWEVr5+Pahfv
5zrw8Qn8qnBZ5TEMSm3JlXvUtyooqZ+uuSJIuiSLIaorynKP/Va1MY5Wh6FS
nyWEWleh5ab1rwrMD2sAY0q2BIzaoi33fHFVOH5cHQ5VyCWWdLWUS0HwaC0I
vlkDgkpRl7Lq68q6FDiPHbuCDjfIh5Fz4lmaR/1slPLNqJ5H4cguS04q0cVi
8r5dCS3UvtRbcLXAF3sL63l4zeMmdjSMRYVn2VQ5BrbFhJ1MLLtRurByh3Da
/jqDf/fzowV7Fmbu3+vZt0df7AOsx6Mni0IW2FbAytcqV8Cc530YGL+CKaIt
aosMF3gTZju+zJ2wFqXM83qfwkxoORU2SoC9DNi2zWN/u9i81U99uXX7wKNE
JXucfjUrG0x0UeifYCot7vvixw8rjQDrKi2+ioSS8+WVO+E42TdesANXQpU/
FV7qE8fG+jDw7njG7oJaItvwqWtgWAmB1dqdin7E7PwM5VUd9HNJ6jWWV/Hp
sMkinHKiJCVF6BucnFveOJ1H3Q/k3/MGv8k1LnJencNmTDN94Y3qEam0JFkC
mNguEzQ1aWJxIf7S1e2JeJmSXLmgSdEaoh1prC8SPebepoWaFxDX7rrloktc
egWHrMG3ZNbSOJygLtxQSUdbI7R4Xwyx41TnadBCFZI2Wey8M4qLTCtSnRQo
W0yo1uV+HVvDamzLLmtV5dQP24lVlRBOJds6dNnZGV9tOsEIPzaFmJvKXrHG
meZRzUCKQ+k+iorBJY5JLQbuXOj+8oUeuGMryFcb+2DJ2I/rgbaJS0Sfw4vO
rXZx4RGeSspw0V9YzRLcQuOKVqH64SqlykhMSTVYMj68ycqu3uDTaZrkdDPi
iPJp5BZBqqSvmWB3EUa00F8TIV4HgY5bBWTNQDI9zwYzzp50f1f3q1FCs6uw
1Lj+mc2lquJx4hGfoaNmKV29NJARv9CRuttGWStOg8JSRWoqoVfl2awkHPf+
V8hj/2quOmlqg3ZTn+vs+Cdp9LF8f18A68waM6qzDWzj/VbHvM7pp3m9apR5
KkdN4kXkqi/t1by0YsW8OUqor5v30nrOkhpd5AFEhTphH69EKc0xrLOF6o71
YcwmVRj0k4z4l9d617msKme3A3zrOzI0yp/mynixzP9ljsyCuvb/7/yVSjG8
E3ddn0ac4f40WqE9qFDIWmJdh9pzq2IUK9TNO5L5uYBJa7Iq6PTpYO+93Dyz
bOPVI/4C+Wpl1Z6GbypyCUWHMSR3w8AL0JN0cQJYR+sFsNjctBexpNUDXaNE
nV2IeY17/xd07JE/Qm7NWePjEK6I6hajS/oTqDvS5BoALvC0YWwFxTyFVwuu
WMYWAUQszl0zaVaq8a0mBWEP5Sxe8jqNGQbsMYu1Hti9YJOxwVfOaTAkU1yZ
dkO+P/6x5kB3WUDfTyTtv67Uw6xT3aLBpSV59LvU7GRDt2+BkwRNqdzJnAKV
0hphg2+6r2+HsGmKlqT/Ad6LZBLu1TgWs0nuuu52UPJtq6rqAZY5jEczSamm
pgdfZ8l860japuutdMOGxavdv3u11eHo+p/PWfBV5dYWk9GeR0n4sUp7dBGm
D3gBkHeJb3Y7u1yjJZddeeVmtIrMvp8TRT/e6sM8zghWNc80IjydUAVSFPGN
PTaSa1SF7kHhnop9hpbgN/88/fDD/emHO+ek+jzY6Wa3SVfeLZrDjpvJQcXq
oSw9yfYak/C1i6gSXmcSgKcubTTW3cl93AXDOoxcf+NxjD9v13+8j1237Exq
m7FSotvn5h4wAdjTud1k3dX43UvojbqsTK9fh3uGu/4uLm+k8bn7u+3tb3mT
OcLM22RVZ1Tf52JJffeqM2gvw23+oV0MbuSwbs711wsKfAUPdtft0fZN08u5
pKtr34+jj0tX42K5ekhsDG+1p+4rC4MWyCoagro2eLYCVHjZ3W7vHjJeDrrt
g4NavGy36RHd/iMI28M6BBnPjgCpogEh04aiAXZJo5JqpxEeWvqXvBeK04mj
btTD26AZc6dphlMBUANnUTnFI7mbTaETP+p62XSC5xZG0MB2jeJqZr0PUE0e
qhWUUfxd1xhQceaS9jDerWElE1X1WhTVwsXG795XicoE56evT8khs25bvH0Q
h2kIcvgCr4WmS79ZBJBUw/HYV+Fmqc0X8ykWCn8sgyug6WIIwuEiz8qsn4GW
wQrRTS7FDF5jFfNb8O0A3jmwbuN7yvNvXpo00ysYq4mXa88mGAjnCz05Zk0n
AXb9fbDBvQP+z+XZy+dkS8NOhenc3Frei2CK5jOn0QdmedMGNjGVARzS7+EZ
c4hvWhgUlhvKV35bfFyOVUDehIW+bXKNtJjhobRZIyDsRqOhtEb36lSldXn1
/lgs5039KyJ7EVtdQDB8Vx1M4twzKS1VhpwiHUv3OpxggFcf4FXsjOZWdQOc
ZyldSt9C7T3KJa3YuknfH5/LBmN5Mvwb8+fZB7+9Vc+0ufkNNb/7j00cd/zz
n8r0/2n8p736P9Vn4X28XTqalu2nL+6aHuanGgH7G3j/KXJl+xKcx1nxWe8/
e93mMZ5K1f/i962cafM+FtG33+QxUGv7DIw58LLz9kWWxP25/z6l7/jzL3m/
/TbCjkPtN9gKd5X330yxFUnt7Ou/786+6H1583SEV+I+TWYFmicL8Ff3/kUe
Z9Tq6M5/6vEPwu7j/LP3//YoHpw0Pc5oBmVcJtFJ80xxFQuJ5icS2peqOVNF
cOurdblXZYF3nWZ4kUpRc2dtVQaprJ14EpfogJGoYkWGiXwlRgZgK5IwH0Wq
g1VfXyudyvXOwTWoZpALcoMtiggYI5vl3HoDzDDq5wHa+hXCRU0E/BAMgUCy
B9cgtrBurSJTY1eKCCSutHDBnDDMqqr0rjFdq+ju1yyAsWNsDhYUs76+lBpv
dSabSzfJRMhBW5YxdTGRK0ZVXwI6e8eAEMlSp6cX6XW07vD5SRSiDmmgIVBB
OVhMKceg+nHen02ky4v0plnccoPvSq/v65lHSQzKZ87aHnsTwii0UGcOaWfq
OWOkZak/GDaomlNypR68et+6tjkKWGQpDdS8RgcUnuImK2ITg9UVFngsTN1F
9N3tLd32RPq7bZj48ut3L7kbRZqlRhFToaCKPqGZpRtCGHPfv5FbX8cuvIMm
JZDCCDeZyQHbeGDPCzKRYSHgpk0p9g3AzQpuiaIiwkO+upymIJOz7AR8y/XF
27On55efPpFGv7199/r86ZtnZ+3Ls6fv3p5f/UrKDzQQnZwSVz/PyQbFxkOn
xQeY5e+gxxVjD8N/f6JmdL+M52iuBH+9fPP6h0bjLMyTGBaBgdaswFwoxH2V
s6nTB8bcBsFsCpyArwNUP4Cd/3hn/xCgCV6Ac3GNERrd/JUXVFBjDeQaua7d
6X9pE77uXVHgfeB5IbEeiV0XTp9ZHYu07/9WbVrci8lbDC2GhtwAZlwUnDBN
Vw2wVOJwhtyz3UP+FN41mZmqe0JwmiDxjmDLB9dxn9cTXmexOtHABnk8BUY9
roGdaNki1xh7j/YOd9n4LK0YLPKgoNpp8EsLKYQSKdEbO8wPQ/QUFHfJz1gj
jrVU1DnJ7uY3zaiDCt4Z4PdKEWjN1eGSSluQtNXL1ZtA/SW56QCiQBpBEQrs
2+eF2rlmfZbqQwsRU/C/QTyEXdHdIQGR6Eo1TlO56pw3Ep9EDDwsbCma4h0P
ag6cPu/FQH45YmZajgvVtck4VWT6RpMsn1P1WlwSQek+TrNUU6jBRMSGzSAw
F7CLmsNGTUD3OFuSzSn0TduJl4ro4xnsGkMqKSZ/nET2MCzGJO7GinO0EUz7
7Os02sk0YylDo0nHJuoHhc6LmkMTOiYKEyQJkBB13wGrnicnq5m0eWx1rYxT
tu55J6/jLKGgnX3KAyQkm9DLM+zCNOD+Wpyy5cCsohDO9mITykKpTsO7Vsto
1dgJFY+HhGOG3sJ1cEMGBCkrQzy42xPJbgQeAYlPwtyneNafYzASW1JYmWTZ
B0YXrbIVTKNsSl4TtQsLSox+MXYQGSFvFZ9cbNktu1LHn8KOZ0SFIYjB30FO
jDK0Q2plbawk3ZKGRoiWeDiv4JulDjYoizB7NRGOxJkmYam8OhKznKSlHDNe
gaQSqlUgC+odSnS2KCmDG1B+2IEJUItt+aIoIaFEMxBO8HgofVgGTUQpX/VC
+WmWxJcYgtsECZ3pAibmroQg4L0mSeTDVw6jYBORDKKPRFzk8OuGeXpBGPeh
jqv6G5UKTMvXP9Nf+NNwlvKpFVkKc2YMkdH6N89eQUGubFojKVVPMNYpLVW7
DBJ1UBgvWOITyC+AY5JnahFkfoti82lCmNxr71qPv4LP+KQDF3XEyrjZ3ziy
GwJi7Ac2GBiOzBHUKv0S9fwV0FM8oD3AFmkoQbF1FUphlJskpVV4ISZ7jd0F
zqSeTGYpUXEZ/PYdtjYrjra2RjDlrNeBX7fwq5vRlk6yHrBL08bxi9++RyPb
1j6y7akOwNgtGgP/3sQ84sKlNkVT8muJgaCK0DKxoKAJ7rGYsGKAq3g0DSC5
BcxtfISL26PNagELhDlLDSbLATbM5+PtUgsUYxcgo9o2KD2pRDF12y0dY8Df
1woufKLIAll3JFSGyoY9G9UKmZsDEuLE4FUnAeQDgkgaATpJlibgosxC7JLN
iok6vImXSNNjZZoE+STgRb+hy0VcIsEpR0n2KVkVyOomx9hUHjQpu6spfBNI
x/TQKo9BSatYkXBI/T4D1e6zUDDJBaCqlaj4L27rZlNCEBtXF12g4Cac660T
p4lZAv1ZMQRksYYe7CFAtOBXYNCjNQHqfk7NUL2Wg7okAWl1EImTgwOj8UwK
ly5km874yJtNV1y1nBhpdXPuUQc1dbZ62DkOMkXOtdDRzIctP2eMeFkb7Hw8
AR9Qr0yLLlwd0gr3ytfdSaOPfTqNrza7IwhaYpLo5ynOrt3VLK+5Qi84ffL6
Ofg0YS8dflKZCeKhzwoJ957ORiJ3n4CDNCvar8NZjrieBBv4/iZuIQPChvj+
zu4ebA5q3gSDQEgjyLcwMDLuHMD+iGiq6GvL83FseNUXFXYkpqNPACvOZSTT
tTS2WgOCo8gtXUE02KkUHW+VMWeKpKTUgevcXC/g63CUR+wmKcZWB5QU2DdS
HmkI0cFlrdpqtB8hyptiU/IBn3BQV0pEfqMYUn8TCUadULC2LY01vt2ghhN4
jy7+1/5ps2H/hS/CQFRSuxVQ7xsatdEwn3n45kYz+PbyIvinfh4m6eI36u9N
+v1f2BWo4UfPTNldo2HVE9LIMA6WkeLLRrBsmsdkffQ3ls0BCJxJhH9z5sG/
GuZXfho+NdRfCkMbuqRtiyL+mxUwv7UfoYQzfPR9E//dpn93mvpl9aQans4A
H50Gx0HY/qNhg4e/6nLLBu6c1XbjhHpwLNg5+6fNhv0XjskfadUbdpnmFvyJ
KJLfGYjNzYb1vEaS88xCalDfOiuxd9V8yUNI0sIW/qGqEbaspqz0mdSLswn0
Nee4yWfJE+KBkJP5E0dteDAGT2ZUu/FP2LB/AYF292kfGxYclUd2eKtxc7vf
7urnBVT9vCSbwxbNUgosAa9u0ZniVtAr2uqrTXmwoVbokCCfOQkN4ViU+otf
HBFpbSFpGSToN/FnybuCjw0LNfqJH5q479s0TFeGIZRZADR/bFr70/BRiU/A
ehas9Dccego0qHK7qhwE/8jqGwKtmvlbs3bNWX/RSw6+BYJtNMx0wlI72+2d
LjwEn3bbO3v86aC9/4Q+7T9rPzprWLinJf6GeJAlMNSbIHUssGWVSb89jj4O
4pH51DDfnWgw1eH+MR7lt/D4nhv8gjZ8Oua7SigRARRZ8PhwrwvqkWPIhdKQ
eXQdF9p/qna6DX7mgz8dlHP9K06sktwDc5Irkxw1Gt8GpxQfwd8ptcqY8GIb
YJUl93yAhy/Bs0FsUU1zHo4oQMrRBVLvYCSZ4ATF7zFMbo0pHiRd+0OQznng
V+A0s05TPXbTodKTUrkQf6TXyH6gdxjycPFRslg/hJeaw2gajg69abi3Yhux
U4kWDSp1HZysuJku7tyAei0WbXbB98ko6uMVIAne1UE2Q+P2iGN+0eCkSZly
ePrzCgPyePD8gWzlV2EJc94Ef8NkhZT2fkyWb4kHH+TWDzDAzMWOIF+Hs0RH
viULdJarHJ8BOqrZdBKpG9N8L53sGJob4MkQgHPYoKcJeAQwQSt4m80ZvZSf
dQrCH6ynFKDDMzk8UP5b+MdsnAVvPsxawRldnXGRgQ3511kC2Ae8F/3xB7Ci
X+GhCzgz42xSYFTkFYZzfomwnx4u5K/RcJiDAvoVXIUPsmw2zugAIQYnjrvU
/1/zZJOQNvoAAA==

-->
</rfc>