<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->

<!DOCTYPE rfc SYSTEM "../Tools/rfcbootstrap/rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-nottingham-binary-structured-headers-02" category="std">

  <front>
    <title>Binary Structured HTTP Headers</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization>Fastly</organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>

    <date />

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This specification defines a binary serialisation of Structured Headers for HTTP, along with a negotiation mechanism for its use in HTTP/2. It also defines how to use Structured Headers for many existing headers – thereby “backporting” them – when supported by two peers.</t>



    </abstract>


    <note title="Note to Readers">


<t><spanx style="emph">RFC EDITOR: please remove this section before publication</spanx></t>

<t>The issues list for this draft can be found at <eref target="https://github.com/mnot/I-D/labels/binary-structured-headers">https://github.com/mnot/I-D/labels/binary-structured-headers</eref>.</t>

<t>The most recent (often, unpublished) draft is at <eref target="https://mnot.github.io/I-D/binary-structured-headers/">https://mnot.github.io/I-D/binary-structured-headers/</eref>.</t>

<t>Recent changes are listed at <eref target="https://github.com/mnot/I-D/commits/gh-pages/binary-structured-headers">https://github.com/mnot/I-D/commits/gh-pages/binary-structured-headers</eref>.</t>

<t>See also the draft’s current status in the IETF datatracker, at
<eref target="https://datatracker.ietf.org/doc/draft-nottingham-binary-structured-headers/">https://datatracker.ietf.org/doc/draft-nottingham-binary-structured-headers/</eref>.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>HTTP messages often pass through several systems – clients, intermediaries, servers, and subsystems of each – that parse and process their header and trailer fields. This repeated parsing (and often re-serialisation) adds latency and consumes CPU, energy, and other resources.</t>

<t>Structured Headers for HTTP <xref target="I-D.ietf-httpbis-header-structure"/> offers a set of data types that new headers can combine to express their semantics. This specification defines a binary serialisation of those structures in <xref target="headers"/>, and specifies its use in HTTP/2 – specifically, as part of HPACK Literal Header Field Representations (<xref target="RFC7541"/>) – in <xref target="negotiate"/>.</t>

<t><xref target="backport"/> defines how to use Structured Headers for many existing headers when supported by two peers.</t>

<t>The primary goal of this specification are to reduce parsing overhead and associated costs, as compared to the textual representation of Structured Headers. A secondary goal is a more compact wire format in common situations. An additional goal is to enable future work on more granular header compression mechanisms.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.</t>

</section>
</section>
<section anchor="headers" title="Binary Structured Headers">

<t>This section defines a binary serialisation for the Structured Header Types defined in <xref target="I-D.ietf-httpbis-header-structure"/>.</t>

<t>The types permissable as the top-level of Structured Header field values – Dictionary, List, and Item – are defined in terms of a Binary Literal Representation (<xref target="binlit"/>), which is a replacement for the String Literal Representation in <xref target="RFC7541"/>.</t>

<t>Binary representations of the remaining types are defined in <xref target="leaf"/>.</t>

<section anchor="binlit" title="The Binary Literal Representation">

<t>The Binary Literal Representation is a replacement for the String Literal Representation defined in <xref target="RFC7541"/>, Section 5.2, for use in BINHEADERS frames (<xref target="frame"/>).</t>

<figure><artwork><![CDATA[
  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|   Type (4)    | PLength (4+)  |
+---+---------------------------+
| Payload Data (Length octets)  |
+-------------------------------+
]]></artwork></figure>

<t>A binary literal representation contains the following fields:</t>

<t><list style="symbols">
  <t>Type: Four bits indicating the type of the payload.</t>
  <t>PLength: The number of octets used to represent the payload, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 4-bit prefix.</t>
  <t>Payload Data: The payload, as per below.</t>
</list></t>

<t>The following payload types are defined:</t>

<section anchor="lists" title="Lists">

<t>List values (type=0x1) have a payload consisting of a stream of Binary Structured Types representing the members of the list. Members that are Items are represented as per <xref target="inner-item"/>; members that are inner-lists are represented as per <xref target="inner-list"/>.</t>

<t>If any member cannot be represented, the entire field value MUST be serialised as a String Literal (<xref target="literal"/>).</t>

</section>
<section anchor="dictionaries" title="Dictionaries">

<t>Dictionary values (type=0x2) have a payload consisting of a stream of members.</t>

<t>Each member is represented by a key length, followed by that many bytes of the member-name, followed by Binary Structured Types representing the member-value.</t>

