rfc9292.original.xml   rfc9292.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.13 (Ruby 3.1. 2) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.13 (Ruby 3.1. 2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-httpbis-binary-message-06" category="std" consensus="true" submissionType= <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
"IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> -ietf-httpbis-binary-message-06" number="9292" submissionType="IETF" category="s
td" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="
en" updates="" obsoletes="" version="3">
<!-- xml2rfc v2v3 conversion 3.13.0 --> <!-- xml2rfc v2v3 conversion 3.13.0 -->
<front> <front>
<title abbrev="Binary HTTP Messages">Binary Representation of HTTP Messages< /title> <title abbrev="Binary HTTP Messages">Binary Representation of HTTP Messages< /title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-binary-message-0 6"/> <seriesInfo name="RFC" value="9292"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson"> <author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<email>mt@lowentropy.net</email> <email>mt@lowentropy.net</email>
</address> </address>
</author> </author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2022" month="July" day="06"/> <date year="2022" month="August"/>
<area>ART</area> <area>art</area>
<workgroup>HTTP</workgroup> <workgroup>httpbis</workgroup>
<abstract> <abstract>
<t>This document defines a binary format for representing HTTP messages.</ t> <t>This document defines a binary format for representing HTTP messages.</ t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message/"/>.
</t>
<t>
Discussion of this document takes place on the
HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.or
g"/>),
which is archived at <eref target="https://lists.w3.org/Archives/Public/
ietf-http-wg/"/>.
Working Group information can be found at <eref target="https://httpwg.o
rg/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http-extensions/labels/binary-me
ssages"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document defines a simple format for representing an HTTP message <t>This document defines a simple format for representing an HTTP message
(<xref target="HTTP"/>), either request or response. This allows for the encodin g of HTTP <xref target="RFC9110"/>, either request or response. This allows for the encodi ng of HTTP
messages that can be conveyed outside an HTTP protocol. This enables the messages that can be conveyed outside an HTTP protocol. This enables the
transformation of entire messages, including the application of authenticated transformation of entire messages, including the application of authenticated
encryption.</t> encryption.</t>
<t>The design of this format is informed by the framing structure of HTTP/ 2 <t>The design of this format is informed by the framing structure of HTTP/ 2
(<xref target="H2"/>) and HTTP/3 (<xref target="H3"/>). Rules for constructing messages rely on the rules <xref target="RFC9113"/> and HTTP/3 <xref target="RFC9114"/>. Rules for constru cting messages rely on the rules
defined in HTTP/2, but the format itself is distinct; see <xref target="differen ces"/>.</t> defined in HTTP/2, but the format itself is distinct; see <xref target="differen ces"/>.</t>
<t>This format defines <tt>message/bhttp</tt>, a binary alternative to the <t>This format defines <tt>"message/bhttp"</tt>, a binary alternative to t
<tt>message/http</tt> he <tt>"message/http"</tt>
content type defined in <xref target="MESSAGING"/>. A binary format permits more content type defined in <xref target="RFC9112"/>. A binary format permits more e
efficient fficient
encoding and processing of messages. A binary format also reduces exposure to encoding and processing of messages. A binary format also reduces exposure to
security problems related to processing of HTTP messages.</t> security problems related to processing of HTTP messages.</t>
<t>Two modes for encoding are described:</t> <t>Two modes for encoding are described:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>a known-length encoding includes length prefixes for all major messa ge <li>a known-length encoding includes length prefixes for all major messa ge
components; and</li> components, and</li>
<li>an indeterminate-length encoding enables efficient generation of mes sages <li>an indeterminate-length encoding enables efficient generation of mes sages
where lengths are not known when encoding starts.</li> where lengths are not known when encoding starts.</li>
</ul> </ul>
<t>This format is designed to convey the semantics of valid HTTP messages as simply <t>This format is designed to convey the semantics of valid HTTP messages as simply
and efficiently as possible. It is not designed to capture all of the details and efficiently as possible. It is not designed to capture all of the details
of the encoding of messages from specific HTTP versions (<xref target="MESSAGING of the encoding of messages from specific HTTP versions <xref target="RFC9112"/>
"/>, <xref target="H2"/>, <xref target="RFC9113"/>
<xref target="H3"/>). As such, this format is unlikely to be suitable for appli <xref target="RFC9114"/>. As such, this format is unlikely to be suitable for a
cations that pplications that
depend on an exact recording of the encoding of messages.</t> depend on an exact recording of the encoding of messages.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and are to be interpreted as described in BCP&nbsp;14
only when, they <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
<t>This document uses terminology from HTTP (<xref target="HTTP"/>) and no <t>This document uses terminology from HTTP <xref target="RFC9110"/> and n
tation from QUIC otation from QUIC
(<xref section="1.3" sectionFormat="of" target="QUIC"/>).</t> (<xref section="1.3" sectionFormat="of" target="RFC9000"/>).</t>
</section> </section>
<section anchor="format"> <section anchor="format">
<name>Format</name> <name>Format</name>
<t><xref section="6" sectionFormat="of" target="HTTP"/> defines the genera l structure of HTTP messages and <t><xref section="6" sectionFormat="of" target="RFC9110"/> defines the gen eral structure of HTTP messages and
composes those messages into distinct parts. This format describes how those composes those messages into distinct parts. This format describes how those
parts are composed into a sequence of bytes. At a high level, binary messages parts are composed into a sequence of bytes. At a high level, binary messages
are comprised of:</t> are comprised of:</t>
<ol spacing="normal" type="1"><li>Framing indicator. This format uses a si ngle integer to describe framing, which describes <ol spacing="normal" type="1"><li>Framing indicator. This format uses a si ngle integer to describe framing, which describes
whether the message is a request or response and how subsequent sections are whether the message is a request or response and how subsequent sections are
formatted; see <xref target="framing"/>.</li> formatted; see <xref target="framing"/>.</li>
<li>For a response, zero or more informational responses. Each informat ional <li>For a response, zero or more informational responses. Each informat ional
response consists of an informational status code and header section.</li> response consists of an informational status code and header section.</li>
<li>Control data. For a request, this contains the request method and ta rget. <li>Control data. For a request, this contains the request method and ta rget.
For a response, this contains the status code.</li> For a response, this contains the status code.</li>
<li>Header section. This contains zero or more header fields.</li> <li>Header section. This contains zero or more header fields.</li>
<li>Content. This is a sequence of zero or more bytes.</li> <li>Content. This is a sequence of zero or more bytes.</li>
<li>Trailer section. This contains zero or more trailer fields.</li> <li>Trailer section. This contains zero or more trailer fields.</li>
<li>Optional padding. Any amount of zero-valued bytes.</li> <li>Optional padding. Any amount of zero-valued bytes.</li>
</ol> </ol>
<t>All lengths and numeric values are encoded using the variable-length in teger <t>All lengths and numeric values are encoded using the variable-length in teger
encoding from <xref section="16" sectionFormat="of" target="QUIC"/>. Integer va lues do not need to be encoded encoding from <xref section="16" sectionFormat="of" target="RFC9000"/>. Integer values do not need to be encoded
on the minimum number of bytes necessary.</t> on the minimum number of bytes necessary.</t>
<section anchor="known-length-messages"> <section anchor="known-length-messages">
<name>Known Length Messages</name> <name>Known-Length Messages</name>
<t>A request or response that has a known length at the time of construc tion uses <t>A request or response that has a known length at the time of construc tion uses
the format shown in <xref target="format-known-length"/>.</t> the format shown in <xref target="format-known-length"/>.</t>
<figure anchor="format-known-length"> <figure anchor="format-known-length">
<name>Known-Length Message</name> <name>Known-Length Message</name>
<sourcecode type="quic-format"><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Request with Known-Length { Known-Length Request {
Framing Indicator (i) = 0, Framing Indicator (i) = 0,
Request Control Data (..), Request Control Data (..),
Known-Length Field Section (..), Known-Length Field Section (..),
Known-Length Content (..), Known-Length Content (..),
Known-Length Field Section (..), Known-Length Field Section (..),
Padding (..), Padding (..),
} }
Response with Known-Length { Known-Length Response {
Framing Indicator (i) = 1, Framing Indicator (i) = 1,
Known-Length Informational Response (..) ..., Known-Length Informational Response (..) ...,
Final Response Control Data (..), Final Response Control Data (..),
Known-Length Field Section (..), Known-Length Field Section (..),
Known-Length Content (..), Known-Length Content (..),
Known-Length Field Section (..), Known-Length Field Section (..),
Padding (..), Padding (..),
} }
Known-Length Field Section { Known-Length Field Section {
skipping to change at line 147 skipping to change at line 140
Known-Length Content { Known-Length Content {
Content Length (i), Content Length (i),
Content (..), Content (..),
} }
Known-Length Informational Response { Known-Length Informational Response {
Informational Response Control Data (..), Informational Response Control Data (..),
Known-Length Field Section (..), Known-Length Field Section (..),
} }
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>A known-length request consists of a framing indicator (<xref target= "framing"/>), request <t>A known-length request consists of a framing indicator (<xref target= "framing"/>), request
control data (<xref target="request-control"/>), a header section with a length prefix, control data (<xref target="request-control"/>), a header section with a length prefix,
binary content with a length prefix, a trailer section with a length prefix, and binary content with a length prefix, a trailer section with a length prefix, and
padding.</t> padding.</t>
<t>A known-length response contains the same fields, with the exception that <t>A known-length response contains the same fields, with the exception that
request control data is replaced by zero or more informational responses request control data is replaced by zero or more informational responses
(<xref target="informational"/>) followed by response control data (<xref target ="response-control"/>).</t> (<xref target="informational"/>) followed by response control data (<xref target ="response-control"/>).</t>
<t>For a known-length encoding, the length prefix on field sections and content is <t>For a known-length encoding, the length prefix on field sections and content is
a variable-length encoding of an integer. This integer is the number of bytes a variable-length encoding of an integer. This integer is the number of bytes
in the field section or content, not including the length field itself.</t> in the field section or content, not including the length field itself.</t>
<t>Fields in the header and trailer sections consist of a length-prefixe d name and <t>Fields in the header and trailer sections consist of a length-prefixe d name and
length-prefixed value; see <xref target="fields"/>.</t> length-prefixed value; see <xref target="fields"/>.</t>
<t>The format allows for the message to be truncated before any of the l ength <t>The format allows for the message to be truncated before any of the l ength
prefixes that precede the field sections or content; see <xref target="padding"/ >.</t> prefixes that precede the field sections or content; see <xref target="padding"/ >.</t>
<t>The variable-length integer encoding means that there is a limit of 2 ^62-1 <t>The variable-length integer encoding means that there is a limit of 2 <sup>62</sup>-1
bytes for each field section and the message content.</t> bytes for each field section and the message content.</t>
</section> </section>
<section anchor="indeterminate-length-messages"> <section anchor="indeterminate-length-messages">
<name>Indeterminate Length Messages</name> <name>Indeterminate-Length Messages</name>
<t>A request or response that is constructed without encoding a known le ngth for <t>A request or response that is constructed without encoding a known le ngth for
each section uses the format shown in <xref target="format-indeterminate-length" />:</t> each section uses the format shown in <xref target="format-indeterminate-length" />:</t>
<figure anchor="format-indeterminate-length"> <figure anchor="format-indeterminate-length">
<name>Indeterminate-Length Message</name> <name>Indeterminate-Length Message</name>
<sourcecode type="quic-format"><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Indeterminate-Length Request { Indeterminate-Length Request {
Framing Indicator (i) = 2, Framing Indicator (i) = 2,
Request Control Data (..), Request Control Data (..),
Indeterminate-Length Field Section (..), Indeterminate-Length Field Section (..),
Indeterminate-Length Content (..), Indeterminate-Length Content (..),
Indeterminate-Length Field Section (..), Indeterminate-Length Field Section (..),
Padding (..), Padding (..),
} }
Indeterminate-Length Response { Indeterminate-Length Response {
skipping to change at line 211 skipping to change at line 204
Indeterminate-Length Field Section { Indeterminate-Length Field Section {
Field Line (..) ..., Field Line (..) ...,
Content Terminator (i) = 0, Content Terminator (i) = 0,
} }
Indeterminate-Length Informational Response { Indeterminate-Length Informational Response {
Informational Response Control Data (..), Informational Response Control Data (..),
Indeterminate-Length Field Section (..), Indeterminate-Length Field Section (..),
} }
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>An indeterminate-length request consists of a framing indicator (<xre f target="framing"/>), <t>An indeterminate-length request consists of a framing indicator (<xre f target="framing"/>),
request control data (<xref target="request-control"/>), a header section that i s terminated request control data (<xref target="request-control"/>), a header section that i s terminated
by a zero value, any number of non-zero-length chunks of binary content, a zero by a zero value, any number of non-zero-length chunks of binary content, a zero
value, a trailer section that is terminated by a zero value, and padding.</t> value, a trailer section that is terminated by a zero value, and padding.</t>
<t>An indeterminate-length response contains the same fields, with the e xception <t>An indeterminate-length response contains the same fields, with the e xception
that request control data is replaced by zero or more informational responses that request control data is replaced by zero or more informational responses
(<xref target="informational"/>) and response control data (<xref target="respon se-control"/>).</t> (<xref target="informational"/>) and response control data (<xref target="respon se-control"/>).</t>
<t>The indeterminate-length encoding only uses length prefixes for conte nt blocks. <t>The indeterminate-length encoding only uses length prefixes for conte nt blocks.
Multiple length-prefixed portions of content can be included, each prefixed by a Multiple length-prefixed portions of content can be included, each prefixed by a
non-zero Chunk Length integer describing the number of bytes in the block. The non-zero Chunk Length integer describing the number of bytes in the block. The
Chunk Length is encoded as a variable-length integer.</t> Chunk Length is encoded as a variable-length integer.</t>
<t>Each Field Line in an Indeterminate-Length Field Section starts with a Name <t>Each Field Line in an Indeterminate-Length Field Section starts with a Name
Length field. An Indeterminate-Length Field Section ends with a Content Length field. An Indeterminate-Length Field Section ends with a Content
Terminator field. The zero value of the Content Terminator distinguishes it Terminator field. The zero value of the Content Terminator distinguishes it
from the Name Length field, which cannot contain a value of 0.</t> from the Name Length field, which cannot contain a value of 0.</t>
<t>Indeterminate-length messages can be truncated in a similar way as kn <t>Indeterminate-length messages can be truncated in a way similar to th
own-length at for
known-length
messages; see <xref target="padding"/>.</t> messages; see <xref target="padding"/>.</t>
<t>Indeterminate-length messages use the same encoding for field lines a s <t>Indeterminate-length messages use the same encoding for Field Line as
known-length messages; see <xref target="fields"/>.</t> known-length messages; see <xref target="fields"/>.</t>
</section> </section>
<section anchor="framing"> <section anchor="framing">
<name>Framing Indicator</name> <name>Framing Indicator</name>
<t>The start of each binary message is a framing indicator that is a sin gle integer that <t>The start of each binary message is a framing indicator that is a sin gle integer that
describes the structure of the subsequent sections. The framing indicator can describes the structure of the subsequent sections. The framing indicator can
take just four values:</t> take just four values:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A value of 0 describes a request of known length.</li> <li>A value of 0 describes a request of known length.</li>
<li>A value of 1 describes a response of known length.</li> <li>A value of 1 describes a response of known length.</li>
<li>A value of 2 describes a request of indeterminate length.</li> <li>A value of 2 describes a request of indeterminate length.</li>
<li>A value of 3 describes a response of indeterminate length.</li> <li>A value of 3 describes a response of indeterminate length.</li>
</ul> </ul>
<t>Other values cause the message to be invalid; see <xref target="inval id"/>.</t> <t>Other values cause the message to be invalid; see <xref target="inval id"/>.</t>
</section> </section>
<section anchor="request-control"> <section anchor="request-control">
<name>Request Control Data</name> <name>Request Control Data</name>
<t>The control data for a request message contains the method and reques t target. <t>The control data for a request message contains the method and reques t target.
That information is encoded as an ordered sequence of fields: Method, Scheme, That information is encoded as an ordered sequence of fields: Method, Scheme,
Authority, Path. Each of these fields is prefixed with a length.</t> Authority, Path. Each of these fields is prefixed with a length.</t>
<t>The values of these fields follow the rules in HTTP/2 (<xref section= <t>The values of these fields follow the rules in HTTP/2 (<xref section=
"8.3.1" sectionFormat="of" target="H2"/>) "8.3.1" sectionFormat="of" target="RFC9113"/>)
that apply to the <tt>:method</tt>, <tt>:scheme</tt>, <tt>:authority</tt>, and < that apply to the <tt>":method"</tt>, <tt>":scheme"</tt>, <tt>":authority"</tt>,
tt>:path</tt> pseudo-header and <tt>":path"</tt> pseudo-header
fields respectively. However, where the <tt>:authority</tt> pseudo-header field fields, respectively. However, where the <tt>":authority"</tt> pseudo-header fie
might ld might
be omitted in HTTP/2, a zero-length value is encoded instead.</t> be omitted in HTTP/2, a zero-length value is encoded instead.</t>
<t>The format of request control data is shown in <xref target="format-r equest-control-data"/>.</t> <t>The format of request control data is shown in <xref target="format-r equest-control-data"/>.</t>
<figure anchor="format-request-control-data"> <figure anchor="format-request-control-data">
<name>Format of Request Control Data</name> <name>Format of Request Control Data</name>
<sourcecode type="quic-format"><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Request Control Data { Request Control Data {
Method Length (i), Method Length (i),
Method (..), Method (..),
Scheme Length (i), Scheme Length (i),
Scheme (..), Scheme (..),
Authority Length (i), Authority Length (i),
Authority (..), Authority (..),
Path Length (i), Path Length (i),
Path (..), Path (..),
} }
]]></sourcecode> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="response-control"> <section anchor="response-control">
<name>Response Control Data</name> <name>Response Control Data</name>
<t>The control data for a response message consists of the status code. The status <t>The control data for a response message consists of the status code. The status
code (<xref section="15" sectionFormat="of" target="HTTP"/>) is encoded as a var iable length integer, not a code (<xref section="15" sectionFormat="of" target="RFC9110"/>) is encoded as a variable-length integer, not a
length-prefixed decimal string.</t> length-prefixed decimal string.</t>
<t>The format of final response control data is shown in <t>The format of final response control data is shown in
<xref target="format-response-control-data"/>.</t> <xref target="format-response-control-data"/>.</t>
<figure anchor="format-response-control-data"> <figure anchor="format-response-control-data">
<name>Format of Final Response Control Data</name> <name>Format of Final Response Control Data</name>
<sourcecode type="quic-format"><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Final Response Control Data { Final Response Control Data {
Status Code (i) = 200..599, Status Code (i) = 200..599,
} }
]]></sourcecode> ]]></artwork>
</figure> </figure>
<section anchor="informational"> <section anchor="informational">
<name>Informational Status Codes</name> <name>Informational Status Codes</name>
<t>Responses that include informational status codes (see <xref sectio n="15.2" sectionFormat="of" target="HTTP"/>) <t>Responses that include informational status codes (see <xref sectio n="15.2" sectionFormat="of" target="RFC9110"/>)
are encoded by repeating the response control data and associated header section are encoded by repeating the response control data and associated header section
until a final response control data is encoded. The status code distinguishes until a final status code is encoded; that is, a Status Code field with a value from 200 to 599 (inclusive). The status code distinguishes
between informational and final responses.</t> between informational and final responses.</t>
<t>The format of the informational response control data is shown in <t>The format of the informational response control data is shown in
<xref target="format-informational"/>.</t> <xref target="format-informational"/>.</t>
<figure anchor="format-informational"> <figure anchor="format-informational">
<name>Format of Informational Response Control Data</name> <name>Format of Informational Response Control Data</name>
<sourcecode type="quic-format"><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Informational Response Control Data { Informational Response Control Data {
Status Code (i) = 100..199, Status Code (i) = 100..199,
} }
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>A response message can include any number of informational response s that <t>A response message can include any number of informational response s that
precede a final status code. These convey an informational status code and a precede a final status code. These convey an informational status code and a
header block.</t> header block.</t>
<t>If the response control data includes an informational status code (that is, a <t>If the response control data includes an informational status code (that is, a
value between 100 and 199 inclusive), the control data is followed by a header value between 100 and 199 inclusive), the control data is followed by a header
section (encoded with known- or indeterminate- length according to the framing section (encoded with known length or indeterminate length according to the fram ing
indicator) and another block of control data. This pattern repeats until the indicator) and another block of control data. This pattern repeats until the
control data contains a final status code (200 to 599 inclusive).</t> control data contains a final status code (200 to 599 inclusive).</t>
</section> </section>
</section> </section>
<section anchor="fields"> <section anchor="fields">
<name>Header and Trailer Field Lines</name> <name>Header and Trailer Field Lines</name>
<t>Header and trailer sections consist of zero or more field lines; see <t>Header and trailer sections consist of zero or more field lines; see
<xref section="5" sectionFormat="of" target="HTTP"/>. The format of a field sect <xref section="5" sectionFormat="of" target="RFC9110"/>. The format of a field s
ion depends on whether the message is ection depends on whether the message is of
known- or indeterminate-length.</t> known length or indeterminate length.</t>
<t>Each field line includes a name and a value. Both the name and value <t>Each Field Line encoding includes a name and a value. Both the name a
are nd value are
length-prefixed sequences of bytes. The field name length is at least one length-prefixed sequences of bytes. The Name field is a minimum of one
byte. The format of a field line is shown in <xref target="format-field-line"/>. byte. The format of a Field Line is shown in <xref target="format-field-line"/>.
</t> </t>
<figure anchor="format-field-line"> <figure anchor="format-field-line">
<name>Format of a Field Line</name> <name>Format of a Field Line</name>
<sourcecode type="quic-format"><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Field Line { Field Line {
Name Length (i) = 1.., Name Length (i) = 1..,
Name (..), Name (..),
Value Length (i), Value Length (i),
Value (..), Value (..),
} }
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>For field names, byte values that are not permitted in an HTTP field name cause <t>For field names, byte values that are not permitted in an HTTP field name cause
the message to be invalid; see <xref section="5.1" sectionFormat="of" target="HT the message to be invalid; see <xref section="5.1" sectionFormat="of" target="RF
TP"/> for a definition of what C9110"/> for a definition of what
is valid and <xref target="invalid"/> for handling of invalid messages. A recip is valid and <xref target="invalid"/> regarding the handling of invalid messages
ient <bcp14>MUST</bcp14> . A recipient <bcp14>MUST</bcp14>
treat a message that contains field values that would cause an HTTP/2 message to treat a message that contains field values that would cause an HTTP/2 message to
be malformed according to <xref section="8.2.1" sectionFormat="of" target="H2"/> be malformed according to <xref section="8.2.1" sectionFormat="of" target="RFC91
as invalid; see <xref target="invalid"/>.</t> 13"/> as invalid; see <xref target="invalid"/>.</t>
<t>The same field name can be repeated in multiple field lines; see <xre <t>The same field name can be repeated over more than one field line; se
f section="5.2" sectionFormat="of" target="HTTP"/> for the semantics of repeated e <xref section="5.2" sectionFormat="of" target="RFC9110"/> for the semantics of
field names and rules for combining repeated field names and rules for combining
values.</t> values.</t>
<t>Messages are invalid (<xref target="invalid"/>) if they contain field <t>Messages are invalid (<xref target="invalid"/>) if they contain field
s named <tt>:method</tt>, s named <tt>":method"</tt>,
<tt>:scheme</tt>, <tt>:authority</tt>, <tt>:path</tt>, or <tt>:status</tt>. Oth <tt>":scheme"</tt>, <tt>":authority"</tt>, <tt>":path"</tt>, or <tt>":status"</t
er pseudo-fields that are t>. Other pseudo-fields that are
defined by protocol extensions <bcp14>MAY</bcp14> be included; pseudo-fields can not be included defined by protocol extensions <bcp14>MAY</bcp14> be included; pseudo-fields can not be included
in trailers (see <xref section="8.1" sectionFormat="of" target="H2"/>). Field l in trailers (see <xref section="8.1" sectionFormat="of" target="RFC9113"/>). A
ines containing pseudo-fields Field Line containing pseudo-fields
<bcp14>MUST</bcp14> precede other field lines. A message that contains a pseudo <bcp14>MUST</bcp14> precede other Field Line values. A message that contains a
-field after pseudo-field after
any other field is invalid; see <xref target="invalid"/>.</t> any other field is invalid; see <xref target="invalid"/>.</t>
<t>Fields that relate to connections (<xref section="7.6.1" sectionForma t="of" target="HTTP"/>) cannot be used to <t>Fields that relate to connections (<xref section="7.6.1" sectionForma t="of" target="RFC9110"/>) cannot be used to
produce the effect on a connection in this context. These fields <bcp14>SHOULD< /bcp14> be produce the effect on a connection in this context. These fields <bcp14>SHOULD< /bcp14> be
removed when constructing a binary message. However, they do not cause a removed when constructing a binary message. However, they do not cause a
message to be invalid (<xref target="invalid"/>); permitting these fields allows a binary message to be invalid (<xref target="invalid"/>); permitting these fields allows a binary
message to capture messages that are exchanged in a protocol context.</t> message to capture messages that are exchanged in a protocol context.</t>
<t>Like HTTP/2 or HTTP/3, this format has an exception for the combinati on of <t>Like HTTP/2 or HTTP/3, this format has an exception for the combinati on of
multiple instances of the <tt>Cookie</tt> field. Instances of fields with the multiple instances of the <tt>Cookie</tt> field. Instances of fields with the
ASCII-encoded value of <tt>cookie</tt> are combined using a semicolon octet (0x3 ASCII-encoded value of <tt>"cookie"</tt> are combined using a semicolon octet (0
b) x3b)
rather than a comma; see <xref section="8.2.3" sectionFormat="of" target="H2"/>. rather than a comma; see <xref section="8.2.3" sectionFormat="of" target="RFC911
</t> 3"/>.</t>
</section> </section>
<section anchor="content"> <section anchor="content">
<name>Content</name> <name>Content</name>
<t>The content of messages is a sequence of bytes of any length. Though a <t>The content of messages is a sequence of bytes of any length. Though a
known-length message has a limit, this limit is large enough that it is known-length message has a limit, this limit is large enough that it is
unlikely to be a practical limitation. There is no limit to the size of content unlikely to be a practical limitation. There is no limit to the size of content
in an indeterminate length message.</t> in an indeterminate-length message.</t>
</section> </section>
<section anchor="padding"> <section anchor="padding">
<name>Padding and Truncation</name> <name>Padding and Truncation</name>
<t>Messages can be padded with any number of zero-valued bytes. Non-zer o padding <t>Messages can be padded with any number of zero-valued bytes. Non-zer o padding
bytes cause a message to be invalid (see <xref target="invalid"/>). Unlike other parts of a bytes cause a message to be invalid (see <xref target="invalid"/>). Unlike other parts of a
message, a processor <bcp14>MAY</bcp14> decide not to validate the value of padd ing bytes.</t> message, a processor <bcp14>MAY</bcp14> decide not to validate the value of padd ing bytes.</t>
<t>Truncation can be used to reduce the size of messages that have no da ta in <t>Truncation can be used to reduce the size of messages that have no da ta in
trailing field sections or content. If the trailers of a message is empty, it trailing field sections or content. If the trailers of a message are empty, the y
<bcp14>MAY</bcp14> be omitted by the encoder in place of adding a length field e qual to <bcp14>MAY</bcp14> be omitted by the encoder in place of adding a length field e qual to
zero. An encoder <bcp14>MAY</bcp14> omit empty content in the same way if the tr ailers are also zero. An encoder <bcp14>MAY</bcp14> omit empty content in the same way if the tr ailers are also
empty. A message that is truncated at any other point is invalid; see empty. A message that is truncated at any other point is invalid; see
<xref target="invalid"/>.</t> <xref target="invalid"/>.</t>
<t>Decoders <bcp14>MUST</bcp14> treat missing truncated fields as equiva lent to having been sent <t>Decoders <bcp14>MUST</bcp14> treat missing truncated fields as equiva lent to having been sent
with the length field sent to zero.</t> with the length field set to zero.</t>
<t>Padding is compatible with truncation of empty parts of the messages. <t>Padding is compatible with truncation of empty parts of the messages.
Zero-valued bytes will be interpreted as zero-length part, which is semantically Zero-valued bytes will be interpreted as a zero-length part, which is semantical ly
equivalent to the part being absent.</t> equivalent to the part being absent.</t>
</section> </section>
</section> </section>
<section anchor="invalid"> <section anchor="invalid">
<name>Invalid Messages</name> <name>Invalid Messages</name>
<t>This document describes a number of ways that a message can be invalid. Invalid <t>This document describes a number of ways that a message can be invalid. Invalid
messages <bcp14>MUST NOT</bcp14> be processed further except to log an error and produce an messages <bcp14>MUST NOT</bcp14> be processed further except to log an error and produce an
error response.</t> error response.</t>
<t>The format is designed to allow incremental processing. Implementations need to <t>The format is designed to allow incremental processing. Implementations need to
be aware of the possibility that an error might be detected after performing be aware of the possibility that an error might be detected after performing
incremental processing.</t> incremental processing.</t>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<t>This section includes example requests and responses encoded in both <t>This section includes example requests and responses encoded in both
known-length and indefinite-length forms.</t> known-length and indeterminate-length forms.</t>
<section anchor="request-example"> <section anchor="request-example">
<name>Request Example</name> <name>Request Example</name>
<t>The example HTTP/1.1 message in <xref target="ex-request"/> shows the content in the <t>The example HTTP/1.1 message in <xref target="ex-request"/> shows the content in the
<tt>message/http</tt> format.</t> <tt>"message/http"</tt> format.</t>
<t>Valid HTTP/1.1 messages require lines terminated with CRLF (the two b <t>Valid HTTP/1.1 messages require lines terminated with CRLF (the two b
ytes 0x0a ytes 0x0d and 0x0a). For simplicity and consistency, the content of these exampl
and 0x0d). For simplicity and consistency, the content of these examples is es is
limited to text, which also uses CRLF for line endings.</t> limited to text, which also uses CRLF for line endings.</t>
<figure anchor="ex-request"> <figure anchor="ex-request">
<name>Sample HTTP Request</name> <name>Sample HTTP Request</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com Host: www.example.com
Accept-Language: en, mi Accept-Language: en, mi
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>This can be expressed as a binary message (type <tt>message/bhttp</tt >) using a <t>This can be expressed as a binary message (type <tt>"message/bhttp"</ tt>) using a
known-length encoding as shown in hexadecimal in <xref target="ex-bink-request"/ >. known-length encoding as shown in hexadecimal in <xref target="ex-bink-request"/ >.
<xref target="ex-bink-request"/> includes text alongside to show that most of th e content is <xref target="ex-bink-request"/> includes text alongside to show that most of th e content is
not modified.</t> not modified.</t>
<figure anchor="ex-bink-request"> <figure anchor="ex-bink-request">
<name>Known-Length Binary Encoding of Request</name> <name>Known-Length Binary Encoding of Request</name>
<artwork type="hex-dump"><![CDATA[ <artwork type=""><![CDATA[
00034745 54056874 74707300 0a2f6865 ..GET.https../he 00034745 54056874 74707300 0a2f6865 ..GET.https../he
6c6c6f2e 74787440 6c0a7573 65722d61 llo.txt@l.user-a 6c6c6f2e 74787440 6c0a7573 65722d61 llo.txt@l.user-a
67656e74 34637572 6c2f372e 31362e33 gent4curl/7.16.3 67656e74 34637572 6c2f372e 31362e33 gent4curl/7.16.3
206c6962 6375726c 2f372e31 362e3320 libcurl/7.16.3 206c6962 6375726c 2f372e31 362e3320 libcurl/7.16.3
4f70656e 53534c2f 302e392e 376c207a OpenSSL/0.9.7l z 4f70656e 53534c2f 302e392e 376c207a OpenSSL/0.9.7l z
6c69622f 312e322e 3304686f 73740f77 lib/1.2.3.host.w 6c69622f 312e322e 3304686f 73740f77 lib/1.2.3.host.w
77772e65 78616d70 6c652e63 6f6d0f61 ww.example.com.a 77772e65 78616d70 6c652e63 6f6d0f61 ww.example.com.a
63636570 742d6c61 6e677561 67650665 ccept-language.e 63636570 742d6c61 6e677561 67650665 ccept-language.e
6e2c206d 690000 n, mi.. 6e2c206d 690000 n, mi..
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This example shows that the Host header field is not replicated in th e <t>This example shows that the Host header field is not replicated in th e
<tt>:authority</tt> field, as is required for ensuring that the request is repro <tt>":authority"</tt> field, as is required for ensuring that the request is rep
duced roduced
accurately; see <xref section="8.3.1" sectionFormat="of" target="H2"/>.</t> accurately; see <xref section="8.3.1" sectionFormat="of" target="RFC9113"/>.</t>
<t>The same message can be truncated with no effect on interpretation. I n this <t>The same message can be truncated with no effect on interpretation. I n this
case, the last two bytes - corresponding to content and a trailer section - can case, the last two bytes -- corresponding to content and a trailer section -- ca n
each be removed without altering the semantics of the message.</t> each be removed without altering the semantics of the message.</t>
<t>The same message, encoded using an indefinite-length encoding is show n in <t>The same message, encoded using an indeterminate-length encoding, is shown in
<xref target="ex-bini-request"/>. As the content of this message is empty, the d ifference in <xref target="ex-bini-request"/>. As the content of this message is empty, the d ifference in
formats is negligible.</t> formats is negligible.</t>
<figure anchor="ex-bini-request"> <figure anchor="ex-bini-request">
<name>Indefinite-Length Binary Encoding of Request</name> <name>Indeterminate-Length Binary Encoding of Request</name>
<artwork type="hex-dump"><![CDATA[ <artwork type=""><![CDATA[
02034745 54056874 74707300 0a2f6865 ..GET.https../he 02034745 54056874 74707300 0a2f6865 ..GET.https../he
6c6c6f2e 7478740a 75736572 2d616765 llo.txt.user-age 6c6c6f2e 7478740a 75736572 2d616765 llo.txt.user-age
6e743463 75726c2f 372e3136 2e33206c nt4curl/7.16.3 l 6e743463 75726c2f 372e3136 2e33206c nt4curl/7.16.3 l
69626375 726c2f37 2e31362e 33204f70 ibcurl/7.16.3 Op 69626375 726c2f37 2e31362e 33204f70 ibcurl/7.16.3 Op
656e5353 4c2f302e 392e376c 207a6c69 enSSL/0.9.7l zli 656e5353 4c2f302e 392e376c 207a6c69 enSSL/0.9.7l zli
622f312e 322e3304 686f7374 0f777777 b/1.2.3.host.www 622f312e 322e3304 686f7374 0f777777 b/1.2.3.host.www
2e657861 6d706c65 2e636f6d 0f616363 .example.com.acc 2e657861 6d706c65 2e636f6d 0f616363 .example.com.acc
6570742d 6c616e67 75616765 06656e2c ept-language.en, 6570742d 6c616e67 75616765 06656e2c ept-language.en,
206d6900 00000000 00000000 00000000 mi............. 206d6900 00000000 00000000 00000000 mi.............
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This indefinite-length encoding contains 10 bytes of padding. As two additional <t>This indeterminate-length encoding contains 10 bytes of padding. As two additional
bytes can be truncated in the same way as the known-length example, anything up bytes can be truncated in the same way as the known-length example, anything up
to 12 bytes can be removed from this message without affecting its meaning.</t> to 12 bytes can be removed from this message without affecting its meaning.</t>
</section> </section>
<section anchor="response-example"> <section anchor="response-example">
<name>Response Example</name> <name>Response Example</name>
<t>Response messages can contain interim (1xx) status codes as the messa ge in <t>Response messages can contain interim (1xx) status codes, as the mess age in
<xref target="ex-response"/> shows. <xref target="ex-response"/> includes exampl es of informational <xref target="ex-response"/> shows. <xref target="ex-response"/> includes exampl es of informational
status codes defined in <xref target="RFC2518"/> and <xref target="RFC8297"/>.</ t> status codes 102 and 103, as defined in <xref target="RFC2518"/> (now obsolete b ut defines status code 102) and <xref target="RFC8297"/>, respectively.</t>
<figure anchor="ex-response"> <figure anchor="ex-response">
<name>Sample HTTP Response</name> <name>Sample HTTP Response</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 102 Processing HTTP/1.1 102 Processing
Running: "sleep 15" Running: "sleep 15"
HTTP/1.1 103 Early Hints HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script Link: </script.js>; rel=preload; as=script
skipping to change at line 480 skipping to change at line 472
Date: Mon, 27 Jul 2009 12:28:53 GMT Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00" ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes Accept-Ranges: bytes
Content-Length: 51 Content-Length: 51
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! My content includes a trailing CRLF. Hello World! My content includes a trailing CRLF.
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>As this is a longer example, only the indefinite-length encoding is s hown in <t>As this is a longer example, only the indeterminate-length encoding i s shown in
<xref target="ex-bini-response"/>. Note here that the specific text used in the reason <xref target="ex-bini-response"/>. Note here that the specific text used in the reason
phrase is not retained by this encoding.</t> phrase is not retained by this encoding.</t>
<figure anchor="ex-bini-response"> <figure anchor="ex-bini-response">
<name>Binary Response including Informational Responses</name> <name>Binary Response, including Informational Responses</name>
<artwork type="hex-dump"><![CDATA[ <artwork type=""><![CDATA[
03406607 72756e6e 696e670a 22736c65 .@f.running."sle 03406607 72756e6e 696e670a 22736c65 .@f.running."sle
65702031 35220040 67046c69 6e6b233c ep 15".@g.link#< 65702031 35220040 67046c69 6e6b233c ep 15".@g.link#<
2f737479 6c652e63 73733e3b 2072656c /style.css>; rel 2f737479 6c652e63 73733e3b 2072656c /style.css>; rel
3d707265 6c6f6164 3b206173 3d737479 =preload; as=sty 3d707265 6c6f6164 3b206173 3d737479 =preload; as=sty
6c65046c 696e6b24 3c2f7363 72697074 le.link$</script 6c65046c 696e6b24 3c2f7363 72697074 le.link$</script
2e6a733e 3b207265 6c3d7072 656c6f61 .js>; rel=preloa 2e6a733e 3b207265 6c3d7072 656c6f61 .js>; rel=preloa
643b2061 733d7363 72697074 0040c804 d; as=script.@.. 643b2061 733d7363 72697074 0040c804 d; as=script.@..
64617465 1d4d6f6e 2c203237 204a756c date.Mon, 27 Jul 64617465 1d4d6f6e 2c203237 204a756c date.Mon, 27 Jul
20323030 39203132 3a32383a 35332047 2009 12:28:53 G 20323030 39203132 3a32383a 35332047 2009 12:28:53 G
4d540673 65727665 72064170 61636865 MT.server.Apache 4d540673 65727665 72064170 61636865 MT.server.Apache
skipping to change at line 514 skipping to change at line 505
6e676573 05627974 65730e63 6f6e7465 nges.bytes.conte 6e676573 05627974 65730e63 6f6e7465 nges.bytes.conte
6e742d6c 656e6774 68023531 04766172 nt-length.51.var 6e742d6c 656e6774 68023531 04766172 nt-length.51.var
790f4163 63657074 2d456e63 6f64696e y.Accept-Encodin 790f4163 63657074 2d456e63 6f64696e y.Accept-Encodin
670c636f 6e74656e 742d7479 70650a74 g.content-type.t 670c636f 6e74656e 742d7479 70650a74 g.content-type.t
6578742f 706c6169 6e003348 656c6c6f ext/plain.3Hello 6578742f 706c6169 6e003348 656c6c6f ext/plain.3Hello
20576f72 6c642120 4d792063 6f6e7465 World! My conte 20576f72 6c642120 4d792063 6f6e7465 World! My conte
6e742069 6e636c75 64657320 61207472 nt includes a tr 6e742069 6e636c75 64657320 61207472 nt includes a tr
61696c69 6e672043 524c462e 0d0a0000 ailing CRLF..... 61696c69 6e672043 524c462e 0d0a0000 ailing CRLF.....
]]></artwork> ]]></artwork>
</figure> </figure>
<t>A response that uses the chunked encoding (see <xref section="7.1" se <t>A response that uses the chunked encoding (see <xref section="7.1" se
ctionFormat="of" target="MESSAGING"/>) as ctionFormat="of" target="RFC9112"/>) as
shown for <xref target="ex-chunked"/> can be encoded using indefinite-length enc shown in <xref target="ex-chunked"/> can be encoded using indeterminate-length e
oding, which ncoding, which
minimizes buffering needed to translate into the binary format. However, chunk minimizes buffering needed to translate into the binary format. However, chunk
boundaries do not need to be retained, and any chunk extensions cannot be boundaries do not need to be retained, and any chunk extensions cannot be
conveyed using the binary format; see <xref target="differences"/>.</t> conveyed using the binary format; see <xref target="differences"/>.</t>
<figure anchor="ex-chunked"> <figure anchor="ex-chunked">
<name>Chunked Encoding Example</name> <name>Chunked Encoding Example</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Transfer-Encoding: chunked Transfer-Encoding: chunked
4 4
skipping to change at line 534 skipping to change at line 525
4 4
This This
6 6
conte conte
13;chunk-extension=foo 13;chunk-extension=foo
nt contains CRLF. nt contains CRLF.
0 0
Trailer: text Trailer: text
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><xref target="ex-bink-chunked"/> shows this message using the known-l <t><xref target="ex-bink-chunked"/> shows this message using the known-l
ength coding. Note that ength encoding. Note that
the transfer-encoding header field is removed.</t> the Transfer-Encoding header field is removed.</t>
<figure anchor="ex-bink-chunked"> <figure anchor="ex-bink-chunked">
<name>Known-Length Encoding of Response</name> <name>Known-Length Encoding of Response</name>
<artwork type="hex-dump"><![CDATA[ <artwork type=""><![CDATA[
0140c800 1d546869 7320636f 6e74656e .@...This conten 0140c800 1d546869 7320636f 6e74656e .@...This conten
7420636f 6e746169 6e732043 524c462e t contains CRLF. 7420636f 6e746169 6e732043 524c462e t contains CRLF.
0d0a0d07 74726169 6c657204 74657874 ....trailer.text 0d0a0d07 74726169 6c657204 74657874 ....trailer.text
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="differences"> <section anchor="differences">
<name>Notable Differences with HTTP Protocol Messages</name> <name>Notable Differences with HTTP Protocol Messages</name>
<t>This format is designed to carry HTTP semantics just like HTTP/1.1, HTT <t>This format is designed to carry HTTP semantics just like HTTP/1.1 <xre
P/2, or f target="RFC9112"/>, HTTP/2 <xref target="RFC9113"/>, or
HTTP/3 (<xref target="MESSAGING"/>, <xref target="H2"/>, <xref target="H3"/>). HTTP/3 <xref target="RFC9114"/>. However, there are some notable
However, there are some notable
differences between this format and the format used in an interactive protocol differences between this format and the format used in an interactive protocol
version.</t> version.</t>
<t>In particular, as a standalone representation, this format lacks the fo llowing <t>In particular, as a standalone representation, this format lacks the fo llowing
features of the formats used in those protocols:</t> features of the formats used in those protocols:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>chunk extensions (<xref section="7.1.1" sectionFormat="of" target="M <li>chunk extensions (<xref section="7.1.1" sectionFormat="of" target="R
ESSAGING"/>) and transfer encoding FC9112"/>) and transfer encoding
(<xref section="6.1" sectionFormat="of" target="MESSAGING"/>) from HTTP/1.1</li> (<xref section="6.1" sectionFormat="of" target="RFC9112"/>)</li>
<li>generic framing and extensibility capabilities</li> <li>generic framing and extensibility capabilities</li>
<li>field blocks other than a single header and trailer field block</li> <li>field blocks other than a single header and trailer field block</li>
<li>carrying reason phrases in responses (<xref section="4" sectionForma <li>carrying reason phrases in responses (<xref section="4" sectionForma
t="of" target="MESSAGING"/>)</li> t="of" target="RFC9112"/>)</li>
<li>header compression (<xref target="HPACK"/>, <xref target="QPACK"/>)< <li>header compression <xref target="RFC7541"/> <xref target="RFC9204"/>
/li> </li>
<li>framing of responses that depends on the corresponding request (such <li>response framing that depends on the corresponding request (such as
as HEAD) HEAD)
or the value of the status code (such as 204 or 304); these responses use the or the value of the status code (such as 204 or 304); these responses use the
same framing as all other messages</li> same framing as all other messages</li>
</ul> </ul>
<t>Some of these features are also absent in HTTP/2 and HTTP/3.</t> <t>Some of these features are also absent in HTTP/2 and HTTP/3.</t>
<t>Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control d ata <t>Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control d ata
rather than using pseudo-fields.</t> rather than using pseudo-fields.</t>
<t>Note that while some messages - CONNECT or upgrade requests in particul <t>Note that while some messages -- CONNECT or upgrade requests in particu
ar - can lar -- can
be represented using this format, doing so serves no purpose as these requests be represented using this format, doing so serves no purpose, as these requests
are used to affect protocol behavior, which this format cannot do without are used to affect protocol behavior, which this format cannot do without
additional mechanisms.</t> additional mechanisms.</t>
</section> </section>
<section anchor="media-type"> <section anchor="media-type">
<name>"message/bhttp" Media Type</name> <name>"message/bhttp" Media Type</name>
<t>The <tt>message/bhttp</tt> media type can be used to enclose a single H TTP request or <t>The <tt>"message/bhttp"</tt> media type can be used to enclose a single HTTP request or
response message, provided that it obeys the MIME restrictions for all response message, provided that it obeys the MIME restrictions for all
"message" types regarding line length and encodings.</t> "message" types regarding line length and encodings.</t>
<dl> <dl spacing="compact" newline="false">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>message</t> <t>message</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>bhttp</t> <t>bhttp</t>
</dd> </dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>
<t>only "8bit" or "binary" is permitted</t> <t>Only "8bit" or "binary" is permitted.</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t>see <xref target="security"/></t> <t>See <xref target="security"/>.</t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t>this specification</t> <t>RFC 9292</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>Applications looking to convey HTTP request semantics independent o f a <t>Applications seeking to convey HTTP semantics that are independent of a
specific protocol.</t> specific protocol.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd>
<dl> <dl spacing="compact" newline="false">
<dt>Magic number(s):</dt>
<dd>N/A</dd>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Magic number(s):</dt>
<dd>N/A</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
</dl> </dl>
</dd> </dd>
<dt>Person and email address to contact for further information:</dt> <dt>Person &amp; email address to contact for further information:</dt>
<dd> <dd>
<t>see Authors' Addresses section</t> <t>See the Authors' Addresses section.</t>
</dd> </dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>
<t>COMMON</t> <t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Author:</dt> <dt>Author:</dt>
<dd> <dd>
<t>see Authors' Addresses section</t> <t>See the Authors' Addresses section.</t>
</dd> </dd>
<dt>Change controller:</dt> <dt>Change controller:</dt>
<dd> <dd>
<t>IESG</t> <t>IESG</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Many of the considerations that apply to HTTP message handling apply to this <t>Many of the considerations that apply to HTTP message handling apply to this
format; see <xref section="17" sectionFormat="of" target="HTTP"/> and <xref sect ion="11" sectionFormat="of" target="MESSAGING"/> for common format; see <xref section="17" sectionFormat="of" target="RFC9110"/> and <xref s ection="11" sectionFormat="of" target="RFC9112"/> for common
issues in handling HTTP messages.</t> issues in handling HTTP messages.</t>
<t>Strict parsing of the format with no tolerance for errors can help avoi d a <t>Strict parsing of the format with no tolerance for errors can help avoi d a
number of attacks. However, implementations still need to be aware of the number of attacks. However, implementations still need to be aware of the
possibility of resource exhaustion attacks that might arise from receiving possibility of resource exhaustion attacks that might arise from receiving
large messages, particularly those with large numbers of fields.</t> large messages, particularly those with large numbers of fields.</t>
<t>Implementations need to ensure that they aren't subject to resource exh austion <t>Implementations need to ensure that they aren't subject to resource exh austion
attack from a maliciously crafted message. Overall, the format is designed to attacks from maliciously crafted messages. Overall, the format is designed to
allow for minimal state when processing messages. However, producing a combined allow for minimal state when processing messages. However, producing a combined
field value (<xref section="5.2" sectionFormat="of" target="HTTP"/>) for fields might require the commitment of field value (<xref section="5.2" sectionFormat="of" target="RFC9110"/>) for fiel ds might require the commitment of
resources. In particular, combining might be necessary for the <tt>Cookie</tt> field resources. In particular, combining might be necessary for the <tt>Cookie</tt> field
when translating this format for use in other contexts, such as use in an API or when translating this format for use in other contexts, such as use in an API or
translation to HTTP/1.1 <xref target="MESSAGING"/>, where the recipient of the f ield might translation to HTTP/1.1 <xref target="RFC9112"/>, where the recipient of the fie ld might
not expect multiple values.</t> not expect multiple values.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to add the "Media Types" registry at <t>IANA has added the media type <tt>"message/bhttp"</tt> to the "Media Ty
<eref target="https://www.iana.org/assignments/media-types"/> with the registrat pes" registry at
ion <eref target="https://www.iana.org/assignments/media-types" brackets="angle"/>.
information in <xref target="media-type"/> for the media type "message/bhttp".</ See <xref target="media-type"/> for registration
t> information.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="H2" to="HTTP/2"/> <displayreference target="RFC9110" to="HTTP"/>
<displayreference target="MESSAGING" to="HTTP/1.1"/> <displayreference target="RFC9000" to="QUIC"/>
<displayreference target="H3" to="HTTP/3"/> <displayreference target="RFC9113" to="HTTP/2"/>
<displayreference target="RFC9112" to="HTTP/1.1"/>
<displayreference target="RFC7541" to="HPACK"/>
<displayreference target="RFC9114" to="HTTP/3"/>
<displayreference target="RFC9204" to="QPACK"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="Roy T. Fielding">
<organization>Adobe</organization>
</author>
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author>
<date day="12" month="September" year="2021"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, <!-- draft-ietf-httpbis-semantics (RFC 9110; published) -->
7538, 7615, 7694, and portions of 7230. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.
</t> xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
</front> xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-
19"/> <!-- draft-ietf-httpbis-http2bis (RFC 9113; published) -->
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9113.
<reference anchor="QUIC"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> xml"/>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
yengar"> xml"/>
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="H2">
<front>
<title>HTTP/2</title>
<author fullname="Martin Thomson">
<organization>Mozilla</organization>
</author>
<author fullname="Cory Benfield">
<organization>Apple Inc.</organization>
</author>
<date day="24" month="January" year="2022"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics 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 excha
nges on the same connection.
This document obsoletes RFCs 7540 and 8740.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-0
7"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. 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</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="MESSAGING">
<front>
<title>HTTP/1.1</title>
<author fullname="Roy T. Fielding">
<organization>Adobe</organization>
</author>
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author>
<date day="12" month="September" year="2021"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n management, and related security concerns.
This document obsoletes portions of RFC 7230. <!-- draft-ietf-httpbis-messaging (RFC 9112; published) -->
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9112.
</abstract> xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messaging- <!-- draft-ietf-quic-http (RFC 9114; published) -->
19"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9114.
</reference> xml"/>
<reference anchor="H3">
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2518.
<title>HTTP/3</title> xml"/>
<author fullname="Mike Bishop"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8297.
<organization>Akamai</organization> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7541.
<date day="2" month="February" year="2021"/> xml"/>
<abstract>
<t>The QUIC transport protocol has several features that are desir <!-- draft-ietf-quic-qpack (RFC 9204; published) -->
able in a transport for HTTP, such as stream multiplexing, per-stream flow contr <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9204.
ol, and low-latency connection establishment. This document describes a mapping xml"/>
of HTTP semantics over QUIC. This document also identifies HTTP/2 features tha
t are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP
/3.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
</reference>
<reference anchor="RFC2518">
<front>
<title>HTTP Extensions for Distributed Authoring -- WEBDAV</title>
<author fullname="Y. Goland" initials="Y." surname="Goland">
<organization/>
</author>
<author fullname="E. Whitehead" initials="E." surname="Whitehead">
<organization/>
</author>
<author fullname="A. Faizi" initials="A." surname="Faizi">
<organization/>
</author>
<author fullname="S. Carter" initials="S." surname="Carter">
<organization/>
</author>
<author fullname="D. Jensen" initials="D." surname="Jensen">
<organization/>
</author>
<date month="February" year="1999"/>
<abstract>
<t>This document specifies a set of methods, headers, and content-
types ancillary to HTTP/1.1 for the management of resource properties, creation
and management of resource collections, namespace manipulation, and resource loc
king (collision avoidance). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2518"/>
<seriesInfo name="DOI" value="10.17487/RFC2518"/>
</reference>
<reference anchor="RFC8297">
<front>
<title>An HTTP Status Code for Indicating Hints</title>
<author fullname="K. Oku" initials="K." surname="Oku">
<organization/>
</author>
<date month="December" year="2017"/>
<abstract>
<t>This memo introduces an informational HTTP status code that can
be used to convey hints that help a client make preparations for processing the
final response.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8297"/>
<seriesInfo name="DOI" value="10.17487/RFC8297"/>
</reference>
<reference anchor="HPACK">
<front>
<title>HPACK: Header Compression for HTTP/2</title>
<author fullname="R. Peon" initials="R." surname="Peon">
<organization/>
</author>
<author fullname="H. Ruellan" initials="H." surname="Ruellan">
<organization/>
</author>
<date month="May" year="2015"/>
<abstract>
<t>This specification defines HPACK, a compression format for effi
ciently representing HTTP header fields, to be used in HTTP/2.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7541"/>
<seriesInfo name="DOI" value="10.17487/RFC7541"/>
</reference>
<reference anchor="QPACK">
<front>
<title>QPACK: Field Compression for HTTP/3</title>
<author fullname="Charles 'Buck' Krasic">
<organization>Netflix</organization>
</author>
<author fullname="Mike Bishop">
<organization>Akamai Technologies</organization>
</author>
<author fullname="Alan Frindell">
<organization>Facebook</organization>
</author>
<date day="2" month="February" year="2021"/>
<abstract>
<t>This specification defines QPACK: a compression format for effi
ciently representing HTTP fields that is to be used in HTTP/3. This is a variat
ion of HPACK compression that seeks to reduce head-of-line blocking.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-qpack-21"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t><contact fullname="Julian Reschke"/>, <contact fullname="David Schinazi "/>, <contact fullname="Lucas Pardue"/> and <contact fullname="Tommy Pauly"/> pr ovided <t><contact fullname="Julian Reschke"/>, <contact fullname="David Schinazi "/>, <contact fullname="Lucas Pardue"/>, and <contact fullname="Tommy Pauly"/> p rovided
excellent feedback on both the design and its documentation.</t> excellent feedback on both the design and its documentation.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA81963IbOZLufzwFVj4Ra0+QJd5E2urLtEaW296xbK+t3ok5
G3vCRRYo1bjI4lQVJasdnmfZZzlPdvLLBFBAkdS4J+ZErDs6LFUVgEQiL18m
EnC/31dN3hTmVB/9IV+n1b1+bzaVqc26SZu8XOtyqV9eXb3Tl6au02tTH6l0
Pq/M7am230dvVVYu1umKusuqdNn0c9Ms+zdNs5nndX/ODfor+bY/mKpF2pjr
sro/1XWTqbQy6ak+e3+l7srq03VVbjen3L26NeutOVVahw+1bu43NNKf6ON8
fa1/xjt6elNifAxanx4f4++766Ssro/p3SrNi1PtqerfXf90N8ZLepdWi5u2
XZHXTZ3Iy+MzepXfmvr43XZe5IvjsAN0W5lN2Ta9zpub7TxZlCs7Ov/VN58b
s66Jp/Vxkc5NUR/HDKmVNOzndb01ff7mVHe/qbfzFX1A3Vzx7F9dXL1QtBpj
pdJtc1NWYFOf/tc6X9en+jLRV8SRulzzM1mcy7Rq8nX0gqZJz8tf86JI+YER
Xq2an4ryjsShKjf3ydo0cffnyVlCK1BmQe/nNxUxr9zcmEqHb3mI86LcZsuC
1jocZZHe/XRj0g2t4zwnvmMctS6rFQnhLa88lpxm23+eRDJVUwfrJl/U9Mm/
//Lq/FS/f3H+bDAYoMnolMf4YU87/D2iH/iDLK83RXovcnU8UipfL8OxLy8+
fDj7+dWbnw/3J+tD5O/pcJgMQc14t/Vft/mCu9jTihZU9ft9nc7rpkoXxI+r
m7zWpGDbFS2HzswyX5tap1ZEtJCMvyCPosPQC1ZQJz+J7XWVZ1lhlHqkX2Fp
s+0C2n54jDpfbQpzcIx0HQ2jHn/5gt+/fn3S04ak2uD7v25N3WhuWm9IDQxE
k4ZLC5KwmjulL7VZL8oMnVrToxzt9JbGXtBYc6MX5frW3JtMl9umzjPjSdhU
ZVMuysJ2btbpvOC2RhEf17VdWTFtIL8ynjs9EupFseXRQUq62ZC6+6+hYGgB
s5UporO63+BdAr4Z4ladX/OHDUa2vKKfRJyI1vk9d7us0hWGoIUlvm+JADtV
kj1wbkR8o/lkVhA0no3pWaL1+y0mA1YRA6Q9evIsqkxxr4laDFPhWyVrmBER
doienm8bocNS2NSmWIJQkkDqbtF8p2tj9JcvWb5cmoomauqvXxMrHbaVk42P
duzjOQT5Y68VyLRoTLVmLdJNySP6j/lbRXNoIGcw5Dog9MsXr3I0rj7riPjG
VCsiWq9KYp1ZLvNFTr0oLzhgHYkBUV1bOfLiv9NXWtQlcY0UgOZiPm/KGuvR
lKo2i22VN/foiSRoxbzFwmMuce9dDbu6K4m2zC5US1bFMrKo8rnJTpX6HbHq
07q8W/cLs75ubtovRQqpvX1BmrbMP9v+SF3Ij/2FfnLapkkYVqRRxIT6O8ye
+15TN5lpwCtaBLMziNMMz0B9bdam8tLuXY7Wd6TAxhJT8zzWZSO049267bRu
yLXUHVGBZLFuCPNEdVkevPnGgLdpkWcxM3Vai+m5V1hUTyoJOb2hxapzmgPp
xSseBVRFI6UbVi+wjNUSC9CQx6mV/TU0Nn7QZVWudL0xi5yGE4JuTcWuG7oY
yGZPi7r2VKuiZ0TydnHT61qB7brIP0E9iTAyYPU2b7AAsqatoREzR2q7MTRj
WgpaSPOZHADJ36KsHLGHiIeBf6TPweK1dAfGPYdu5fy72KpPtACEsrJaH13+
8uHqqCd/6zdv+ef3F+RM3188x88fXp69fu1/UPaLDy/f/vL6eftT2/L87eXl
xZvn0pie6uiROro8+zO9AVVHb99dvXr75uz1EZS+iVxPyloIRuVkIyrSAKhe
CntmNQht/nD+7v/+93BCq/Av5PdHw+Gzr1/tL0+Hswn9AvGU0co18V5+JeaR
QG02Jq3QC8SDRIXWoyAXAJG7gWRD6Imdv/tPcOa/TvX388VmOPnRPsCEo4eO
Z9FD5tnuk53GwsQ9j/YM47kZPe9wOqb37M/R747vwcOu69/WcJpsPMqivL4X
pWBdaJ0785WUTmwGfwEQBif2wTCi0MNkDPHEY6gHS+cL1gml2q+mzozSijnH
AgkXi1TsesrAQpC5Y/PHBN/QX+07Ep3SOzW9YdOkdezFRJpqChvupLni71gA
bb+ZdEQoCBiGvCGomN838Cf6jGRV3+TXN2Qfb03Rc/7Fm0/XEYFiwJUlWf5h
ol9YDEA2GopfVklEF7MfsGt9XYgKXBOGwmwswQ5E9Eik88VNOxFASZJyxlxg
oaUDFijdB8J4DTF5iixkfg3Nc2Fth8B0IYoU0AEDOziDglGCBeXOpcee/tVU
JcZgB+3BdLmmlXQfgXUXKREevcZgnjAgHERhDL3WnX7I0TTbmr7J7AxMmtGM
LeVE1jiBFSRsW+gsbdKWSOaAtc4AIGm+FmFzzFkR88qMeyVvdm2aBGR157jb
PiCJxp8k+mVMk5U83ybikqV/mZsigxE/EfJpNVw7XsBQAqP2Io5KTUmOKvJw
3zpuYz/2A88S/XZjmbxJM/gXQk1rcrirckuyYQfuk7feMqSVcc/IhnqAAKtA
ZqQi78mfiTaxu6Im29rh69u0yuEDHTaxct4iOTYpgTGZtrYETt+qhR0jKxkA
rI04/7kfUVlATCKbr7Yr0DanZk6JqQXAHCktm6dH+o8MbF4LTT61oc72qg8H
JTdp7cCcw2ypYOwmX/FitXCdiIF2qwCBi79h4CtP+iEuZC3729/+pjlclA/U
e0vKHUVXQnDfEvyFpNVZl1fOuujH+RP9gx706KVr6tTjOamHfpwkT/Ay6uoF
hEI77u/9xArpb2n/TqTK/v5V0VwsL3/bZIY7472KTITvFgPpJEnw/Ys8evU/
hgcPtAEP7AuauEwC71+Tmwzm1u3EUYXm7ue4m5jubvsDzER3B179Y8z8CtlW
X071oz2yrzk7+cNR1ItVyaOv0Mnoa6egkevw8XbeClDgwp70XDOOR53DwDf2
ed8+52/TjqsRoU3jUK2nLApwEe7ej+hBE9vqQ98RxnG2eM+cW38ZOKOU7I4Y
9Z70yhHD54Vh4y5BRsCudt45It1NkS4kYfEtvhyAL3oFbLgskdeRTiIaYw7L
i4DFNEPxtXtjYwbvMX8QJPFMA9xCHsixPicItuNpwtCJsQV7Eu9qrWPJhZcd
f6FycSfRmFpSMhixx24oziTZYaWJJFwwT14fbfuzcsW4IxaL2gm0yLN01rdZ
gYzTriwj3RfsGD1m48FsHse0+Y8o+ebQovhPclhrTnbRL0usf0o4wAafMpby
qQn2g/QbiY3ZZU8d8McRZCXaU3QADbRrtTKpDY8xQGUxbZGvcmbM6P9MR/2h
Ep/OmRfgy3iVmLnBPC1J1vG/ChMmvwkACL4SD0/sgsKV2ybI/cTggKhTTJ2j
S8KthxDBvmTO16+nu8ggmoQzmc7nP+hQR38XHezte7+H2/tp11P+hv52POaB
edpVeXCi44Nj/5MQxP94PoXg4MEPzm+260/R/N2bK9skBJd/bzjpjREJ/9Ti
EeA5278f8XB/uwBpLyT6x4j9JwGfb16zHQC0N29rgdDeXkNAdCDt+48ho/0I
4VuRkbOMnpiMjDN9xpCCfVOPPUrrX9flus/RpaV6AVlgWmM81bO9KNfLDpDa
HVvvGTvTAaw6yLl/AF8pHv//K74C9b8RV8HLPrwpwElSdkb7th4cpJoX5eIT
Rf2X26LJsS/YBR6bsrJef+kb2Y07u7eR9cQ9+yZYHeXWPzYPDgjYHJfDVN0w
3sIoJo6RnFFxN7VPQXC4fgBvEJ84MRVYlJyz8N+g0LL94VD8G5IR9TpAfkgX
flM/Zp35XqwJU4EJc51hPVuBdshsj82THOj1Nq9vwKhGcWIFH4NGHdLoEoq0
XICxVuiZXXaMQdI1nJaBPu9ql7qFj9xBTUCtSCt9l/LuTQjv/R7vPmz48Fjb
2rQK2SaOHJcIHvIOdq2icKI7XgCOAQR3gcOXR84sihrxSvMWMmQlzvkKLt21
rc4m7eZ1ZcfHpaIlmRhkvPnBbno2YQHYHYfYr5r0k9F/2dbYrN+6FBlvOp4F
Kxnkv4Pk8DICq0ncZthpYw3Qw41GhwaKrNH+tuODA+5vrN5y7tsmBRepE5A4
tMnXvN3o1t/+6gVgLwr+8qjr9kQWIuO7DNPMUZzhfUeQYHbfuUTzFYtIa+q7
RgtxJrlYk0WZYJHeU8IB6LinPyxuzMr01BlXBOXNfY9gIfFGMu4iULVzXxjC
W+Eo/+DjMuZkt5nE922lQVthoIP9n6fJOBnyrg2qGsQtYrfz3pcEnAo7Pvbo
x5oJ5x9TR/tHcdQfTzc0hY96U5ttVvYFaihLC6QCA96a4j7RL8s7c2uqnt23
llHa/uIurJlY5dc3jSLBKCmabOJ6CUENznSIYAbrQsvaUFdxXE0zPuT9d2O7
jlj18eWDWd9YLFGiJCIV5/fsQwdIRSo639iH7hsvMZ3P2udtnEFv44/40QFM
u2+KDtO+8CzbNz+gWlHJfWgbOtmBOg8ope0h0EoPhrs7OPrKP1C8yxRuap60
+5VPDuIKHeMKSQulO0mazCzylexxChCNpWiZh1DwoDCpQJhifhyWpociWQjV
B2HHOc9eMgSDQZKcPHu2d4H3DLu7wg+MaRf6USfKCqioabljHNxuHtjEkIWX
h3cLa/1YTH67mMkoWE4VblVx6nJj0sZhzv3rAPuU1nW5yBntxGGQ2q6bvAAg
eHgl7ZgW1oX7mxF6IxvV3BnT3Q8FCfEA9Y4oNTeHIoxvEKtO/LFHnL4lON4v
VkOI1XCvWMX07ojTN4wp2wS7us9pXxGWOAg9EIQJSnMZTreckcnAytWuNvHv
71mnykqKhCyEdJcPCJkvCnuw38cWZJLXkuBYO3khJvOoxGfpqyZ3+UTy6d3l
D3P3LqxXLrR+7LSDwYLAakSwcWTp90EXrmrJOnyLV5XHqxLKpmQdbxwvXNzY
7t5LYn6DKoRqbZUSNVVQLdR2RjPwaGvPKunHZMRAy0nEB4v7XrY5eLeN3saB
MD82UFDq5bdl66PwPohIHPB0VuhEeRNkYb2X8bSTw5bSsBrbHvsLPdShNfGw
7qLNjBcS4DrZ8psJLuJL9B9Km93wr0SwUBzSdWYOldZhicyV3w3gHgofjtP8
CpOCUWvDeftDUxci90Enft/H+wMuzgfxMD1htBslHfmFgzb/wdOLsY08OwBu
WiJ2LVQaCBBM0QsfmYIZpKeYt8PYAo9tfaWUubrw2ZY3B3zk0Eb93dDGS5jF
4VJlJYgo83WBeHUHA0dclkJMLHQQGHGLG3pY2G0z+yaordUws4t8w8WkqJFT
TWUwoZZAruB22ilzCad+V27picRsqQ8n2ukBoBNWsuXUkWkJQ45RG3IAkj0Q
611FqTzHV85eiI0R7q9coushDWYYoQL+7lS4+i4DAZAwMCjrXs1pScg+Cl+I
xktf6lb5xdWPg3kQBGXHce+zNTYswgBZEGGpgxGWja56sBn0EZvLj7SiEkvb
gMn26oTUl5bP733VvW5PuejLsz+HCb/vOt3YBFPwBW+sii3dQWlPgygycel+
ye3YSUMOohEUl2k6hy3eJVg/ltf9gplGHel0SSZU8d5n0En+oGC9CHglheO2
9HntnEQQT8ySaaicTwLebGuuZiLcgUMaEsya5ZIacm1w0KOvoeWE6+fGwxHL
b1tPOjeqMqvyFv4bpdvROYK0k8miPnwwzQJma6yshqq9hieWze+cHbMQuiXI
bj27McPOXOF2fPSDkfnnBRmha5dT9HLnJq3U6/yTcZaDpFnOUMTV2DeSSmmr
IZy2iva5Enjl1R4hfurcGucTzsvyU24+ulTsq/ADOz+3K6DOPpy/etV3qMkn
tj4ubB+2QnTOyiTVcaj0W+U0MRCyaEyjHw8+j+dPVJVah5/K6q9WadcQwf6N
nbJYXOOSyD40NlLK15bKdqsLJafO5RH3Lh+EE2Pba8J0e5OptgqO9+Mtv2Vv
Hj8gv0UhDjcXiMqVGZ2ieCxousAJm0LaplLBeOW2+9el7dOCyTr/1ZXX8fzE
U+5LDHqRFoa4bVJBepyn5q3ERy7zHNhd6xDwxqfIoohhtyCSEIXbyrAd2roE
qzn7XbYzeq32JPoX5pC1PFKajEVx2tITJUABI8kwTC7yCZkgiKYUX87Wx2Xy
0NzS5Ks3Aw7YyVq7Y4/GRLyOlfImvcVgLkZRbMA5BX+o/gOVm6JF3tgzTgqy
52a1QdIyb5R1Ii4rZ09QiS5x8T7vpHEHdkHjWhuSaMSNpcJaoJDVt0XP6FYG
a8uF1u12AnYq8g6pKZ8nqUvFzXadCPYc/b4HjJZ3G5syXzddt6Fit/HcMHE1
wyct8InPe8J4+m6dAa0xvZxa8yGqEmvBq4pwD0fzlN+YjHhS28+ZJUo5VWDX
sSIcgDM11nq1coGtDmaUl8EAeZIM/e+uDlAPRbF7gCPKpaIvt+EEeG/BEnmG
exVPDYPha+qQV3leu7Idsr2iPF5fkSQSlu4eaGx3Elr1pWV2HiZKD7SKmbhB
2sOI7gwIWwZRQKzMtuK1FtcCwouSj0eaqiordzKNVSpdK3noj0NG+ZrOoSl2
lkBK5LxxOLsIzqARdTiduXKHtmtXAw24nN6l7SaSnJgi/Wzu7YQdZZz/xlxg
ObmGiVEPnDcIkoB97+C8BhefU5BQW4bXHpLYuNLIe5cTr6Pd6zCVruekLLF7
waew6Byq+A1AUAXTFWzWWCKEjW5EdwS3NS+IHs1nl5EmrI6osvZ5kNYIqPi4
ol0ZGvM//Em1sOeaZ4fzpIJLg9IDVqbz969fID9DhuKutDoy+DxI+Wgb/ZA9
kUMKfOAtX2CNbB0jkgnEovteRKTfkLFThRNX7B1FZICHnHLxMUfe12cqgHc4
XDVrqH5tI2c+p+5OFf58caWPbwzJXdJ8btqjzL/UpuqfXRMFp3qxrYrjWTKc
EuAo8nn469uNWX/48Pp4kDxLZoX+lV5Tc0Im6mVZU9O7u7vEEo6j8upsAY3p
vyZwt6XhTzUOaq1y5WPtdslckP2hXWEnA0dO5a3+ms84pVy71Hxnn/YxHzzt
nGB94iCY2n84Mw3SEDc0A5e/d3JFY3xqhStRex62eoE1osUpaQ3gtGnVajmI
BLtf1j5tGxSzwrGviBSy5ZlbNxoh2642ajAYjCezyYk+mQxOpk9nEz2bzAaz
8WCgB+loOX06PdE6SWhpE76tIElohdV0Qf8tRwYfU5vJQE8Xg3R2Mhvr6cls
NMqmQ62tHPxUJFsIQKqms+nJ1NAQ48l0TB+PqNVoOZ5RP+PheDoy47HGAa5m
EoiFGg1orGdT+pjbTBda2oyHWtqMBlp3ZElNlrMBBtMn45PxhEbR4wF9+wxD
zWjUwSzVOwKnZCB8PKSPR/h4PJgQD5Z6Np5NBsvZjEcSsUxuiN3JnZrRn5Eh
Ps2eTofTbAZmTE/oCTFjOc0GSzAjlt2EmDGm/07o49mE2LWgb6ZmOpud4Afi
02AKxouEF1bCE2K8GRHx00xPcWUBJr7nD6tBkoR6EErT3gp5ezfHRVDl3FUQ
Zx+d8bPnVaCc0WEkd64WNUu5r+Zg6xjuqdrakbSW+ia2g5k9/1xvKwn+7BiO
cqmEEneYqXRBS079F/e7AU2whxwmbTrOugVIbG8JlLaRsgchNqJ4JcGyWqRy
mIuMNhKRrWXuk85V4qFciskpoWRHuxVnfa67kHIQzNHG2LYSmA/Du12kKCkU
wKg9c+t1jk3Z6Cb2he3B8WjnRiQlD4wRDifvuBBqtAu9+ay0P/6P/sT78fqu
zXWRX/PR664BGv0TDNAg1TA+sD0axgca5A2QNT/X0J7ZBLZHiyGBorMhGU+1
GBIyLjo2P7pQsAmwPVrajGda2rB5GA1garTuujIF6wPjo2F9YHw0rA+Mj4b1
ganRuuvwFKwPjI+G9YHx0bA+MD4a1gd/tI7tz92dgvWB8dGwPjA+GtYHxkfD
+sDUEA8j+7NYKFgfGB+YqyGMj4b1YdbB+sDUEIWR/Vn3YI4zGB89sH/2/KDZ
/gR/OqYo75qiV62Afrs9ekCqfV5uOGjTEv5sIss0qS1+t6dIXai9W4UWhXap
KEPs5oWtXJhKqkGjbzeKdH840lGvTr9tIV2gQ17j2fawVuKuCpOuHVoOahk8
ZH3f2Z+UgVw+l61XvtKPh58/P4l3s9M6tCBe8R22dvA20d3HXWxe7+x9qmig
6H6O3+O4/cnwKRLsvE+AB09Hz2Z+FybCkh4qDwcj/c7HDur9dg2unOqjujBm
o4cnRyr8eKwv0qq41y+JAbV6TW7vVH9/XDf3EPy6/vE75FZ/ILNelCnF02n9
A79rv6Rob9Mkf9n7Jb8LhsO+4Ns/quckK7gKifzuaKb/bVvgxTMSgNPR01Oy
AD9fXqkPpro11ak+25C5p+HIdfQvLSY71X9CdetoFLR9djo8OT2ZctuLqxQT
Hk/SdPx01s/6QzKUZj4YHDkM/B4JzvrUnjayqTurSqf6ZEjxB+7Msl87pfIf
ysVQQJbHm4KkB3uVZDxxUVaR/Yu+DHMdftvPp20QHyQd1O1OuuyD3fKON9lr
UQQ5lUOQluNgq05cWNzY+uPf6L2cyCb6TdkYbYu6LJjw93QwlN7WrZ5XJsXt
Vpubinx8C2OgUC6T5MouRDNjTzaekN0ckBkdkSE1BD7Jc5BZJec0GpFzWrAn
+2mZVCLDCUSYrTC5QAKzJyNaekDpGWFOuAdqPB+Nx2yFIejJT9cJcfzTo+/V
iH3C7FkLNen38diM5/AuI7Le1Kor9mpM7gEv0Qp+gZD4nOz5kGA7vZIOdVc5
4GtPQJFMZz6iVguMj0FH02dwIuRrDZP2v5wGwSeloIiHsIPK+BrUTRkVd/VM
TSdCEU0HFIVDgDeLp+QRdaiNyU/kXaYTmsOEhhhmk4x6NhooeTyCqx5MKC4B
N5DTTAIlVfzFYDyAY6YFGI/0OKUnT8cprQV7dvK1XVVWk4yAytQGOjOg9BkR
PBkC9sPTMl65vEpqVvjE6vuAIT61YrRPNGqi+dl0ilU+odbZCY2VAFD2faT2
J2CICWZCaIDwAM0EHppnpkE46CbZiE2Hopk8o4lAoOivE2AbmgnI1rSKJ8Qn
YnxoXxIScIrNhpMRCRtis+F0iB+eEjjKSEZGGXWJfjSJbGSE1JhmOx2BhQOi
D1FfFNbQ2tFYYqoAOWB8KhrLAGQQMwjwjWbPaG3x28AGTIZXUsOgJZJtZuPD
4A2REhiGSAnQaDAiwoY0L1qIIUkWgTdXsnAyTG7TSs2eDZaTIXoeC96h6UzQ
AY+FNTBa3yexZSRuDBYAUFqomRqZDvQDcSWFuhNww1rFPpICSQNVJixKqJJB
2JA1mMLr8eSpiDwJvdbeyCZjNrIkhiczgngIhmm1h7Skk2xGKxtxo2uKhRsD
MRJkWgidTrG4CIan1AeRytyIDbYCUc60kNhOxvpkNFlMAGUH2SAV8Baa9QPg
LTbv/h5I+7g9yLq/2KruFFixZfbnGfkED5lbb+Q7+7ozieyCO5WeoFhf/ADC
R3YEthdCGy6vEwVFh32KzX8pvvoh/5WImm8R1KAVkqQ2U4aL4XiPli964VMk
4S1hQUkxU6Lm5XadpVW+99YJ52J6tq7pXhqFW+N+f1f5e+zaWzGioQ9dxXYY
YlkYc8WX3VGo5PDBqVsLpSYMudVUWfEbjr/jd+0dlT8sy1Ktgy1xCwsGypZF
CcCIcIJbaitH5/ZXD/ot1oW4tDmxdmVdIiKA0i1PIoxuHbagAa7Kszs0MmEv
at00hsXsO55+yK5oQP7mBOkhsgoIHiODoeGZEn+PilkrVlj/jZgHtAu1UO8w
kPUyA6qYwJxOxeVDeTVGgsVBfJwkNruQMJe7qZ8Op6PUTxxjtehMPQK/uC75
eStLkilhKPfObaUH+yih1D18p1taubtg2+QGHz8p/HY8CWfP19SXlWpvN9x3
o5pub1QLSxAqrjvTdbniLU7MRwVU+mrHcLvfHfpu71ZyJVUcV6V8cMCXEih7
1xufPOI9p3yxLdKqJylk7PNnyNia9gpMNolxiUGRLj65E93YugFAX5oUVQ0+
6+MyKi1oxe1Vjg45rbNjOqKykeE+6ykViawL3g4qHTac7mnm7/fiJD+NzHdv
Ea5254v4Aj6hw+4gLdJNyj/m2Pj5nVU0ORxo9zxtnYI977TnhoOgDU8XcoTR
BLxrAe98tqTdLQpmMunOA53YYfjSLcN35aLJ71++Ozv/4w8Up85OJkORsN//
Oz+LL2T9K4G8T7YrN3ku3ooKzYMqTMmohclClxB5jJsAITcvL86eP1G4Azfe
iO+cOmgbwCLQx+PB5Ml3dpunJcAeaaL+pHbNrVAtNx0y5/39Y+pDuTLtZpEX
QreRbfdSg+M77dWjpAO2/mDnVSzu9r4yKQINbokNy3Kj2hUx7VG9Fg3mLTrc
dmHV3GdE+vr87Zs3F+dX4Mx2c13RMrc7inmorDYbOw+UNPCxnu4euW++trLU
jPC5wGSzrXDrm82s1O0QfDTAFUZIeqctQJob7L6XldtxC7lj3T1BBZscUm2y
iqaHiqa8Xtm7G4+i7agjMsdZnmoE9WSQV/iFEao95tLZvNL8gVyo2qnkIFNQ
8LScNrK1bm+0UN0S+R4md5szRrIVO+Xc3ItVu3x1eQGJbMhEyJ6zvZtUOfqP
mAp43etUqjR5xzHY1HXGiStQQDHfH63Uqb/ZVH3YzpvoDU9T8UEo3mGgJadX
ZMVrfv3m+Eyp4P6y3ZcXQVYRe25y4al8wEmKo6fzvDmCiB0JEjviE3KuGJdo
cjfD7ulBwJq7O/YrXzFA45fUPHVWc7cVE8Z3i9c3KKK2KQ3+gj9gYYoeE+Tu
3hlqzQLjJycE3Dr6skDRmd/PwDmFSA5a7w1QDRNn9wlwK7jPtfhLlpV6UaXX
XFuR40vEutXBKZ61Uh8kGvn991nxI43wfdb8eJle0xBSnvG4fnL6/TE9/D7L
fqQ+6OfMffccmm3rbIo8rW09rdTyoQwH8z/U+AXMi3erDw1zmS4QFdSonqE2
olpkqw+2OcZU1DuSOnvhDF9yjvw0vJHbSMKNrnxK2VaMdBkCSZJTd/W/6jNp
a3xlhcjVWkIgbJejCS7/fPuGc8mtWvLlMu4LWQV7T/w3DHLOtZbOigP2o9Wr
iw8/s6nymnAeLTjZKa8BSl0GlwbFgqHj06DhvZ5tpXlwWJRCljgo8ke4ZkFl
u+Sj/asu0nFV1iuaH9+0z57DD9e9y/kDcxKWxN32HCBJt83YlMQalH/KhicK
aiR/f2OKjU5vS5TTq7bgKG0awMMgrMw7BTx1g+KpIKgMy3hUWMYjyKTcVgvI
801KmJsvOpIhbCUBF/ekuIFUcB5qonPUiikpzGwvQG9dKOdrS3crn3wnUwiK
XAGS99ceyb5vm6i9B+BY/2uDg+x/gefk4sIdwpUQLmSmKPbPF3m5rYmaBf5J
CeMPHKA6/Ra3wxa9cE3iwERJ3dSSK5zW9pwlAn2ufQ6u8Q5OMfhFka1pKSp0
9bkqOLQQAtH4EGF7/0Btme9Kg2yVMfmSlRhW5ZhQ842WUcDhDwO05Vn+rkpf
sxyXIiuemEtodOAOt9lyTseiRFs2TQvvgKd9TcJ79u4VYIHvC0i3bKueOmFb
e9a6PQPitCU4YQ0cZD7jsHZ7qMKfdEAx39mbs445IRHDQ1tXQLbNArBMorqj
FiDVR0AbOVk/krZG/ed/PXb/JgeqjfJ0nfI/55HWkA/wvz5uAVX9pL3HxfYi
njY6jo/NrwCEtQc9AuDVQXCJ/JML8xQhziN9tkAyozAZu82aAnvRKpP9cLQk
QG4TJF/+bUtObY0YfnHziUbigOXLcwKZGU5tEzT5NXdPX28XtHTvCGdt8aW1
gV+uSNDu6fG2uMdTB+cUqhMLrqxckrKCMLiJuTvnZf8hA667a9rqSamcUP8P
NdU2qjRmAAA=
</rfc> </rfc>
 End of changes. 96 change blocks. 
639 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.48.