draft-ietf-httpbis-origin-h3-03.txt		draft-ietf-httpbis-origin-h3-latest.txt
	HTTPbis Working Group M. Bishop		Internet Engineering Task Force (IETF) M. Bishop
	Internet-Draft Akamai		Request for Comments: 9412 Akamai
	Intended status: Standards Track January 24, 2023		Category: Standards Track June 2023
	Expires: July 28, 2023		ISSN: 2070-1721
	The ORIGIN Extension in HTTP/3		The ORIGIN Extension in HTTP/3
	draft-ietf-httpbis-origin-h3-03
	Abstract		Abstract
	The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but		The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it
	needs to be separately registered. This document describes the		needs to be separately registered. This document describes the
	ORIGIN frame for HTTP/3.		ORIGIN frame for HTTP/3.
	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 July 28, 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/rfc9412.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2023 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 12 ¶		skipping to change at page 2, line 12 ¶
	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
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2
	2. The ORIGIN HTTP/3 Frame . . . . . . . . . . . . . . . . . . . 2		2. The ORIGIN HTTP/3 Frame . . . . . . . . . . . . . . . . . . . 2
	2.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 3
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 3		3. Security Considerations . . . . . . . . . . . . . . . . . . . 3
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. Normative References . . . . . . . . . . . . . . . . . . 4		5.1. Normative References . . . . . . . . . . . . . . . . . . 4
	5.2. Informative References . . . . . . . . . . . . . . . . . 4		5.2. Informative References . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	Existing RFCs define extensions to HTTP/2 [HTTP2] which remain useful		Existing RFCs define extensions to HTTP/2 [RFC9113] that remain
	in HTTP/3. Appendix A.2.3 of [HTTP3] describes the required updates		useful in HTTP/3. Appendix A.2 of [RFC9114] describes the required
	for HTTP/2 frames to be used with HTTP/3.		updates for HTTP/2 frames to be used with HTTP/3.
	[ORIGIN] defines the HTTP/2 ORIGIN frame, which indicates what		[ORIGIN] defines the HTTP/2 ORIGIN frame, which indicates what
	origins are available on a given connection. It defines a single		origins are available on a given connection. It defines a single
	HTTP/2 frame type.		HTTP/2 frame type.
	1.1. Notational Conventions		1.1. Notational Conventions
	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.
	Frame diagrams in this document use the format defined in Section 1.3		The frame diagram in this document uses the format defined in
	of [QUIC-TRANSPORT] to illustrate the order and size of fields.		Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of
			fields.
	2. The ORIGIN HTTP/3 Frame		2. The ORIGIN HTTP/3 Frame
	The ORIGIN HTTP/3 frame allows a server to indicate what origin(s)		The ORIGIN HTTP/3 frame allows a server to indicate what origin or
	([RFC6454]) the server would like the client to consider as members		origins [RFC6454] the server would like the client to consider as one
	of the Origin Set (Section 2.3 of [ORIGIN]) for the connection within		or more members of the Origin Set (Section 2.3 of [ORIGIN]) for the
	which it occurs.		connection within which it occurs.
	The semantics of the frame payload are identical to those of the		The semantics of the frame payload are identical to those of the
	HTTP/2 frame defined in [ORIGIN]. Where HTTP/2 reserves Stream 0 for		HTTP/2 frame defined in [ORIGIN]. Where HTTP/2 reserves stream 0 for
	frames related to the state of the connection, HTTP/3 defines a pair		frames related to the state of the connection, HTTP/3 defines a pair
	of unidirectional streams called "control streams" for this purpose.		of unidirectional streams called "control streams" for this purpose.
	Where [ORIGIN] indicates that the ORIGIN frame should be sent on
	Stream 0, this should be interpreted to mean the HTTP/3 control		Where [ORIGIN] indicates that the ORIGIN frame is sent on stream 0,
	stream. The ORIGIN frame is sent from servers to clients on the		this should be interpreted to mean the HTTP/3 control stream: that
	server's control stream.		is, the ORIGIN frame is sent from servers to clients on the server's
			control stream.
	HTTP/3 does not define a Flags field in the generic frame layout. As		HTTP/3 does not define a Flags field in the generic frame layout. As
	no flags have been defined for the ORIGIN frame, this specification		no flags have been defined for the ORIGIN frame, this specification
	does not define a mechanism for communicating such flags in HTTP/3.		does not define a mechanism for communicating such flags in HTTP/3.
	2.1. Frame Layout		2.1. Frame Layout
	The ORIGIN frame has a nearly identical layout to that used in		The ORIGIN frame has a layout that is nearly identical to the layout
	HTTP/2, restated here for clarity. The ORIGIN frame type is 0xc		used in HTTP/2; the information is restated here for clarity. The
	(decimal 12) as in HTTP/2. The payload contains zero or more		ORIGIN frame type is 0x0c (decimal 12), as in HTTP/2. The payload
	instances of the Origin-Entry field.		contains zero or more instances of the Origin-Entry field.
	HTTP/3 Origin-Entry {		HTTP/3 Origin-Entry {
	Origin-Len (16),		Origin-Len (16),
	ASCII-Origin (..),		ASCII-Origin (..),
	}		}
	HTTP/3 ORIGIN Frame {		HTTP/3 ORIGIN Frame {
	Type (i) = 0x0c,		Type (i) = 0x0c,
	Length (i),		Length (i),
	Origin-Entry (..) ...,		Origin-Entry (..) ...,
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 47 ¶
	Origin-Len: An unsigned, 16-bit integer indicating the length, in		Origin-Len: An unsigned, 16-bit integer indicating the length, in
	octets, of the ASCII-Origin field.		octets, of the ASCII-Origin field.
	ASCII-Origin: An OPTIONAL sequence of characters containing the		ASCII-Origin: An OPTIONAL sequence of characters containing the
	ASCII serialization of an origin ([RFC6454], Section 6.2) that the		ASCII serialization of an origin ([RFC6454], Section 6.2) that the
	sender asserts this connection is or could be authoritative for.		sender asserts this connection is or could be authoritative for.
	3. Security Considerations		3. Security Considerations
	This document introduces no new security considerations beyond those		This document introduces no new security considerations beyond those
	discussed in [ORIGIN] and [HTTP3].		discussed in [ORIGIN] and [RFC9114].
	4. IANA Considerations		4. IANA Considerations
	This document registers a frame type in the "HTTP/3 Frame Type"		This document registers a frame type in the "HTTP/3 Frame Types"
	registry ([HTTP3]).		registry defined by [RFC9114], located at
			<https://www.iana.org/assignments/http3-parameters/>.
	+------------+-------+---------------+		Value: 0x0c
	| Frame Type | Value | Specification |
	+------------+-------+---------------+
	| ORIGIN | 0xc | Section 2 |
	+------------+-------+---------------+
	Table 1: Registered HTTP/3 Frame Types		Frame Type: ORIGIN
	5. References		Status: permanent
	5.1. Normative References		Reference: Section 2
	[HTTP2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,		Date: 2023-03-14
	DOI 10.17487/RFC9113, June 2022,
	<https://www.rfc-editor.org/info/rfc9113>.
	[HTTP3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,		Change Controller: IETF
	June 2022, <https://www.rfc-editor.org/info/rfc9114>.
			Contact: HTTP WG <ietf-http-wg@w3.org>
			5. References
			5.1. Normative References
	[ORIGIN] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",		[ORIGIN] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
	RFC 8336, DOI 10.17487/RFC8336, March 2018,		RFC 8336, DOI 10.17487/RFC8336, March 2018,
	<https://www.rfc-editor.org/info/rfc8336>.		<https://www.rfc-editor.org/info/rfc8336>.
	[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>.
			[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
			DOI 10.17487/RFC9113, June 2022,
			<https://www.rfc-editor.org/info/rfc9113>.
			[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
			June 2022, <https://www.rfc-editor.org/info/rfc9114>.
	5.2. Informative References		5.2. Informative References
	[QUIC-TRANSPORT]		[QUIC-TRANSPORT]
	Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		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>.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	DOI 10.17487/RFC6454, December 2011,		DOI 10.17487/RFC6454, December 2011,
End of changes. 23 change blocks.
	54 lines changed or deleted		59 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/