<figure><artwork><![CDATA[
  0   1   2   3   4   5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
| KL (8+)                       |  member-name (KL octets)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---
| member-value
+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>A parameter’s fields are:</t>

<t><list style="symbols">
  <t>KL: The number of octets used to represent the member-name, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 8-bit prefix</t>
  <t>member-name: KL octets of the member-name</t>
  <t>member-value: One or more Binary Structure Types</t>
</list></t>

<t>member-values that are Items are represented as per <xref target="inner-item"/>; member-values that are inner-lists are represented as per <xref target="inner-list"/>.</t>

<t>If any member cannot be represented, the entire field value MUST be serialised as a String Literal (<xref target="literal"/>).</t>

</section>
<section anchor="items" title="Items">

<t>Item values (type=0x3) have a payload consisting of Binary Structured Types, as described in <xref target="inner-item"/>.</t>

</section>
<section anchor="literal" title="String Literals">

<t>String Literals (type=0x4) are the string value of a header field; they are used to carry header field values that are not Binary Structured Headers, and may not be Structured Headers at all. As such, their semantics are that of String Literal Representations in <xref target="RFC7541"/>, Section 5.2.</t>

<t>Their payload is the octets of the field value.</t>

<t><list style="symbols">
  <t>ISSUE: use Huffman coding? <eref target="https://github.com/mnot/I-D/issues/305">https://github.com/mnot/I-D/issues/305</eref></t>
</list></t>

</section>
</section>
<section anchor="leaf" title="Binary Structured Types">

<t>Every Binary Structured Type starts with a 5-bit type field that identifies the format of its payload:</t>

<figure><artwork><![CDATA[
  0   1   2   3   4   5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
      Type (5)      |  Payload...
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>Some Binary Structured Types contain padding bits; senders MUST set padding bits to 0; recipients MUST ignore their values.</t>

<section anchor="inner-list" title="Inner Lists">

<t>The Inner List data type (type=0x1) has a payload in the format:</t>

<figure><artwork><![CDATA[
  5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---
     L(3+)  |  Members (L octets)
+---+---+---+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>Its fields are:</t>

<t><list style="symbols">
  <t>L: The number of octets used to represent the members, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 3-bit prefix</t>
  <t>Members: L octets</t>
</list></t>

<t>Each member of the list will be represented as an Item (<xref target="inner-item"/>); if any member cannot, the entire field value will be serialised as a String Literal (<xref target="literal"/>).</t>

<t>The inner list’s parameters, if present, are serialised in a following Parameter type (<xref target="parameter"/>); they do not form part of the payload of the inner list.</t>

</section>
<section anchor="parameter" title="Parameters">

<t>The Parameters data type (type=0x2) has a payload in the format:</t>

<figure><artwork><![CDATA[
  5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---
     L(3+)  |  Parameters (L octets)
+---+---+---+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>Its fields are:</t>

<t><list style="symbols">
  <t>L: The number of octets used to represent the token, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 3-bit prefix</t>
  <t>Parameters: L octets</t>
</list></t>

<t>Each parameter is represented by key length, followed by that many bytes of the parameter-name, followed by a Binary Structured Type representing the parameter-value.</t>

<figure><artwork><![CDATA[
  0   1   2   3   4   5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
| KL (8+)                       |  parameter-name (KL octets)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---
| parameter-value (VL octets)
+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>A parameter’s fields are:</t>

<t><list style="symbols">
  <t>KL: The number of octets used to represent the parameter-name, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 8-bit prefix</t>
  <t>parameter-name: KL octets of the parameter-name</t>
  <t>parameter-value: A Binary Structured type representing a bare item (<xref target="inner-item"/>)</t>
</list></t>

<t>Parameter-values are bare items; that is, they MUST NOT have parameters themselves.</t>

<t>If the parameters cannot be represented, the entire field value will be serialised as a String Literal (<xref target="literal"/>).</t>

<t>Parameters are always associated with the Binary Structured Type that immediately preceded them. If parameters are not explicitly allowed on the preceding type, or there is no preceding type, it is an error.</t>

<t><list style="symbols">
  <t>ISSUE: use Huffman coding for parameter-name? <eref target="https://github.com/mnot/I-D/issues/305">https://github.com/mnot/I-D/issues/305</eref></t>
</list></t>

</section>
<section anchor="inner-item" title="Item Payload Types">

<t>Individual Structured Header Items can be represented using the Binary Payload Types defined below.</t>

<t>The item’s parameters, if present, are serialised in a following Parameter type (<xref target="parameter"/>); they do not form part of the payload of the item.</t>

<section anchor="integers" title="Integers">

<t>The Integer data type (type=0x3) has a payload in the format:</t>

<figure><artwork><![CDATA[
  5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---
  S |  Integer (2+)
+---+---+---+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>Its fields are:</t>

<t><list style="symbols">
  <t>S: sign bit; 0 is negative, 1 is positive</t>
  <t>Integer: The integer, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 2-bit prefix</t>
</list></t>

</section>
<section anchor="floats" title="Floats">

<t>The Float data type (type=0x4) have a payload in the format:</t>

<figure><artwork><![CDATA[
  5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---
  S |   Integer (2+)
+---+---+---+---+---+---+---+---+---+---+---

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---
|  FLength (8+)
+---+---+---+---+---+---+---+---

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---
|  Fractional (8+)
+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>Its fields are:</t>

<t><list style="symbols">
  <t>S: sign bit; 0 is negative, 1 is positive</t>
  <t>Integer: The integer component, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 2-bit prefix.</t>
  <t>Fractional: The fractional component, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 8-bit prefix.</t>
</list></t>

</section>
<section anchor="strings" title="Strings">

<t>The String data type (type=0x5) has a payload in the format:</t>

<figure><artwork><![CDATA[
  5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---
     L(3+)  |  String (L octets)
+---+---+---+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>Its fields are:</t>

<t><list style="symbols">
  <t>L: The number of octets used to represent the string, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 3-bit prefix.</t>
  <t>String: L octets.</t>
  <t>ISSUE: use Huffman coding? <eref target="https://github.com/mnot/I-D/issues/305">https://github.com/mnot/I-D/issues/305</eref></t>
</list></t>

</section>
<section anchor="token" title="Tokens">

<t>The Token data type (type=0x6) has a payload in the format:</t>

<figure><artwork><![CDATA[
  5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---
     L(3+)  |  Token (L octets)
+---+---+---+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>Its fields are:</t>

<t><list style="symbols">
  <t>L: The number of octets used to represent the token, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 3-bit prefix.</t>
  <t>Token: L octets.</t>
  <t>ISSUE: use Huffman coding? <eref target="https://github.com/mnot/I-D/issues/305">https://github.com/mnot/I-D/issues/305</eref></t>
</list></t>

</section>
<section anchor="byte-sequences" title="Byte Sequences">

<t>The Byte Sequence data type (type=0x7) has a payload in the format:</t>

<figure><artwork><![CDATA[
  5   6   7   0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+---+---+---
     L(3+)  |  Byte Sequence (L octets)
+---+---+---+---+---+---+---+---+---+---+---
]]></artwork></figure>

<t>Its fields are:</t>

<t><list style="symbols">
  <t>L: The number of octets used to represent the byte sequence, encoded as per <xref target="RFC7541"/>, Section 5.1, with a 3-bit prefix.</t>
  <t>Byte Sequence: L octets.</t>
</list></t>

</section>
<section anchor="booleans" title="Booleans">

<t>The Boolean data type (type=0x8) has a payload of two bits:</t>

<figure><artwork><![CDATA[
  5   6   7
+---+---+---+
  B |   X   |
+---+---+---+
]]></artwork></figure>

<t>If B is 0, the value is False; if B is 1, the value is True. X is padding.</t>

</section>
</section>
</section>
</section>
<section anchor="negotiate" title="Using Binary Structured Headers in HTTP/2">

<t>When both peers on a connection support this specification, they can take advantage of that knowledge to serialise headers that they know to be Structured Headers (or compatible with them; see <xref target="backport"/>).</t>

<t>Peers advertise and discover this support using a HTTP/2 setting defined in <xref target="setting"/>, and convey Binary Structured Headers in a frame type defined in <xref target="frame"/>.</t>

<section anchor="setting" title="Binary Structured Headers Setting">

<t>Advertising support for Binary Structured Headers is accomplished using a HTTP/2 setting, SETTINGS_BINARY_STRUCTURED_HEADERS (0xTODO).</t>

<t>Receiving SETTINGS_BINARY_STRUCTURED_HEADERS from a peer indicates that:</t>

<t><list style="numbers">
  <t>The peer supports the Binary Structured Types defined in <xref target="headers"/>.</t>
  <t>The peer will process the BINHEADERS frames as defined in <xref target="frame"/>.</t>
  <t>When a downstream consumer does not likewise support that encoding, the peer will transform them into HEADERS frames (if the peer is HTTP/2) or a form it will understand (e.g., the textual representation of Structured Headers data types defined in <xref target="I-D.ietf-httpbis-header-structure"/>).</t>
  <t>The peer will likewise transform all fields defined as Aliased Fields (<xref target="aliased"/>) into their non-aliased forms as necessary.</t>
</list></t>

<t>The default value of SETTINGS_BINARY_STRUCTURED_HEADERS is 0. Future extensions to Structured Headers might use it to indicate support for new types.</t>

</section>
<section anchor="frame" title="The BINHEADERS Frame">

<t>When a peer has indicated that it supports this specification {#setting}, a sender can send the BINHEADERS Frame Type (0xTODO).</t>

<t>The BINHEADERS Frame Type behaves and is represented exactly as a HEADERS Frame type (<xref target="RFC7540"/>, Section 6.2), with one exception; instead of using the String Literal Representation defined in <xref target="RFC7541"/>, Section 5.2, it uses the Binary Literal Representation defined in <xref target="binlit"/>.</t>

<t>Fields that are Structured Headers can have their values represented using the Binary Literal Representation corresponding to that header’s top-level type – List, Dictionary, or Item; their values will then be serialised as a stream of Binary Structured Types.</t>

<t>Additionally, any field (including those defined as Structured Headers) can be serialised as a String Literal (<xref target="literal"/>), which accommodates headers that are not defined as Structured Headers, not valid Structured Headers, or that the sending implementation does not wish to send as Binary Structured Types for some other reason.</t>

<t>Note that Field Names are always serialised as String Literals (<xref target="literal"/>).</t>

<t>This means that a BINHEADERS frame can be converted to a HEADERS frame by converting the field values to the string representations of the various Structured Headers Types, and String Literals (<xref target="literal"/>) to their string counterparts.</t>

<t>Conversely, a HEADERS frame can be converted to a BINHEADERS frame by encoding all of the Literal field values as Binary Structured Types. In this case, the header types used are informed by the implementations knowledge of the individual header field semantics; see <xref target="backport"/>. Those which it cannot (do to either lack of knowledge or an error) or does not wish to convert into Structured Headers are conveyed in BINHEADERS as String Literals (<xref target="literal"/>).</t>

<t>Field values are stored in the HPACK <xref target="RFC7541"/> dynamic table without Huffman encoding, although specific Binary Structured Types might specify the use of such encodings.</t>

<t>Note that BINHEADERS and HEADERS frames MAY be mixed on the same connection, depending on the requirements of the sender. Also, note that only the field values are encoded as Binary Structured Types; field names are encoded as they are in HPACK.</t>

</section>
</section>
<section anchor="backport" title="Using Binary Structured Headers with Existing Fields">

<t>Any header field can potentially be parsed as a Structured Header according to the algorithms in <xref target="I-D.ietf-httpbis-header-structure"/> and serialised as a Binary Structured Header. However, many cannot, so optimistically parsing them can be expensive.</t>

<t>This section identifies fields that will usually succeed in <xref target="direct"/>, and those that can be mapped into Structured Headers by using an alias field name in <xref target="aliased"/>.</t>

<section anchor="direct" title="Directly Represented Fields">

<t>The following HTTP field names can have their values parsed as Structured Headers according to the algorithms in <xref target="I-D.ietf-httpbis-header-structure"/>, and thus can usually be serialised using the corresponding Binary Structured Types.</t>

<t>When one of these fields’ values cannot be represented using Structured Types, its value can instead be represented as a String Literal (<xref target="literal"/>).</t>

<t><list style="symbols">
  <t>Accept - List</t>
  <t>Accept-Encoding - List</t>
  <t>Accept-Language - List</t>
  <t>Accept-Patch - List</t>
  <t>Accept-Ranges - List</t>
  <t>Access-Control-Allow-Credentials - Item</t>
  <t>Access-Control-Allow-Headers - List</t>
  <t>Access-Control-Allow-Methods - List</t>
  <t>Access-Control-Allow-Origin - Item</t>
  <t>Access-Control-Max-Age - Item</t>
  <t>Access-Control-Request-Headers - List</t>
  <t>Access-Control-Request-Method - Item</t>
  <t>Age - Item</t>
  <t>Allow - List</t>
  <t>ALPN - List</t>
  <t>Alt-Svc - Dictionary</t>
  <t>Alt-Used - Item</t>
  <t>Cache-Control - Dictionary</t>
  <t>Connection - List</t>
  <t>Content-Encoding - List</t>
  <t>Content-Language - List</t>
  <t>Content-Length - Item</t>
  <t>Content-Type - Item</t>
  <t>Expect - Item</t>
  <t>Expect-CT - Dictionary</t>
  <t>Forwarded - Dictionary</t>
  <t>Host - Item</t>
  <t>Keep-Alive - Dictionary</t>
  <t>Origin - Item</t>
  <t>Pragma - Dictionary</t>
  <t>Prefer - Dictionary</t>
  <t>Preference-Applied - Dictionary</t>
  <t>Retry-After - Item  (see caveat below)</t>
  <t>Surrogate-Control - Dictionary</t>
  <t>TE - List</t>
  <t>Trailer - List</t>
  <t>Transfer-Encoding - List</t>
  <t>Vary - List</t>
  <t>X-Content-Type-Options - Item</t>
  <t>X-XSS-Protection - List</t>
</list></t>

<t>Note that only the delta-seconds form of Retry-After is supported; a Retry-After value containing a http-date will need to be either converted into delta-seconds or serialised as a String Literal (<xref target="literal"/>).</t>

</section>
<section anchor="aliased" title="Aliased Fields">

<t>The following HTTP field names can have their values represented in Structured headers by mapping them into its data types and then serialising the resulting Structured Header using an alternative field name.</t>

<t>For example, the Date HTTP header field carries a http-date, which is a string representing a date:</t>

<figure><artwork><![CDATA[
Date: Sun, 06 Nov 1994 08:49:37 GMT
]]></artwork></figure>

<t>Its value is more efficiently represented as an integer number of delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970, minus leap seconds). Thus, the example above would be represented in (non-binary) Structured headers as:</t>

<figure><artwork><![CDATA[
SH-Date: 784072177
]]></artwork></figure>

<t>As with directly represented fields, if the intended value of an aliased field cannot be represented using Structured Types successfully, its value can instead be represented as a String Literal (<xref target="literal"/>).</t>

<t>Note that senders MUST know that the next-hop recipient understands these fields (typically, using the negotiation mechanism defined in <xref target="negotiate"/>) before using them. Likewise, recipients MUST transform them back to their unaliased form before forwarding the message to a peer or other consuming components that do not have this capability.</t>

<t>Each field name listed below indicates a replacement field name and a way to map its value to Structured Headers.</t>

<t><list style="symbols">
  <t>ISSUE: using separate names assures that the different syntax doesn’t “leak” into normal headers, but it isn’t strictly necessary if implementations always convert back to the correct form when giving it to peers or consuming software that doesn’t understand this. <eref target="https://github.com/mnot/I-D/issues/307">https://github.com/mnot/I-D/issues/307</eref></t>
</list></t>

<section anchor="urls" title="URLs">

<t>The following field names (paired with their replacement field names) have values that can be represented in Binary Structured Headers by considering their payload a string.</t>

<t><list style="symbols">
  <t>Content-Location - SH-Content-Location</t>
  <t>Location - SH-Location</t>
  <t>Referer - SH-Referer</t>
</list></t>

<t>For example, a (non-binary) Location:</t>

<figure><artwork><![CDATA[
SH-Location: "https://example.com/foo"
]]></artwork></figure>

<t>TOOD: list of strings, one for each path segment, to allow better compression in the future?</t>

</section>
<section anchor="dates" title="Dates">

<t>The following field names (paired with their replacement field names) have values that can be represented in Binary Structured Headers by parsing their payload according to <xref target="RFC7230"/>, Section 7.1.1.1, and representing the result as an integer number of seconds delta from the Unix Epoch (00:00:00 UTC on 1 January 1970, minus leap seconds).</t>

<t><list style="symbols">
  <t>Date - SH-Date</t>
  <t>Expires - SH-Expires</t>
  <t>If-Modified-Since - SH-IMS</t>
  <t>If-Unmodified-Since - SH-IUS</t>
  <t>Last-Modified - SH-LM</t>
</list></t>

<t>For example, a (non-binary) Expires:</t>

<figure><artwork><![CDATA[
SH-Expires: 1571965240
]]></artwork></figure>

</section>
<section anchor="etags" title="ETags">

<t>The following field names (paired with their replacement field names) have values that can be represented in Binary Structured Headers by representing the entity-tag as a string, and the weakness flag as a boolean “w” parameter on it, where true indicates that the entity-tag is weak; if 0 or unset, the entity-tag is strong.</t>

<t><list style="symbols">
  <t>ETag - SH-ETag</t>
</list></t>

<t>For example, a (non-Binary) ETag:</t>

<figure><artwork><![CDATA[
SH-ETag: "abcdef"; w=?1
]]></artwork></figure>

<t>If-None-Match is a list of the structure described above.</t>

<t><list style="symbols">
  <t>If-None-Match - SH-INM</t>
</list></t>

<t>For example, a (non-binary) If-None-Match:</t>

<figure><artwork><![CDATA[
SH-INM: "abcdef"; w=?1, "ghijkl"
]]></artwork></figure>

</section>
<section anchor="links" title="Links">

<t>The field-value of the Link header field <xref target="RFC8288"/> can be represented in Binary Structured Headers by representing the URI-Reference as a string, and link-param as parameters.</t>

<t><list style="symbols">
  <t>Link: SH-Link</t>
</list></t>

<t>For example, a (non-binary) Link:</t>

<figure><artwork><![CDATA[
SH-Link: "/terms"; rel="copyright"; anchor="#foo"
]]></artwork></figure>

</section>
<section anchor="cookies" title="Cookies">

<t>The field-value of the Cookie and Set-Cookie fields <xref target="RFC6265"/> can be represented in Binary Structured Headers as a List with parameters and a Dictionary, respectively. The serialisation is almost identical, except that the Expires parameter is always a string (as it can contain a comma), multiple cookie-strings can appear in Set-Cookie, and cookie-pairs are delimited in Cookie by a comma, rather than a semicolon.</t>

<t>Set-Cookie: SH-Set-Cookie
Cookie: SH-Cookie</t>

<figure><artwork><![CDATA[
SH-Set-Cookie: lang=en-US, Expires="Wed, 09 Jun 2021 10:18:14 GMT"
SH-Cookie: SID=31d4d96e407aad42, lang=en-US
]]></artwork></figure>

<t><list style="symbols">
  <t>ISSUE: explicitly convert Expires to an integer? <eref target="https://github.com/mnot/I-D/issues/308">https://github.com/mnot/I-D/issues/308</eref></t>
  <t>ISSUE: dictionary keys cannot contain UC alpha. <eref target="https://github.com/mnot/I-D/issues/312">https://github.com/mnot/I-D/issues/312</eref></t>
  <t>ISSUE: explicitly allow non-string content. <eref target="https://github.com/mnot/I-D/issues/313">https://github.com/mnot/I-D/issues/313</eref></t>
</list></t>

</section>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t><list style="symbols">
  <t>ISSUE: todo</t>
</list></t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>As is so often the case, having alternative representations of data brings the potential for security weaknesses, when attackers exploit the differences between those representations and their handling.</t>

<t>One mitigation to this risk is the strictness of parsing for both non-binary and binary Structured Headers data types, along with the “escape valve” of String Literals (<xref target="literal"/>). Therefore, implementation divergence from this strictness can have security impact.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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="I-D.ietf-httpbis-header-structure">
<front>
<title>Structured Headers for HTTP</title>

<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
    <organization />
</author>

<author initials='P' surname='Kamp' fullname='Poul-Henning Kamp'>
    <organization />
</author>

<date month='January' day='28' year='2020' />

<abstract><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 fields.  It is intended for use by specifications of new HTTP header fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-header-structure-15' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-structure-15.txt' />
</reference>



<reference  anchor="RFC7541" target='https://www.rfc-editor.org/info/rfc7541'>
<front>
<title>HPACK: Header Compression for HTTP/2</title>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='H.' surname='Ruellan' fullname='H. Ruellan'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.</t></abstract>
</front>
<seriesInfo name='RFC' value='7541'/>
<seriesInfo name='DOI' value='10.17487/RFC7541'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<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="RFC7540" target='https://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<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 perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>



<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor="RFC8288" target='https://www.rfc-editor.org/info/rfc8288'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2017' month='October' />
<abstract><t>This specification defines a model for the relationships between resources on the Web (&quot;links&quot;) and the type of those relationships (&quot;link relation types&quot;).</t><t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t></abstract>
</front>
<seriesInfo name='RFC' value='8288'/>
<seriesInfo name='DOI' value='10.17487/RFC8288'/>
</reference>



<reference  anchor="RFC6265" target='https://www.rfc-editor.org/info/rfc6265'>
<front>
<title>HTTP State Management Mechanism</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2011' month='April' />
<abstract><t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6265'/>
<seriesInfo name='DOI' value='10.17487/RFC6265'/>
</reference>




    </references>



<section anchor="data-supporting-directly-represented-field-mappings" title="Data Supporting Directly Represented Field Mappings">

<t><spanx style="emph">RFC EDITOR: please remove this section before publication</spanx></t>

<t>To help guide decisions about Directly Represented Fields, the HTTP response headers captured by the HTTP Archive <eref target="https://httparchive.org">https://httparchive.org</eref> in February 2020, representing more than 350,000,000 HTTP exchanges, were parsed as Structured Headers using the types listed in <xref target="direct"/>, with the indicated number of successful header instances, failures, and the resulting failure rate:</t>

<t><list style="symbols">
  <t>accept: 9,201 / 10 = 0.109%</t>
  <t>accept-encoding: 34,158 / 74 = 0.216%</t>
  <t>accept-language: 381,037 / 512 = 0.134%</t>
  <t>accept-patch: 5 / 0 = 0.000%</t>
  <t>accept-ranges: 197,759,320 / 3,960 = 0.002%</t>
  <t>access-control-allow-credentials: 16,687,349 / 7,357 = 0.044%</t>
  <t>access-control-allow-headers: 12,979,869 / 14,960 = 0.115%</t>
  <t>access-control-allow-methods: 15,469,948 / 28,203 = 0.182%</t>
  <t>access-control-allow-origin: 105,326,437 / 264,278 = 0.250%</t>
  <t>access-control-max-age: 5,287,263 / 7,749 = 0.146%</t>
  <t>access-control-request-headers: 39,340 / 624 = 1.561%</t>
  <t>access-control-request-method: 146,566 / 13,822 = 8.618%</t>
  <t>age: 71,292,543 / 168,572 = 0.236%</t>
  <t>allow: 351,707 / 1,886 = 0.533%</t>
  <t>alt-svc: 19,777,530 / 15,682,026 = 44.225%</t>
  <t>cache-control: 264,666,876 / 946,434 = 0.356%</t>
  <t>connection: 105,884,722 / 2,915 = 0.003%</t>
  <t>content-encoding: 139,812,089 / 379 = 0.000%</t>
  <t>content-language: 2,368,912 / 728 = 0.031%</t>
  <t>content-length: 296,649,810 / 787,897 = 0.265%</t>
  <t>content-type: 341,948,525 / 794,864 = 0.232%</t>
  <t>expect: 0 / 47 = 100.000%</t>
  <t>expect-ct: 26,573,905 / 29,117 = 0.109%</t>
  <t>forwarded: 119 / 35 = 22.727%</t>
  <t>host: 25,335 / 1,441 = 5.382%</t>
  <t>keep-alive: 43,063,257 / 796 = 0.002%</t>
  <t>origin: 24,336 / 1,539 = 5.948%</t>
  <t>pragma: 46,826,446 / 81,707 = 0.174%</t>
  <t>preference-applied: 57 / 0 = 0.000%</t>
  <t>retry-after: 605,926 / 6,194 = 1.012%</t>
  <t>strict-transport-security: 26,826,043 / 35,266,676 = 56.797%</t>
  <t>surrogate-control: 121,124 / 861 = 0.706%</t>
  <t>te: 1 / 0 = 0.000%</t>
  <t>trailer: 282 / 0 = 0.000%</t>
  <t>transfer-encoding: 13,953,547 / 0 = 0.000%</t>
  <t>vary: 150,802,211 / 41,317 = 0.027%</t>
  <t>x-content-type-options: 99,982,040 / 203,824 = 0.203%</t>
  <t>x-xss-protection: 79,878,780 / 362,984 = 0.452%</t>
</list></t>

<t>This data set focuses on response headers, although some request headers are present (because, the Web).</t>

<t><spanx style="verb">alt-svc</spanx> has a high failure rate because some currently-used ALPN tokens (e.g., <spanx style="verb">h3-Q43</spanx>) do not conform to key’s syntax. Since the final version of HTTP/3 will use the <spanx style="verb">h3</spanx> token, this shouldn’t be a long-term issue, although future tokens may again violate this assumption.</t>

<t><spanx style="verb">forwarded</spanx> has a high failure rate because many senders use the unquoted form for IP addresses, which makes integer parsing fail; e.g., <spanx style="verb">for=192.168.1.1</spanx>.</t>

<t><spanx style="verb">strict-transport-security</spanx> has a high failure rate because the <spanx style="verb">includeSubDomains</spanx> flag does not conform to the key syntax.</t>

<t>The most common problem causing failure for many other headers is duplicated values; e.g., a Content-Length with <spanx style="verb">2, 2</spanx>.</t>

<t>The top ten header fields in that data set that were not parsed as Directly Represented Fields are:</t>

<t><list style="symbols">
  <t>date: 354,682,923</t>
  <t>server: 311,299,092</t>
  <t>last-modified: 263,851,521</t>
  <t>expires: 199,985,746</t>
  <t>status: 192,439,616</t>
  <t>etag: 172,071,630</t>
  <t>timing-allow-origin: 64,413,748</t>
  <t>x-cache: 41,743,978</t>
  <t>p3p: 39,495,307</t>
  <t>x-frame-options: 34,041,316</t>
</list></t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAOYwX14AA9U9+VfbSJq/+6+oJW9fQ7dkLPl2Nj1LgEyYBsJw7PS8ffs6
Zblsa5Eljw7Ay2T+9v2OKl22gRzzOpNuEluq6zvqu6uwbbuR+mmgRuKtH8p4
Ja7SOPPSLFYT8f76+kK8V3Ki4qQhx+NY3Y0ak8gL5QLaT2I5Te0wSlM/nM3l
wh7TAHaSD2DPua/dchsTmUKfx6OD6+NPDQ++zKJ4NRJJOmk0/GU8EtArSd1W
awiNZazkSPxRhSqWQeM+im9ncZQtR41btYJvk5E4CVMVhyq1j3AVjUaSynDy
mwyiEGZZqaSx9Efiv9PIswT85YcTFaaWSKI4jdU0gU+rhf6Qxr4Hr7xosZT6
wwIawys/DPxQ/U+jIbN0HsWjhrAbAv74YTISZ01xnoNOjxkrZzK+rb+J4pkM
/f+TqR+FI/FOJmmwohdqIf1gJBaAxP/Ev5oAEb3IYlj+PE2XyWh///7+vmne
7jcaYRQvYKg7BQsSl+8OXccZjgCJ4bR40WjYti3kGKADoBqN67mfiGSpPH/q
e7QOMVFTgC4RUjDdRKJiXwZ+wq+jaYUTmJACpiCusASieibu/XQOI4RAzdTn
jgvlzQHaZEGN/TQRWaIAZ9Rv322KkxQ6J1G+gHl0DzSiVltmXMhwJdSDnyBS
hWYqAQCmcxWr8UrsjKV3uwTiwvsdfLrAt/dzFYokW+ILGBHapfeRWCro3NQY
Aqyq387xrzT67VJzeuNHwKo4Pjq5/nA5EstASVharBbRnYKxEZHKI1DHClan
xDIbBxqrPyKqAdokyQAyQGZKAFAv2i/Ck9gPnmbhRMhU/Ieh8gxQmY2bwH77
SOz9E/toP5BjFST7WzfWz02ebxHBRLHygG/FbjRNVWiJLKR1JXM12dNzwyLK
MxJP6Wn9iCbcOtM+TnXJMyB9Z8g5ADuCqJ4HBDcVsML+bG4vJfR9GqQrpZhF
gJK89B8S4WVxjLPDTk+zBBkK354cX78TIFskMvqtioEx00a+lNKLpq/SaRN2
4j4IsP2Xyy4CHFll4U8mgWo0XqHsiaNJRjzQaJCQXKgkQbgEIV8sZZLA8kBm
zebALXcoxkDkAKoWxLde4BsRA2JsoSa+jH2F0kjF0Bg+gDQD1h2bPrAblfTm
zPOA7KWMgSex0TKOPEWzKT/We4NeANx+AJ+nvgomSVOQCIjVUkkkGA6Am2kX
m/KiY2VXRMCekJMJMDG0D70VjelFYZIBrOLw4sYSKJ5nK15rhFsRhkiiLIb1
IBG3Sw/x+PhvwBVEEhtpNfYTje+CAp8+wbqm2E0CWlJEAZJTpKulShgLobrP
pQHuK+AyoKNCaaIelnGBlgQEbZj6nkHD50pCEP+A7nxpxH2Pj3rqT580uXhQ
fFsXeki3fM4gQJwlSAKC6v3FweEv4tRPiUsYV+IdUk1cKoQCWIVWkohdQBzI
pn6343z6tIej0kKM+AWcAeIfH400BBR+rZB9Woai7FnG/gKRNotg9YSrNQSj
oIDJYcbMUznrgTiNcRpCHmwYUNPEmh4Is4QwRDoZ15myKEjVQ5rBLHEFLZtV
VVMcoJyOwkm+OBR/ICphMVrZg/qKURSj2kRMopSC8RIfZiGEwyAh7gIfv8EI
ZhhksFCOA+ic4awCTRSByg9Hn8UyzAKZ70acDZmxoh1JBb16haaC1KMfRuEd
AIUTM2rB2sGRYRPunN1cXe9Y/K84/0CfL4//fHNyeXyEn6/eH5ye5h9Mi6v3
H25Oj4pP/LwBPQ8/nJ0dnx9xZ3gqao/ODv66w2y98+Hi+uTD+cHpDstc1GSR
l6GNZAg7VizIAEpSBkljohIv9sfwBfq8PbwQTkcw76K1AnzJXwZOvwNfkMm0
GAmDlf4KBAehswR5FeMgsG1gjy/9FBQDMkcjAZYOBRoAhMlN5qvm4cdXZqca
Q0jr72c2PmvuDRtGXJMM4u4T3oMvEWh6x7AEW4LgBzuBuEgmzN/R0g5AWwQb
WZolubiTAdoWsPePfAIDFm6B+EhSRuFJytYP0qa0QtQzpEekwZSROFUhgzJm
jJYvSI89C2jhg9qhnQO7LpCeIsKXUINbectQhJhcXgH0eua4JtZIapCJJf0Q
x2MM1SB4fARLbErj4MZBTD4NyeMrDQij/enGXwhilQdyWC1xpXms23QtGksr
hLcn5++PD46OL6/ENJaoSwHh9AnwDaD94x//ALO+BT6AAz8u/LThpwM/Xfjp
wU+/8RPYI0/+NP4O7ZBJxW5nD/2Jv4uLUxXOwFjf7fwET/6ej7HtD45xIVdB
BAL6CPXurh4g8lKVJvkYT/35iaBpHJjtFWgc1uQ3COkUCM97YBoFQXSPGGfD
BXyZHwkUcJzAtoChUlS/E9ItyCp6QxkmWvKam9BLgzwiVgmzxRj2ELRiAJAe
E9ZKejHl7mjceNGEhBnu1K3EdSzjA3XAhgTDDLxK/4FmLyGPl5CPrccE2z66
1zKhAFu3Wt8DI2T7V7TTQT/gP0YW7GLbN60HZ0/MJTgpMh8EDTat0WnrgzBS
coGf18UlC7UcHQa5C4WIyzcpGvxNcaYfkhmGazwhMxU/5QOUkeeHYCvaQP7F
p0+v8yHz3vwah352DGxEMuAE4AGLhcdC8w+sedREpb6kRATCgmq+kJ6CtCi0
NfKep5H1vQ47U7Ms703Cfy51wdJrNAoZXCeG+xnE0AiBKY7Rytcw+UkFEWB7
STIJAmJrS/OMtsoQlWTCjVepyqnFI9kYmqi2/0zy2wTcy8ST+Grx9cwPSKZf
TsXu4CcSbRv+gPQrAS52obWWWl8/91cLZ1h9GafPt9cyFCxhAAa4EXxhFo24
VUg8/nL6WTKuwhSfLecGJTkHc5cGG4kc0Rv4r2hLcI/EB/DU0O9Ak7nOjsyN
jUa5x9dJm7Ux/pVkDsEL06NpVxMz7WfEzJaNTkqoYqVX0WZmrq4ObWmzOvLw
K+/MksDkIMdgTi4zNmEMkNCbl2zZ19rIh8aGUz0Zw2rnGwzenHCI863GPtvA
C7kSmjQb/AEcJwjAtwNPIPPmVj1IoFcvU22Gbzf/kiftPlbtMLKhjM8mTnWL
lIBs4mY+ubq6OR6Rufg+m04XFNeYwBr+8HSIjWOO++1W9+cGW8jbZDzQEA1p
aHQMLvg2XYCBthiWqbd9l7Y9WVq8YkKQj3F1Dnqw8UauNECGVpoGe/SdaA3W
DWwVd/dyTaHttGaz+fVTkKhuXEWLdYlmkK+NXUDOBIlK9uxr4L2QWJOEBEa7
yq9xX7ReY3zXX1LckJv5szDibQYsxpsklxe4k9lSBGqXhBgbm8XrIqRWNSKT
kjzRkVambU7Mfw7hmEinu21yUkRuZ+5+mQZngpykaxrzSxRm8gXKsl1Vlhqc
kTDgVA2+kokNAwRBTbWQvgjZwd+tiuu918LfoJu2KiMz+mcqI8ptEPPgGn9I
CqMEY9lToZdqkQQtjY3xm5KLc2F6ac57fMzHIVBIK0wiEuHIdnmotOShma/F
cgzz56Mj7xcD8+pLL9dZ3/2eWL+00t+X+9PoFuNxX8v7BTxr7J8TaYPL85kO
Tz7UBp9HbtN0a05PMcq/mt9Thf/7c31qmBW7//XyBX57T6jOLV/rDFXH2+AP
VRtUemiv6GADk6ZrTCrFmHyYTaqg0bioDsoGbd4hea1tt0QH2U1OgR2JQqRT
Ij1RwR0ZFic1CJLP9H++UOWUxCACIIN7uUrK6SKiRDrfZnFpWBeUZE1VsEJq
eQqpjOA1BcC1rM6BQKmHZeB7fgrtpZYgESsD7m6i1JbgMDHiNoGea699TruH
QsVxFD9t4VOcuMoin2X0G1cxjz0ae7/EH0DIcOLf+RNMpK3nGNiz1kUKZVGc
JUY4ajxX5zBx8HJME+f7PmwEWIi2Dih7r2ZU5sGmMH3bYAy0f2dj4ArFuVne
rvvTN9L9VyORgOeAjsVrWDAyrZpR1ZAFa4evyyjx8SsyKs/OItXnL18gJN2y
kNRUeAcoTTUN6PMGCnTWQhu/Bwm+ggbfQmGKdyZxM3jB9N9oSiwa45z0y2b9
ZzEbpc6jkMTFV7EdJmQKqHiOaQHl10wzqEyj2ZuVmuZvreHWGbz7PfkbepW/
r6/B8cKvdDaQ2AxN4Wl8w9AaEfganSJUreQdaeeSHm6gc+97ojMv8l/fpUQq
Eyz/PCK/Bc8S1vG3DBaq9GauPNtA6/73ROvqYn9fmqObDvYer+Ub0L4CW4UH
NPGiKFDSlFLpbxsINqgTDI3G+4gir+vkqmIO3rwlG+FXUa6p4HeMtim0AEXX
Yr+IXSH4/k4GiaKgHb12aq+v40w1YVRUkRwJRriwzOmG7PDtxU5FzeHjq6Iu
sNH4CxbyjSNAJRXvoTcjMRgdalTrGr8N5XvaS0SfIJW3YI5N7mSYypkuuQDT
7TaM7gM1mVExWG7S5zWE1IbGwIa6YGzD0ncjVvgwKxZFGcdugeFxJcpljeQY
EhiwGBWnvi6GnfiJh2WFGgoNErsu0uAlUVT1Wy3d0Q9NLaeHpXibMiMlNEsu
4GFuqgymy3maW7IwZowrvZDHV2b2RuNAw4PPzfrRK3xiJYAED9HGtd5boIU9
dXx9fXL+x6vf3p6cH1z+9ber68ubw+uby+Oj30xB0m7r4frD0Yc9XeoNXiKM
9IJ+0zha4AZSGMHj0hydsIMN5DS5+AVfaoiSJ/z1WlldXmPbbLilgSiYUCp9
3lBWJZMtRGk3BW0GCe7jfaiLMHRlMziCkUrIqQz8W3WPjFXsDGBjEluEz7Sy
ljQGUUN+KJ0+APs1EvU6L39adAKqMYH2MIAg2YX1ddg/o2QQnmgRu6o5a1qf
Xf1aLpX+7DJFoH+njuscGwWgWJGpNYKZAnB+EPgS5f87fgN+u+QnWLBMaOGE
VRiFtn5DwBPBQBhhIX280hEEGFdmQVrkj1/AjChsm+Id1+UCysBMo0wtzLwB
Twt/Nk+5Ni/FJoZ9K5sP68wJl+XSw4Lh3pEYeHzFHKZFrd4OqFrMmCZnmpb3
wVqxdCENLKp8DyeczqGPdV7nqTmnWWzejeujRmOFHnVCMq4Wa1cP4A5huAt1
YbWricBoFd0qq+he093TOho8KBjFU0t88RqPSaWK9WkRPPoW1ZQ+EawiRF4y
nqlqBQRp5sxLCjYwBmKcog/l/OrTEbEti/CiGL6Cf8lRwYin5W33Q1Iq+iU0
27au5S1X90YcmHtdXQwLHtLr62HVZyv9mqhsTGU7HUkIVzpgu+uHXpDxcunk
Q2l/r6Nqz4QLPyeyayqLSXUtoglpjIrBYCKxT85tURPAhz/Z+JaCs1L7loop
4IOqpBJfzSNG4IN4m7MBQ+cRtuonlAgJpvjNmReZRCFgE4+R8Wx8eOOc1VAR
tK7iZ616Zi3XCht0gRasxseajjN4J2OFjmfA6mVV7WDeS7833FqtqonKdTpb
CrPvZOxH2Sb858VE4eRpgEQu+PVUXpTRkQGsMQFo6exDnChiRPESMNewAZAa
7Uy6SS/esF8F7O3kbYoTfcrBA93EmleXI7E6Je+GC8hQb5lspKrxVVKyivNU
dR54rxQ45YVH64YuqmHcgLoMPzU5l91JRIdQfGLBANrjJKUZ4zzlQAbGGpNr
ZLJG3lQjFWuEr/QZjgLbL+DddxVcY5w/jWKV+8J84qks4cVkFcqF74GHYUz/
KEtzB76wumSAb/BUnVaaW7cpa3ZuxgRCLQ9YwpqvfMSksnHLUAJH1wy4s4O/
Ih8u/IciG5QQg+ZulAXiaqnljG4Rg4vqx8QY+YZird4EYymJSISZejM8/rK2
RxGBJXd5C8CvdacwFzulPnmdHbqHiP2XupOk2I/NqTCtNx9f5RwKSiSs1evh
dl0CSMDSqFgQZXRcsdAKtZwT6oC4UI4oL2dRDBMvkpcbrXwEr6aBtsHVFO+j
ezyWaXEJgamWSSIRgfWyQHDpoF5+WI2sei2I1MMSjco71aydJypVw01LFgbb
9ElGAwL3ecqYJBNgDC81TifrWuqiZ1rg+afJ1k0Kgkd7e3g+CmzpEgvwBLnt
rS3XI5oQlnFZMmRyqurl1E8k0JHNMnNtto0KIm+SJ9+CxgZNGS/BoLRqehRm
WdXw2m4Gkb2OxivvzkRvv+QHA9nGRLeeaL2wFiv22GHBRRoreEMp13Op7x/F
gYfWtGCTMP9uHxs1V39xKsNZhpGZ+osLmeLp4drTSz7HXXmcJDbo4jSOAvsA
GcA+BNB4L2NLNEO3tTS0fnq8MwV8Pnmu1YfYnwFfbJvwTD7YBwTn5veXGBdM
0meXZNrxokrDVcbGFZWGOL04L30LUvvqzhPl43j68Q2yYz7KofTmykxcb35Y
BOLykbEpIH4Dtc2bdXLnbzhnWEyun5MTmD89BkHmpfXv9uF1fXnvovhexhMC
p/LiPV48kPf/Rakl0A8kY71dnZwXsZwtZL3VRaymoA82PsUor32wXAb++iou
VRqv7INpSp2pAkLsoinlgZCSKRcl7GFWKAOLaAa+xjY6XB8XuLzWB+jLD8IE
lrKBIv+FoiX/9qtdxrf9YckGYQ79r/avV1f2RQxKskLzkiWSWwITFaTS5pPM
CYeJQEyVIS4inWryGqRK+Z2WQ1xzzHFBFK82+lusl0LFBjXqNbYmCzub9E51
Aej7fPYBhnpQ6PGV0UtfqGrKkhTYqiSD54VqROWZq24CBSVzKTDGygTPt2uI
jOKAsbMgrUl3bayUFC7eQEPJ7NKK0fgFHKkHid4Auw9HiGyCrGYnxXiGrEyS
ynnbuk/G5KN7dDgtcURX6lxlYHW2euI8uhPOcNgRrcGoMxy1++KPZ9dF7iZP
LdB5GzUF0xlryYPVhgpjk30vMjvEBCLnQoz3ImQ3of8g1DKCJe+2WiP6X9xc
H6Lt64g/yTDDfeEM+y0wtPwQ9Hag5NKMs4feTZboijHGmJBjvGblPsqCNZ0J
lN7FsCGfJt3bRHZpUjZX721GT3/QafVdp9/X1YPapJ0YQ6g8Aat9qlJKdRFC
iEKvOL6i7SzT9rMsAzb9kmSaUbjlm5kJhdConCLgXIsJfoTqIbXn0bI4RVCK
MicVs4cyY+aeisKa2nzHTyXCVrqHYs9cjpMPsGgCBBxEttbOMtTC5+heFBGD
LCwHis3AU9ZJxTlFuoGFYwMUeoVtGBmBlmQLDjroOg9tmev6MS1gyOdfyrEP
6F2Zs5gli1rfdUPapJTnqB0bL9rTvRbiXq5wUSCNSiTfaM9X09eUAVJY9Abk
1U5dktDtIzlVJ/6UVCOQfgUi/oH8/PCHVOzAPrvdYalH90WZkANw9zhLuSoR
G/L1V7AP8tA7cn89lKEDWCZoUCIPG9mersGj20JmnDfieLpONpaJkETT9D4/
YmVWXMp5ICWaL0zW93/msseby9OkrkzKemR3Kf24VC3qx1uoluiis/Kpsw3l
kBgS2eo0c8wtAXcw1uxZOgRmBDtRO7fXIh39twVIrvpTzLVXGpReXJJxFPNz
/aWmg2RVbJrOhaTMn4gdg3TdmbA+jaIdlp7XHz4cjfh8CgZSuMjJIt8Jo6KK
i/lTvPNotqByKtyOZD6PVZrW7kIxlRGUqvmDPl2NW+p7ImQpAFAmYtmd1YEs
t11JjPSbDv7HPuvaCQM2MbbqW6NpWe9W9e3xl+tbZDmyRohb8BNb/X5MbiA8
019QEE3tM7ByAaET+8rH+hFqcHJ2xS9vwsWm1zf4+lSiT6Vfa5Y9e5or9cQF
U5oHwun2nWGv63ZazITIJsfXcvZdsckagfFjurJTOcvzMRzA1Em8exDQIWav
p4FpMtY1Kjv3O6UjMbhRUjQMscYc5la1FHt9NtBiODbVlrRQ8mZhokonwYpm
sKRIyyHEp2YA+LSZUm8NpaBFiUz4TezIsQemwM5rcf/mD44pfbHPQTKAr54a
k9ZIDp1y0Ge9i2PIZPyxGqx0ZtY6f4aFKn2KFUK/+gItsTOb+/97G2i5pi/W
CG8NTyF72LnZx2mE8LZqv+srjNzB4NOnb8IyN5cnWoLjdlrjmgBWYBNf6NvD
dFU94QuXN6J9Bh+ekf/YtJD91HFnn+4H2sFTpsGbHS9armKMn8MDGXrzKH6z
86pQA4itwyi69dV2fPF7Tgyp1NZftYXJqOu5ve4XoI4Qc8pnJNN55fAGGVzl
xCnG/1Ae36lgxSUN1SuekCsDuj2RY7dg9Vo6h11sLiMgK8fUzEEU46btYqI/
1dfQ8RFfSReKyT2QxehOonfjERpsrTmpdXHFVYEnU4REjVGSmYtgAn/hawRp
jNK5NpoHoJVk78LCQyodWPheFFBushiamKT42ig91U8MZ5T7BDKcvVGhfXNl
GXS82fkLnvZpDcWfslC4LdcRTmvkDEZOBz3PnUY+Igx+cvSm7Uw6k2FPgTsm
5aTjWqVBma1y47d0+MaYnIYGaE/kCvOlFZ2Dn4uxJ8WFLbdqlcd2Dc1uDoGy
y7l8of3puD9vXDbbPLjr8nQnmXQvHbb9M100eXB+gCYiWZJSXwyXT5dGkwhb
gcGRxSDW11oeUHEY5jTofkey1imnCQqPk6RFBGND5pciJWNmVKpbMjkdzoCb
WY0iw9A32f8yTenGzYQQEvlVVwW8DLQF7xWtKErWp9YaEm+zhI8Bm8p4WQiw
vj/jfUvOBxaw+MmtuVaBXRnSqdE0t9twrVT2WIhAmmG8Vb4UEaLKLbc4xQ5o
KrkkY+FO7axfD1HPhKLEicldtdbKDgDr8YwkvTbvWCMbEPLAV45on+4sNDfX
og9GGTy6nOuKA4C4lO0pHnHGEbGvvuE2AkUYLMUsA24DoeT5XGEF2htcyydS
TGyEUCSMEzOlIlHAK5NBZ9Op1UHszZE7802D/0p+iHe5/oyC8J0ax2T3ggxq
WVW1uuAbEgCX7W7LarXoh8cGKc/32ALbomn1ZPqqCINw6FCHAmpJvJxPioqv
kkmfR3+MGYExH4kbwhJT6Qfo2hf2YRGD1O9QumPkz0bnA/TTSAwtt+WIfRC7
4o1oNZ3W8N/zt7ZJcI9Eu2M53QG063eonev0Su0CnUOAdgPHarX70LDruDxi
u1NquSSzSnShAU8IqCy9jgmZI/Q+rH53aLXdFrRsW8Oeae2a1kliezoBQ4LS
9oocEwzQs3qDvtXuDHHNVrvb5/6dztb+momgr2sN+0Nr0MO+Tief3HG6Wzsv
OCGFjobV6Q2tYQeR5Q4Au23uPNi+8ogSG9C31QWIe1aHEOj2OpbbHzC6u60N
vRfywSasdy0XgHV7bQK2D0DTlJ3ehk6xzlbl4LYBzR1Ec89F2jrNbs95oh9D
Covt9Kxur4coalsDF4k9aPacAXXFRfUdyx26VreDq3J6A6vbZ45w27wuhB2m
7zpWv4UAO9Zg0KMW3XabW6R2cuchO1j9ft/qtnGZgOHewLVaLrbtdJquS2Tx
KDWmVzsi7PV6PWvQxyUOO4hVZt12l6Yv6i0Y8YNBx+oDGIB4a+h0Nbu1dVMK
pRTbwQGkDYBPWgPkkXZ/WOZl07zYFa7VBviHDo7ed5mkrbZTaayvGXSHwLkd
HB1h7QNZB0PmXTB0yx1Sus6w3XGQ16yui1uqP+wA2+od2iaGU5SOGwkcrYMD
Oa18ofzOxtfAdd0+7LMWDuMOLcfpl+XB1OTuAHSHQEYEuW6z7/bxPehgHATY
t90lSnY6DjToNtvM9reY1JOY1BuJTttq9dqW2+3TinvljW12gtuBkYi3gOhD
GgmgxBZLSvrBKEBa3CodbDVgFqIF9zvcLM/3Sc73wS7p16VOTFkuiVmukegB
EwxdHK5nOUPeCi2HlsUq1aYAM6pI2+hTQhyuo0Vc3oaNCDzX6yNQ3V6zPyTs
JHnGMGdPx3UsB/YbrL3n0JL6LWJLTDc49XXqa7hhtoG74R0nFMvcaQ27bdh5
awDfSfx9CQ6osUHLtVwHZwIOamtqt5iaD3aZyeyIU4+gK0Cu4c4jaQGCDSDX
vMb75MF+AIGxzFOSIAOAkfsDqz8gMd6DnTXgHp0uIJYLX8hUwuuKppFHJblR
uKbZyzVbWDWphVGRsomVORMudsfKk5kpu/uLGmPI6qOWJR/1OZ05OKYVpSh0
Lx5f3xMfrGyq1KNsfcqn9XQx/cd52/5zp/1xz8T/AWWce4jQJ/gh0dH0puDA
Fhdk4TlRLFHUNfdUvd82tT3cCAb+aM62sRk1xzwWhrfHeIwZjUkbHW3+BQEl
zOhrpPU68foyOUN35M6P8P51Hg3D/wsiKGIl39fP44VqnExyyCw2C/+WRalJ
qqCZfHKBd13HuS2PmciFvKXrzjlAmRvVMMtrobEJXd84Q7cJegIDnh9xcVt3
3fOLJURyAbK6ysZHEV4KnHzkOFlex1giGXbAW2I00Uq/EUHf5w1cPQ6ofCtL
ygZVfus5p4kMQyJfZ8tAG3AcFzTAynqFBZl8H8GZdT+a252jpUB3qxwr0r+u
wJxyxx3DlWFKFzkXxudTFVp88M7mHDBIrA5p06HbRkFFvzkAnjqou4dWa+jC
0wADsSZOixIPNj4o7a7rsA7REVaSDl2wPnokMfEXLOBTFxTv0Oo5+FSlGOdz
+iBDwDrotVsov3xM6NQsIVDeHZBi/c6AxRHq9hFKqj5oj2Efny7bS7JdOkPQ
Oq0+taMay0JegdHaIunWo0LF/wfdWsGCp2YAAA==

-->

</rfc>

