draft-ietf-httpbis-binary-message-06.txt		draft-ietf-httpbis-binary-message-latest.txt
	HTTP Working Group M. Thomson		Internet Engineering Task Force (IETF) M. Thomson
	Internet-Draft Mozilla		Request for Comments: 9292 Mozilla
	Intended status: Standards Track C. Wood		Category: Standards Track C. Wood
	Expires: January 7, 2023 Cloudflare		ISSN: 2070-1721 Cloudflare
	July 06, 2022		August 2022
	Binary Representation of HTTP Messages		Binary Representation of HTTP Messages
	draft-ietf-httpbis-binary-message-06
	Abstract		Abstract
	This document defines a binary format for representing HTTP messages.		This document defines a binary format for representing HTTP messages.
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Status information for this document may be found at		Status information for this document may be found at
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 33 ¶
	Discussion of this document takes place on the HTTP Working Group		Discussion of this document takes place on the HTTP Working Group
	mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at		mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at
	<https://lists.w3.org/Archives/Public/ietf-http-wg/>. Working Group		<https://lists.w3.org/Archives/Public/ietf-http-wg/>. Working Group
	information can be found at <https://httpwg.org/>.		information can be found at <https://httpwg.org/>.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	<https://github.com/httpwg/http-extensions/labels/binary-messages>.		<https://github.com/httpwg/http-extensions/labels/binary-messages>.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on January 7, 2023.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9292.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 20 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Known Length Messages . . . . . . . . . . . . . . . . . . 4		3.1. Known-Length Messages . . . . . . . . . . . . . . . . . . 4
	3.2. Indeterminate Length Messages . . . . . . . . . . . . . . 6		3.2. Indeterminate-Length Messages . . . . . . . . . . . . . . 6
	3.3. Framing Indicator . . . . . . . . . . . . . . . . . . . . 8		3.3. Framing Indicator . . . . . . . . . . . . . . . . . . . . 8
	3.4. Request Control Data . . . . . . . . . . . . . . . . . . 8		3.4. Request Control Data . . . . . . . . . . . . . . . . . . 8
	3.5. Response Control Data . . . . . . . . . . . . . . . . . . 9		3.5. Response Control Data . . . . . . . . . . . . . . . . . . 9
	3.5.1. Informational Status Codes . . . . . . . . . . . . . 9		3.5.1. Informational Status Codes . . . . . . . . . . . . . 9
	3.6. Header and Trailer Field Lines . . . . . . . . . . . . . 10		3.6. Header and Trailer Field Lines . . . . . . . . . . . . . 10
	3.7. Content . . . . . . . . . . . . . . . . . . . . . . . . . 11		3.7. Content . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.8. Padding and Truncation . . . . . . . . . . . . . . . . . 11		3.8. Padding and Truncation . . . . . . . . . . . . . . . . . 11
	4. Invalid Messages . . . . . . . . . . . . . . . . . . . . . . 12		4. Invalid Messages . . . . . . . . . . . . . . . . . . . . . . 12
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Request Example . . . . . . . . . . . . . . . . . . . . . 12		5.1. Request Example . . . . . . . . . . . . . . . . . . . . . 12
	5.2. Response Example . . . . . . . . . . . . . . . . . . . . 13		5.2. Response Example . . . . . . . . . . . . . . . . . . . . 13
	6. Notable Differences with HTTP Protocol Messages . . . . . . . 16		6. Notable Differences with HTTP Protocol Messages . . . . . . . 16
	7. "message/bhttp" Media Type . . . . . . . . . . . . . . . . . 17		7. "message/bhttp" Media Type . . . . . . . . . . . . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10.1. Normative References . . . . . . . . . . . . . . . . . . 18		10.1. Normative References . . . . . . . . . . . . . . . . . . 18
	10.2. Informative References . . . . . . . . . . . . . . . . . 19		10.2. Informative References . . . . . . . . . . . . . . . . . 18
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	This document defines a simple format for representing an HTTP		This document defines a simple format for representing an HTTP
	message ([HTTP]), either request or response. This allows for the		message [HTTP], either request or response. This allows for the
	encoding of HTTP messages that can be conveyed outside an HTTP		encoding of HTTP messages that can be conveyed outside an HTTP
	protocol. This enables the transformation of entire messages,		protocol. This enables the transformation of entire messages,
	including the application of authenticated encryption.		including the application of authenticated encryption.
	The design of this format is informed by the framing structure of		The design of this format is informed by the framing structure of
	HTTP/2 ([H2]) and HTTP/3 ([H3]). Rules for constructing messages		HTTP/2 [H2] and HTTP/3 [H3]. Rules for constructing messages rely on
	rely on the rules defined in HTTP/2, but the format itself is		the rules defined in HTTP/2, but the format itself is distinct; see
	distinct; see Section 6.		Section 6.
	This format defines "message/bhttp", a binary alternative to the		This format defines ""message/bhttp"", a binary alternative to the
	"message/http" content type defined in [MESSAGING]. A binary format		""message/http"" content type defined in [MESSAGING]. A binary
	permits more efficient encoding and processing of messages. A binary		format permits more efficient encoding and processing of messages. A
	format also reduces exposure to security problems related to		binary format also reduces exposure to security problems related to
	processing of HTTP messages.		processing of HTTP messages.
	Two modes for encoding are described:		Two modes for encoding are described:
	o a known-length encoding includes length prefixes for all major		o a known-length encoding includes length prefixes for all major
	message components; and		message components, and
	o an indeterminate-length encoding enables efficient generation of		o an indeterminate-length encoding enables efficient generation of
	messages where lengths are not known when encoding starts.		messages where lengths are not known when encoding starts.
	This format is designed to convey the semantics of valid HTTP		This format is designed to convey the semantics of valid HTTP
	messages as simply and efficiently as possible. It is not designed		messages as simply and efficiently as possible. It is not designed
	to capture all of the details of the encoding of messages from		to capture all of the details of the encoding of messages from
	specific HTTP versions ([MESSAGING], [H2], [H3]). As such, this		specific HTTP versions [MESSAGING] [H2] [H3]. As such, this format
	format is unlikely to be suitable for applications that depend on an		is unlikely to be suitable for applications that depend on an exact
	exact recording of the encoding of messages.		recording of the encoding of messages.
	2. Conventions and Definitions		2. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This document uses terminology from HTTP ([HTTP]) and notation from		This document uses terminology from HTTP [HTTP] and notation from
	QUIC (Section 1.3 of [QUIC]).		QUIC (Section 1.3 of [QUIC]).
	3. Format		3. Format
	Section 6 of [HTTP] defines the general structure of HTTP messages		Section 6 of [HTTP] defines the general structure of HTTP messages
	and composes those messages into distinct parts. This format		and composes those messages into distinct parts. This format
	describes how those parts are composed into a sequence of bytes. At		describes how those parts are composed into a sequence of bytes. At
	a high level, binary messages are comprised of:		a high level, binary messages are comprised of:
	1. Framing indicator. This format uses a single integer to describe		1. Framing indicator. This format uses a single integer to describe
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 24 ¶
	5. Content. This is a sequence of zero or more bytes.		5. Content. This is a sequence of zero or more bytes.
	6. Trailer section. This contains zero or more trailer fields.		6. Trailer section. This contains zero or more trailer fields.
	7. Optional padding. Any amount of zero-valued bytes.		7. Optional padding. Any amount of zero-valued bytes.
	All lengths and numeric values are encoded using the variable-length		All lengths and numeric values are encoded using the variable-length
	integer encoding from Section 16 of [QUIC]. Integer values do not		integer encoding from Section 16 of [QUIC]. Integer values do not
	need to be encoded on the minimum number of bytes necessary.		need to be encoded on the minimum number of bytes necessary.
	3.1. Known Length Messages		3.1. Known-Length Messages
	A request or response that has a known length at the time of		A request or response that has a known length at the time of
	construction uses the format shown in Figure 1.		construction uses the format shown in Figure 1.
	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 page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	Fields in the header and trailer sections consist of a length-		Fields in the header and trailer sections consist of a length-
	prefixed name and length-prefixed value; see Section 3.6.		prefixed name and length-prefixed value; see Section 3.6.
	The format allows for the message to be truncated before any of the		The format allows for the message to be truncated before any of the
	length prefixes that precede the field sections or content; see		length prefixes that precede the field sections or content; see
	Section 3.8.		Section 3.8.
	The variable-length integer encoding means that there is a limit of		The variable-length integer encoding means that there is a limit of
	2^62-1 bytes for each field section and the message content.		2^62-1 bytes for each field section and the message content.
	3.2. Indeterminate Length Messages		3.2. Indeterminate-Length Messages
	A request or response that is constructed without encoding a known		A request or response that is constructed without encoding a known
	length for each section uses the format shown in Figure 2:		length for each section uses the format shown in Figure 2:
	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 (..),
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 22 ¶
	included, each prefixed by a non-zero Chunk Length integer describing		included, each prefixed by a non-zero Chunk Length integer describing
	the number of bytes in the block. The Chunk Length is encoded as a		the number of bytes in the block. The Chunk Length is encoded as a
	variable-length integer.		variable-length integer.
	Each Field Line in an Indeterminate-Length Field Section starts with		Each Field Line in an Indeterminate-Length Field Section starts with
	a Name Length field. An Indeterminate-Length Field Section ends with		a Name Length field. An Indeterminate-Length Field Section ends with
	a Content Terminator field. The zero value of the Content Terminator		a Content Terminator field. The zero value of the Content Terminator
	distinguishes it from the Name Length field, which cannot contain a		distinguishes it from the Name Length field, which cannot contain a
	value of 0.		value of 0.
	Indeterminate-length messages can be truncated in a similar way as		Indeterminate-length messages can be truncated in a way similar to
	known-length messages; see Section 3.8.		that for known-length messages; see Section 3.8.
	Indeterminate-length messages use the same encoding for field lines		Indeterminate-length messages use the same encoding for Field Line as
	as known-length messages; see Section 3.6.		known-length messages; see Section 3.6.
	3.3. Framing Indicator		3.3. Framing Indicator
	The start of each binary message is a framing indicator that is a		The start of each binary message is a framing indicator that is a
	single integer that describes the structure of the subsequent		single integer that describes the structure of the subsequent
	sections. The framing indicator can take just four values:		sections. The framing indicator can take just four values:
	o A value of 0 describes a request of known length.		o A value of 0 describes a request of known length.
	o A value of 1 describes a response of known length.		o A value of 1 describes a response of known length.
	skipping to change at page 8, line 52 ¶		skipping to change at page 8, line 52 ¶
	Other values cause the message to be invalid; see Section 4.		Other values cause the message to be invalid; see Section 4.
	3.4. Request Control Data		3.4. Request Control Data
	The control data for a request message contains the method and		The control data for a request message contains the method and
	request target. That information is encoded as an ordered sequence		request target. That information is encoded as an ordered sequence
	of fields: Method, Scheme, Authority, Path. Each of these fields is		of fields: Method, Scheme, Authority, Path. Each of these fields is
	prefixed with a length.		prefixed with a length.
	The values of these fields follow the rules in HTTP/2 (Section 8.3.1		The values of these fields follow the rules in HTTP/2 (Section 8.3.1
	of [H2]) that apply to the ":method", ":scheme", ":authority", and		of [H2]) that apply to the "":method"", "":scheme"", "":authority"",
	":path" pseudo-header fields respectively. However, where the		and "":path"" pseudo-header fields, respectively. However, where the
	":authority" pseudo-header field might be omitted in HTTP/2, a zero-		"":authority"" pseudo-header field might be omitted in HTTP/2, a
	length value is encoded instead.		zero-length value is encoded instead.
	The format of request control data is shown in Figure 3.		The format of request control data is shown in Figure 3.
	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 (..),
	}		}
	Figure 3: Format of Request Control Data		Figure 3: Format of Request Control Data
	3.5. Response Control Data		3.5. Response Control Data
	The control data for a response message consists of the status code.		The control data for a response message consists of the status code.
	The status code (Section 15 of [HTTP]) is encoded as a variable		The status code (Section 15 of [HTTP]) is encoded as a variable-
	length integer, not a length-prefixed decimal string.		length integer, not a length-prefixed decimal string.
	The format of final response control data is shown in Figure 4.		The format of final response control data is shown in Figure 4.
	Final Response Control Data {		Final Response Control Data {
	Status Code (i) = 200..599,		Status Code (i) = 200..599,
	}		}
	Figure 4: Format of Final Response Control Data		Figure 4: Format of Final Response Control Data
	3.5.1. Informational Status Codes		3.5.1. Informational Status Codes
	Responses that include informational status codes (see Section 15.2		Responses that include informational status codes (see Section 15.2
	of [HTTP]) are encoded by repeating the response control data and		of [HTTP]) are encoded by repeating the response control data and
	associated header section until a final response control data is		associated header section until a final status code is encoded; that
	encoded. The status code distinguishes between informational and		is, a Status Code field with a value from 200 to 599 (inclusive).
	final responses.		The status code distinguishes between informational and final
			responses.
	The format of the informational response control data is shown in		The format of the informational response control data is shown in
	Figure 5.		Figure 5.
	Informational Response Control Data {		Informational Response Control Data {
	Status Code (i) = 100..199,		Status Code (i) = 100..199,
	}		}
	Figure 5: Format of Informational Response Control Data		Figure 5: Format of Informational Response Control Data
	A response message can include any number of informational responses		A response message can include any number of informational responses
	that precede a final status code. These convey an informational		that precede a final status code. These convey an informational
	status code and a header block.		status code and a header block.
	If the response control data includes an informational status code		If the response control data includes an informational status code
	(that is, a value between 100 and 199 inclusive), the control data is		(that is, a value between 100 and 199 inclusive), the control data is
	followed by a header section (encoded with known- or indeterminate-		followed by a header section (encoded with known length or
	length according to the framing indicator) and another block of		indeterminate length according to the framing indicator) and another
	control data. This pattern repeats until the control data contains a		block of control data. This pattern repeats until the control data
	final status code (200 to 599 inclusive).		contains a final status code (200 to 599 inclusive).
	3.6. Header and Trailer Field Lines		3.6. Header and Trailer Field Lines
	Header and trailer sections consist of zero or more field lines; see		Header and trailer sections consist of zero or more field lines; see
	Section 5 of [HTTP]. The format of a field section depends on		Section 5 of [HTTP]. The format of a field section depends on
	whether the message is known- or indeterminate-length.		whether the message is of known length or indeterminate length.
	Each field line includes a name and a value. Both the name and value		Each Field Line encoding includes a name and a value. Both the name
	are length-prefixed sequences of bytes. The field name length is at		and value are length-prefixed sequences of bytes. The Name field is
	least one byte. The format of a field line is shown in Figure 6.		a minimum of one byte. The format of a Field Line is shown in
			Figure 6.
	Field Line {		Field Line {
	Name Length (i) = 1..,		Name Length (i) = 1..,
	Name (..),		Name (..),
	Value Length (i),		Value Length (i),
	Value (..),		Value (..),
	}		}
	Figure 6: Format of a Field Line		Figure 6: Format of a Field Line
	For field names, byte values that are not permitted in an HTTP field		For field names, byte values that are not permitted in an HTTP field
	name cause the message to be invalid; see Section 5.1 of [HTTP] for a		name cause the message to be invalid; see Section 5.1 of [HTTP] for a
	definition of what is valid and Section 4 for handling of invalid		definition of what is valid and Section 4 regarding the handling of
	messages. A recipient MUST treat a message that contains field		invalid messages. A recipient MUST treat a message that contains
	values that would cause an HTTP/2 message to be malformed according		field values that would cause an HTTP/2 message to be malformed
	to Section 8.2.1 of [H2] as invalid; see Section 4.		according to Section 8.2.1 of [H2] as invalid; see Section 4.
	The same field name can be repeated in multiple field lines; see		The same field name can be repeated over more than one field line;
	Section 5.2 of [HTTP] for the semantics of repeated field names and		see Section 5.2 of [HTTP] for the semantics of repeated field names
	rules for combining values.		and rules for combining values.
	Messages are invalid (Section 4) if they contain fields named		Messages are invalid (Section 4) if they contain fields named
	":method", ":scheme", ":authority", ":path", or ":status". Other		"":method"", "":scheme"", "":authority"", "":path"", or "":status"".
	pseudo-fields that are defined by protocol extensions MAY be		Other pseudo-fields that are defined by protocol extensions MAY be
	included; pseudo-fields cannot be included in trailers (see		included; pseudo-fields cannot be included in trailers (see
	Section 8.1 of [H2]). Field lines containing pseudo-fields MUST		Section 8.1 of [H2]). A Field Line containing pseudo-fields MUST
	precede other field lines. A message that contains a pseudo-field		precede other Field Line values. A message that contains a pseudo-
	after any other field is invalid; see Section 4.		field after any other field is invalid; see Section 4.
	Fields that relate to connections (Section 7.6.1 of [HTTP]) cannot be		Fields that relate to connections (Section 7.6.1 of [HTTP]) cannot be
	used to produce the effect on a connection in this context. These		used to produce the effect on a connection in this context. These
	fields SHOULD be removed when constructing a binary message.		fields SHOULD be removed when constructing a binary message.
	However, they do not cause a message to be invalid (Section 4);		However, they do not cause a message to be invalid (Section 4);
	permitting these fields allows a binary message to capture messages		permitting these fields allows a binary message to capture messages
	that are exchanged in a protocol context.		that are exchanged in a protocol context.
	Like HTTP/2 or HTTP/3, this format has an exception for the		Like HTTP/2 or HTTP/3, this format has an exception for the
	combination of multiple instances of the "Cookie" field. Instances		combination of multiple instances of the "Cookie" field. Instances
	of fields with the ASCII-encoded value of "cookie" are combined using		of fields with the ASCII-encoded value of ""cookie"" are combined
	a semicolon octet (0x3b) rather than a comma; see Section 8.2.3 of		using a semicolon octet (0x3b) rather than a comma; see Section 8.2.3
	[H2].		of [H2].
	3.7. Content		3.7. Content
	The content of messages is a sequence of bytes of any length. Though		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		a 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		it is unlikely to be a practical limitation. There is no limit to
	the size of content in an indeterminate length message.		the size of content in an indeterminate-length message.
	3.8. Padding and Truncation		3.8. Padding and Truncation
	Messages can be padded with any number of zero-valued bytes. Non-		Messages can be padded with any number of zero-valued bytes. Non-
	zero padding bytes cause a message to be invalid (see Section 4).		zero padding bytes cause a message to be invalid (see Section 4).
	Unlike other parts of a message, a processor MAY decide not to		Unlike other parts of a message, a processor MAY decide not to
	validate the value of padding bytes.		validate the value of padding bytes.
	Truncation can be used to reduce the size of messages that have no		Truncation can be used to reduce the size of messages that have no
	data in trailing field sections or content. If the trailers of a		data in trailing field sections or content. If the trailers of a
	message is empty, it MAY be omitted by the encoder in place of adding		message are empty, they MAY be omitted by the encoder in place of
	a length field equal to zero. An encoder MAY omit empty content in		adding a length field equal to zero. An encoder MAY omit empty
	the same way if the trailers are also empty. A message that is		content in the same way if the trailers are also empty. A message
	truncated at any other point is invalid; see Section 4.		that is truncated at any other point is invalid; see Section 4.
	Decoders MUST treat missing truncated fields as equivalent to having		Decoders MUST treat missing truncated fields as equivalent to having
	been sent with the length field sent to zero.		been sent with the length field set to zero.
	Padding is compatible with truncation of empty parts of the messages.		Padding is compatible with truncation of empty parts of the messages.
	Zero-valued bytes will be interpreted as zero-length part, which is		Zero-valued bytes will be interpreted as a zero-length part, which is
	semantically equivalent to the part being absent.		semantically equivalent to the part being absent.
	4. Invalid Messages		4. Invalid Messages
	This document describes a number of ways that a message can be		This document describes a number of ways that a message can be
	invalid. Invalid messages MUST NOT be processed further except to		invalid. Invalid messages MUST NOT be processed further except to
	log an error and produce an error response.		log an error and produce an error response.
	The format is designed to allow incremental processing.		The format is designed to allow incremental processing.
	Implementations need to be aware of the possibility that an error		Implementations need to be aware of the possibility that an error
	might be detected after performing incremental processing.		might be detected after performing incremental processing.
	5. Examples		5. Examples
	This section includes example requests and responses encoded in both		This section includes example requests and responses encoded in both
	known-length and indefinite-length forms.		known-length and indeterminate-length forms.
	5.1. Request Example		5.1. Request Example
	The example HTTP/1.1 message in Figure 7 shows the content in the		The example HTTP/1.1 message in Figure 7 shows the content in the
	"message/http" format.		""message/http"" format.
	Valid HTTP/1.1 messages require lines terminated with CRLF (the two		Valid HTTP/1.1 messages require lines terminated with CRLF (the two
	bytes 0x0a and 0x0d). For simplicity and consistency, the content of		bytes 0x0d and 0x0a). For simplicity and consistency, the content of
	these examples is limited to text, which also uses CRLF for line		these examples is limited to text, which also uses CRLF for line
	endings.		endings.
	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
	Figure 7: Sample HTTP Request		Figure 7: Sample HTTP Request
	This can be expressed as a binary message (type "message/bhttp")		This can be expressed as a binary message (type ""message/bhttp"")
	using a known-length encoding as shown in hexadecimal in Figure 8.		using a known-length encoding as shown in hexadecimal in Figure 8.
	Figure 8 includes text alongside to show that most of the content is		Figure 8 includes text alongside to show that most of the content is
	not modified.		not modified.
	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..
	Figure 8: Known-Length Binary Encoding of Request		Figure 8: Known-Length Binary Encoding of Request
	This example shows that the Host header field is not replicated in		This example shows that the Host header field is not replicated in
	the ":authority" field, as is required for ensuring that the request		the "":authority"" field, as is required for ensuring that the
	is reproduced accurately; see Section 8.3.1 of [H2].		request is reproduced accurately; see Section 8.3.1 of [H2].
	The same message can be truncated with no effect on interpretation.		The same message can be truncated with no effect on interpretation.
	In this case, the last two bytes - corresponding to content and a		In this case, the last two bytes -- corresponding to content and a
	trailer section - can each be removed without altering the semantics		trailer section -- can each be removed without altering the semantics
	of the message.		of the message.
	The same message, encoded using an indefinite-length encoding is		The same message, encoded using an indeterminate-length encoding, is
	shown in Figure 9. As the content of this message is empty, the		shown in Figure 9. As the content of this message is empty, the
	difference in formats is negligible.		difference in formats is negligible.
	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.............
	Figure 9: Indefinite-Length Binary Encoding of Request		Figure 9: Indeterminate-Length Binary Encoding of Request
	This indefinite-length encoding contains 10 bytes of padding. As two		This indeterminate-length encoding contains 10 bytes of padding. As
	additional bytes can be truncated in the same way as the known-length		two additional bytes can be truncated in the same way as the known-
	example, anything up to 12 bytes can be removed from this message		length example, anything up to 12 bytes can be removed from this
	without affecting its meaning.		message without affecting its meaning.
	5.2. Response Example		5.2. Response Example
	Response messages can contain interim (1xx) status codes as the		Response messages can contain interim (1xx) status codes, as the
	message in Figure 10 shows. Figure 10 includes examples of		message in Figure 10 shows. Figure 10 includes examples of
	informational status codes defined in [RFC2518] and [RFC8297].		informational status codes 102 and 103, as defined in [RFC2518] (now
			obsolete but defines status code 102) and [RFC8297], respectively.
	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
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Mon, 27 Jul 2009 12:28:53 GMT		Date: Mon, 27 Jul 2009 12:28:53 GMT
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 26 ¶
	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.
	Figure 10: Sample HTTP Response		Figure 10: Sample HTTP Response
	As this is a longer example, only the indefinite-length encoding is		As this is a longer example, only the indeterminate-length encoding
	shown in Figure 11. Note here that the specific text used in the		is shown in Figure 11. Note here that the specific text used in the
	reason phrase is not retained by this encoding.		reason phrase is not retained by this encoding.
	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
	skipping to change at page 15, line 29 ¶		skipping to change at page 15, line 29 ¶
	38656230 30220d61 63636570 742d7261 8eb00".accept-ra		38656230 30220d61 63636570 742d7261 8eb00".accept-ra
	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.....
	Figure 11: Binary Response including Informational Responses		Figure 11: Binary Response, including Informational Responses
	A response that uses the chunked encoding (see Section 7.1 of		A response that uses the chunked encoding (see Section 7.1 of
	[MESSAGING]) as shown for Figure 12 can be encoded using indefinite-		[MESSAGING]) as shown in Figure 12 can be encoded using
	length encoding, which minimizes buffering needed to translate into		indeterminate-length encoding, which minimizes buffering needed to
	the binary format. However, chunk boundaries do not need to be		translate into the binary format. However, chunk boundaries do not
	retained, and any chunk extensions cannot be conveyed using the		need to be retained, and any chunk extensions cannot be conveyed
	binary format; see Section 6.		using the binary format; see Section 6.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Transfer-Encoding: chunked		Transfer-Encoding: chunked
	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
	Figure 12: Chunked Encoding Example		Figure 12: Chunked Encoding Example
	Figure 13 shows this message using the known-length coding. Note		Figure 13 shows this message using the known-length encoding. Note
	that the transfer-encoding header field is removed.		that the Transfer-Encoding header field is removed.
	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
	Figure 13: Known-Length Encoding of Response		Figure 13: Known-Length Encoding of Response
	6. Notable Differences with HTTP Protocol Messages		6. Notable Differences with HTTP Protocol Messages
	This format is designed to carry HTTP semantics just like HTTP/1.1,		This format is designed to carry HTTP semantics just like HTTP/1.1
	HTTP/2, or HTTP/3 ([MESSAGING], [H2], [H3]). However, there are some		[MESSAGING], HTTP/2 [H2], or HTTP/3 [H3]. However, there are some
	notable differences between this format and the format used in an		notable differences between this format and the format used in an
	interactive protocol version.		interactive protocol version.
	In particular, as a standalone representation, this format lacks the		In particular, as a standalone representation, this format lacks the
	following features of the formats used in those protocols:		following features of the formats used in those protocols:
	o chunk extensions (Section 7.1.1 of [MESSAGING]) and transfer		o chunk extensions (Section 7.1.1 of [MESSAGING]) and transfer
	encoding (Section 6.1 of [MESSAGING]) from HTTP/1.1		encoding (Section 6.1 of [MESSAGING])
	o generic framing and extensibility capabilities		o generic framing and extensibility capabilities
	o field blocks other than a single header and trailer field block		o field blocks other than a single header and trailer field block
	o carrying reason phrases in responses (Section 4 of [MESSAGING])		o carrying reason phrases in responses (Section 4 of [MESSAGING])
	o header compression ([HPACK], [QPACK])		o header compression [HPACK] [QPACK]
	o framing of responses that depends on the corresponding request		o response framing that depends on the corresponding request (such
	(such as HEAD) or the value of the status code (such as 204 or		as HEAD) or the value of the status code (such as 204 or 304);
	304); these responses use the same framing as all other messages		these responses use the same framing as all other messages
	Some of these features are also absent in HTTP/2 and HTTP/3.		Some of these features are also absent in HTTP/2 and HTTP/3.
	Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control		Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control
	data rather than using pseudo-fields.		data rather than using pseudo-fields.
	Note that while some messages - CONNECT or upgrade requests in		Note that while some messages -- CONNECT or upgrade requests in
	particular - can be represented using this format, doing so serves no		particular -- can be represented using this format, doing so serves
	purpose as these requests are used to affect protocol behavior, which		no purpose, as these requests are used to affect protocol behavior,
	this format cannot do without additional mechanisms.		which this format cannot do without additional mechanisms.
	7. "message/bhttp" Media Type		7. "message/bhttp" Media Type
	The "message/bhttp" media type can be used to enclose a single HTTP		The ""message/bhttp"" media type can be used to enclose a single HTTP
	request or response message, provided that it obeys the MIME		request or response message, provided that it obeys the MIME
	restrictions for all "message" types regarding line length and		restrictions for all "message" types regarding line length and
	encodings.		encodings.
	Type name: message		Type name: message
	Subtype name: bhttp		Subtype name: bhttp
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: N/A		Optional parameters: N/A
			Encoding considerations: Only "8bit" or "binary" is permitted.
	Encoding considerations: only "8bit" or "binary" is permitted		Security considerations: See Section 8.
	Security considerations: see Section 8
	Interoperability considerations: N/A		Interoperability considerations: N/A
			Published specification: RFC 9292
	Published specification: this specification		Applications that use this media type: Applications seeking to
			convey HTTP semantics that are independent of a specific protocol.
	Applications that use this media type: Applications looking to
	convey HTTP request semantics independent of a specific protocol.
	Fragment identifier considerations: N/A		Fragment identifier considerations: N/A
	Additional information:		Additional information:
	Magic number(s): N/A
	Deprecated alias names for this type: N/A		Deprecated alias names for this type: N/A
			Magic number(s): N/A
	File extension(s): N/A		File extension(s): N/A
	Macintosh file type code(s): N/A		Macintosh file type code(s): N/A
			Person & email address to contact for further information: See the
	Person and email address to contact for further information: see Aut		Authors' Addresses section.
	hors' Addresses section
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: N/A		Restrictions on usage: N/A
			Author: See the Authors' Addresses section.
			Change controller: IESG
	Author: see Authors' Addresses section		<<<<<<< HEAD
	Change controller: IESG		======= >>>>>>> main
	8. Security Considerations		8. Security Considerations
	Many of the considerations that apply to HTTP message handling apply		Many of the considerations that apply to HTTP message handling apply
	to this format; see Section 17 of [HTTP] and Section 11 of		to this format; see Section 17 of [HTTP] and Section 11 of
	[MESSAGING] for common issues in handling HTTP messages.		[MESSAGING] for common issues in handling HTTP messages.
	Strict parsing of the format with no tolerance for errors can help		Strict parsing of the format with no tolerance for errors can help
	avoid a number of attacks. However, implementations still need to be		avoid a number of attacks. However, implementations still need to be
	aware of the possibility of resource exhaustion attacks that might		aware of the possibility of resource exhaustion attacks that might
	arise from receiving large messages, particularly those with large		arise from receiving large messages, particularly those with large
	numbers of fields.		numbers of fields.
	Implementations need to ensure that they aren't subject to resource		Implementations need to ensure that they aren't subject to resource
	exhaustion attack from a maliciously crafted message. Overall, the		exhaustion attacks from maliciously crafted messages. Overall, the
	format is designed to allow for minimal state when processing		format is designed to allow for minimal state when processing
	messages. However, producing a combined field value (Section 5.2 of		messages. However, producing a combined field value (Section 5.2 of
	[HTTP]) for fields might require the commitment of resources. In		[HTTP]) for fields might require the commitment of resources. In
	particular, combining might be necessary for the "Cookie" field when		particular, combining might be necessary for the "Cookie" field when
	translating this format for use in other contexts, such as use in an		translating this format for use in other contexts, such as use in an
	API or translation to HTTP/1.1 [MESSAGING], where the recipient of		API or translation to HTTP/1.1 [MESSAGING], where the recipient of
	the field might not expect multiple values.		the field might not expect multiple values.
	9. IANA Considerations		9. IANA Considerations
	IANA is requested to add the "Media Types" registry at		IANA has added the media type ""message/bhttp"" to the "Media Types"
	<https://www.iana.org/assignments/media-types> with the registration		registry at <https://www.iana.org/assignments/media-types>. See
	information in Section 7 for the media type "message/bhttp".		Section 7 for registration information.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[H2] Thomson, M. and C. Benfield, "HTTP/2", draft-ietf-httpbis-		[H2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
	http2bis-07 (work in progress), January 2022.		DOI 10.17487/RFC9113, June 2022,
			<https://www.rfc-editor.org/info/rfc9113>.
	[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Semantics", draft-ietf-httpbis-semantics-19 (work in		Ed., "HTTP Semantics", STD 97, RFC 9110,
	progress), September 2021.		DOI 10.17487/RFC9110, June 2022,
			<https://www.rfc-editor.org/info/rfc9110>.
	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9000>.		<https://www.rfc-editor.org/info/rfc9000>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	10.2. Informative References		10.2. Informative References
	[H3] Bishop, M., "HTTP/3", draft-ietf-quic-http-34 (work in		[H3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
	progress), February 2021.		June 2022, <https://www.rfc-editor.org/info/rfc9114>.
	[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for		[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
	HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,		HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
	<https://www.rfc-editor.org/info/rfc7541>.		<https://www.rfc-editor.org/info/rfc7541>.
	[MESSAGING]		[MESSAGING]
	Fielding, R. T., Nottingham, M., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	"HTTP/1.1", draft-ietf-httpbis-messaging-19 (work in		Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
	progress), September 2021.		June 2022, <https://www.rfc-editor.org/info/rfc9112>.
	[QPACK] Krasic, C. '., Bishop, M., and A. Frindell, "QPACK: Field		[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
	Compression for HTTP/3", draft-ietf-quic-qpack-21 (work in		Field Compression for HTTP/3", RFC 9204,
	progress), February 2021.		DOI 10.17487/RFC9204, June 2022,
			<https://www.rfc-editor.org/info/rfc9204>.
	[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.		[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
	Jensen, "HTTP Extensions for Distributed Authoring --		Jensen, "HTTP Extensions for Distributed Authoring --
	WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,		WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,
	<https://www.rfc-editor.org/info/rfc2518>.		<https://www.rfc-editor.org/info/rfc2518>.
	[RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints",		[RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints",
	RFC 8297, DOI 10.17487/RFC8297, December 2017,		RFC 8297, DOI 10.17487/RFC8297, December 2017,
	<https://www.rfc-editor.org/info/rfc8297>.		<https://www.rfc-editor.org/info/rfc8297>.
	Acknowledgments		Acknowledgments
	Julian Reschke, David Schinazi, Lucas Pardue and Tommy Pauly provided		Julian Reschke, David Schinazi, Lucas Pardue, and Tommy Pauly
	excellent feedback on both the design and its documentation.		provided excellent feedback on both the design and its documentation.
	Authors' Addresses		Authors' Addresses
	Martin Thomson		Martin Thomson
	Mozilla		Mozilla
	Email: mt@lowentropy.net		Email: mt@lowentropy.net
	Christopher A. Wood		Christopher A. Wood
	Cloudflare		Cloudflare
End of changes. 78 change blocks.
	164 lines changed or deleted		152 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/