< draft-pardue-quic-http-mcast-07.txt		draft-pardue-quic-http-mcast-08.txt >
	Network Working Group L. Pardue		Network Working Group L. Pardue
	Internet-Draft		Internet-Draft
	Intended status: Informational R. Bradbury		Intended status: Experimental R. Bradbury
	Expires: February 8, 2021 S. Hurst		Expires: August 22, 2021 S. Hurst
	BBC Research & Development		BBC Research & Development
	August 7, 2020		February 18, 2021
	Hypertext Transfer Protocol (HTTP) over multicast QUIC		Hypertext Transfer Protocol (HTTP) over multicast QUIC
	draft-pardue-quic-http-mcast-07		draft-pardue-quic-http-mcast-08
	Abstract		Abstract
	This document specifies a profile of the QUIC protocol and the HTTP/3		This document specifies a profile of the QUIC protocol and the HTTP/3
	mapping that facilitates the transfer of HTTP resources over		mapping that facilitates the transfer of HTTP resources over
	multicast IP using the QUIC transport as its framing and		multicast IP using the QUIC transport as its framing and
	packetisation layer. Compatibility with the QUIC protocol's syntax		packetisation layer. Compatibility with the QUIC protocol's syntax
	and semantics is maintained as far as practical and additional		and semantics is maintained as far as practical and additional
	features are specified where this is not possible.		features are specified where this is not possible.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 8, 2021.		This Internet-Draft will expire on August 22, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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
	skipping to change at page 2, line 51 ¶		skipping to change at page 2, line 51 ¶
	4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 20		4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 20
	4.7. Connection Shutdown . . . . . . . . . . . . . . . . . . . 20		4.7. Connection Shutdown . . . . . . . . . . . . . . . . . . . 20
	4.8. Connection Migration . . . . . . . . . . . . . . . . . . 20		4.8. Connection Migration . . . . . . . . . . . . . . . . . . 20
	4.9. Explicit Congestion Notification . . . . . . . . . . . . 21		4.9. Explicit Congestion Notification . . . . . . . . . . . . 21
	4.10. Session Keep-alive . . . . . . . . . . . . . . . . . . . 21		4.10. Session Keep-alive . . . . . . . . . . . . . . . . . . . 21
	4.11. Loss Detection and Recovery . . . . . . . . . . . . . . . 21		4.11. Loss Detection and Recovery . . . . . . . . . . . . . . . 21
	4.12. Prohibited QUIC Frames and Packets . . . . . . . . . . . 22		4.12. Prohibited QUIC Frames and Packets . . . . . . . . . . . 22
	5. HTTP/3 Profile . . . . . . . . . . . . . . . . . . . . . . . 22		5. HTTP/3 Profile . . . . . . . . . . . . . . . . . . . . . . . 22
	5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 23		5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 23
	5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23		5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23
	5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 23		5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 24
	5.4. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24		5.4. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24
	5.5. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24		5.5. Effects of Packet Loss . . . . . . . . . . . . . . . . . 24
	5.6. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24		5.6. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 25
	6. Application-Layer Security . . . . . . . . . . . . . . . . . 24		5.7. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 25
	6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 25		6. Application-Layer Security . . . . . . . . . . . . . . . . . 26
	6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 25		6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 26
	6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 27		6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 26
	7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 27		6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 28
	7.1. Forward Error Correction . . . . . . . . . . . . . . . . 27		7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 28
	7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 27		7.1. Forward Error Correction . . . . . . . . . . . . . . . . 28
	8. Transmission of Partial Content . . . . . . . . . . . . . . . 28		7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 28
	9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 28		8. Transmission of Partial Content . . . . . . . . . . . . . . . 29
	9.1. Draft Version Identification . . . . . . . . . . . . . . 28		9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 29
	10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 29		9.1. Draft Version Identification . . . . . . . . . . . . . . 29
	10.1. Source-specific Multicast Advertisement . . . . . . . . 30		10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 30
	10.2. Session Parameter Advertisement . . . . . . . . . . . . 30		10.1. Source-specific Multicast Advertisement . . . . . . . . 31
	10.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30		10.2. Session Parameter Advertisement . . . . . . . . . . . . 31
	10.2.2. Session Key . . . . . . . . . . . . . . . . . . . . 31		10.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 31
	10.2.3. Session Cipher Initialization Vector . . . . . . . . 31		10.2.2. Session Key . . . . . . . . . . . . . . . . . . . . 32
	10.2.4. Session Identification . . . . . . . . . . . . . . . 31		10.2.3. Session Cipher Initialization Vector . . . . . . . . 32
	10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 32		10.2.4. Session Identification . . . . . . . . . . . . . . . 32
	10.2.6. Resource Concurrency . . . . . . . . . . . . . . . . 32		10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 33
	10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 32		10.2.6. Resource Concurrency . . . . . . . . . . . . . . . . 33
	10.2.8. Digest Algorithm . . . . . . . . . . . . . . . . . . 33		10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 33
	10.2.9. Signature Algorithm . . . . . . . . . . . . . . . . 33		10.2.8. Digest Algorithm . . . . . . . . . . . . . . . . . . 34
	10.2.10. Extensions . . . . . . . . . . . . . . . . . . . . . 34		10.2.9. Signature Algorithm . . . . . . . . . . . . . . . . 34
	11. Security and Privacy Considerations . . . . . . . . . . . . . 34		10.2.10. Extensions . . . . . . . . . . . . . . . . . . . . . 35
	11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 34		11. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	11.1.1. Large-scale Data Gathering and Correlation . . . . . 35		11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 35
	11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 35		11.1.1. Large-scale Data Gathering and Correlation . . . . . 36
	11.2. Protection of Discovery Mechanism . . . . . . . . . . . 35		11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 36
	11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 36		11.2. Protection of Discovery Mechanism . . . . . . . . . . . 36
	11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 36		11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 37
	11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 36		11.3.1. Sender Spoofing . . . . . . . . . . . . . . . . . . 37
	11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 36		11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 37
	11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 36
	11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 37		11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 37
	11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 37		11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 38
	11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 37		11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 38
	11.6.2. Network Performance Degradation . . . . . . . . . . 37		11.6.2. Network Performance Degradation . . . . . . . . . . 38
	11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 38		11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 38
	11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 38		11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 38
	11.8. Unicast Repair Information Leakage . . . . . . . . . . . 38		11.8. Unicast Repair Information Leakage . . . . . . . . . . . 39
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	12.1. Registration of Protocol Identification String . . . . . 39		12.1. Registration of Protocol Identification String . . . . . 39
	12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 39		12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 40
	12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 39		12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 40
	12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 39		12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 40
	12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 39		12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 40
	12.2.4. Initialization Vector . . . . . . . . . . . . . . . 40		12.2.4. Initialization Vector . . . . . . . . . . . . . . . 40
	12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 40		12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 40
	12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 40		12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 40
	12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 40		12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 41
	12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 40		12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 41
	12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 40		12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 41
	12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 40		12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 41
	12.2.11. Extension . . . . . . . . . . . . . . . . . . . . . 40		12.2.11. Extension . . . . . . . . . . . . . . . . . . . . . 41
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
	13.1. Normative References . . . . . . . . . . . . . . . . . . 41		13.1. Normative References . . . . . . . . . . . . . . . . . . 41
	13.2. Informative References . . . . . . . . . . . . . . . . . 42		13.2. Informative References . . . . . . . . . . . . . . . . . 43
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 44		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 45
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 44		Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 45
	B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 44		B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 45
	B.1.1. Source-specific Multicast QUIC Session . . . . . . . 45		B.1.1. Source-specific Multicast QUIC Session . . . . . . . 45
	B.1.2. Source-specific Multicast QUIC Session with Transport		B.1.2. Source-specific Multicast QUIC Session with Transport
	Encryption using a Symmetric Key . . . . . . . . . . 45		Encryption using a Symmetric Key . . . . . . . . . . 46
	B.1.3. Source-specific Multicast QUIC Session with Transport		B.1.3. Source-specific Multicast QUIC Session with Transport
	Encryption, Content Integrity and Authenticity . . . 45		Encryption, Content Integrity and Authenticity . . . 46
	B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 46		B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 47
	B.2.1. Transfer without Content Integrity or Authenticity . 46		B.2.1. Transfer without Content Integrity or Authenticity . 47
	B.2.2. Transfer of Partial Content without Content Integrity		B.2.2. Transfer of Partial Content without Content Integrity
	or Authenticity . . . . . . . . . . . . . . . . . . . 46		or Authenticity . . . . . . . . . . . . . . . . . . . 47
	B.2.3. Transfer with Content Integrity and without		B.2.3. Transfer with Content Integrity and without
	Authenticity . . . . . . . . . . . . . . . . . . . . 47		Authenticity . . . . . . . . . . . . . . . . . . . . 48
	B.2.4. Partial Transfer with Content Integrity and without		B.2.4. Partial Transfer with Content Integrity and without
	Authenticity . . . . . . . . . . . . . . . . . . . . 48		Authenticity . . . . . . . . . . . . . . . . . . . . 48
	B.2.5. Transfer with Content Integrity and Authenticity . . 48		B.2.5. Transfer with Content Integrity and Authenticity . . 49
	B.2.6. Partial Transfer with Content Integrity and		B.2.6. Partial Transfer with Content Integrity and
	Authenticity . . . . . . . . . . . . . . . . . . . . 49		Authenticity . . . . . . . . . . . . . . . . . . . . 50
	Appendix C. Summary of differences from unicast QUIC and HTTP/3 50		Appendix C. Summary of differences from unicast QUIC and HTTP/3 51
	Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 61		Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 62
	D.1. Since draft-pardue-quic-http-mcast-06 . . . . . . . . . . 61		D.1. Since draft-pardue-quic-http-mcast-07 . . . . . . . . . . 62
	D.2. Since draft-pardue-quic-http-mcast-05 . . . . . . . . . . 62		D.2. Since draft-pardue-quic-http-mcast-06 . . . . . . . . . . 63
	D.3. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 63		D.3. Since draft-pardue-quic-http-mcast-05 . . . . . . . . . . 63
	D.4. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 63		D.4. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 64
	D.5. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 64		D.5. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 64
	D.6. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 64		D.6. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 65
	D.7. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 64		D.7. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 65
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65		D.8. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 66
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
	1. Introduction		1. Introduction
	The means to bulk transfer resources over multicast IP [RFC1112]		The means to bulk transfer resources over multicast IP [RFC1112]
	using HTTP semantics presents an opportunity to more efficiently		using HTTP semantics presents an opportunity to more efficiently
	deliver services at scale, while leveraging the wealth of existing		deliver services at scale, while leveraging the wealth of existing
	HTTP-related standards, tools and applications. Audio-visual		HTTP-related standards, tools and applications. Audio-visual
	segmented media, in particular, would benefit from this mode of		segmented media, in particular, would benefit from this mode of
	transmission.		transmission.
	skipping to change at page 16, line 11 ¶		skipping to change at page 16, line 11 ¶
	to show willingness to receive one or more extension frame types. It		to show willingness to receive one or more extension frame types. It
	is not possible for multicast QUIC receivers to signal this		is not possible for multicast QUIC receivers to signal this
	information to senders.		information to senders.
	This document defines an "extensions" session parameter, which is		This document defines an "extensions" session parameter, which is
	advertised as the Alt-Svc parameter "extensions" Section 10.2.10 and		advertised as the Alt-Svc parameter "extensions" Section 10.2.10 and
	replaces the transport parameter exchange detailed above. The Alt-		replaces the transport parameter exchange detailed above. The Alt-
	Svc "extensions" parameter is optional. Session advertisements MAY		Svc "extensions" parameter is optional. Session advertisements MAY
	contain zero or more instances of this parameter. The parameter		contain zero or more instances of this parameter. The parameter
	lists transport parameter values present in the QUIC Transport		lists transport parameter values present in the QUIC Transport
	Parameter Registry as specified in Section 22.2 of [QUIC-TRANSPORT].		Parameter Registry as specified in Section 22.3 of [QUIC-TRANSPORT].
	Only transport parameters which expressly reference Multicast QUIC		Only transport parameters which expressly reference Multicast QUIC
	are considered valid extension parameters.		are considered valid extension parameters.
	*Authors' Note:* The authors welcome suggestions for how to map		*Authors' Note:* The authors welcome suggestions for how to map
	these extension types more cleanly into this document.		these extension types more cleanly into this document.
	Participants SHOULD NOT join sessions advertising extensions that		Participants SHOULD NOT join sessions advertising extensions that
	they do not support, as QUIC frames are not self-describing.		they do not support, as QUIC frames are not self-describing.
	skipping to change at page 18, line 18 ¶		skipping to change at page 18, line 18 ¶
	This section is based on our best understanding of draft-ietf-		This section is based on our best understanding of draft-ietf-
	quic-transport-29. The authors will track developments and will		quic-transport-29. The authors will track developments and will
	update this section accordingly.		update this section accordingly.
	The profile of [QUIC-TRANSPORT] is presented in this section. In		The profile of [QUIC-TRANSPORT] is presented in this section. In
	order to preserve compatibility with conventional QUIC, the		order to preserve compatibility with conventional QUIC, the
	specification works with a limited scope of change. However, the		specification works with a limited scope of change. However, the
	nature of unidirectional multicast communications means that some		nature of unidirectional multicast communications means that some
	protocol procedures or behaviours need to be modified.		protocol procedures or behaviours need to be modified.
	Section 5.4 of [QUIC-TRANSPORT] defines a set of required actions		Section 5.3 of [QUIC-TRANSPORT] defines a set of required actions
	that a QUIC server and QUIC client must be able to perform. Due to		that a QUIC server and QUIC client must be able to perform. Due to
	the limitations of this profile, all of the requirements in		the limitations of this profile, all of the requirements in
	Section 5.4 of [QUIC-TRANSPORT] are removed except for:		Section 5.3 of [QUIC-TRANSPORT] are removed except for:
	o Configuring the minimum and total number of permitted streams of		o Configuring the minimum and total number of permitted streams of
	each type is described in Section 3.5.		each type is described in Section 3.5.
	o Multicast QUIC senders may still send "PING" frames to stop a		o Multicast QUIC senders may still send "PING" frames to stop a
	session from expiring as described in Section 4.10.		session from expiring as described in Section 4.10.
	4.1. Packet Size		4.1. Packet Size
	The means for determining an appropriate size for QUIC packets are		The means for determining an appropriate size for QUIC packets are
	skipping to change at page 23, line 9 ¶		skipping to change at page 23, line 9 ¶
	comply with the requirements of the session parameters, as described		comply with the requirements of the session parameters, as described
	earlier in Section 3.		earlier in Section 3.
	The profile of HTTP/3 specified in this section places additional		The profile of HTTP/3 specified in this section places additional
	constraints on the use of metadata compression (Section 5.3).		constraints on the use of metadata compression (Section 5.3).
	5.1. HTTP Connection Settings		5.1. HTTP Connection Settings
	The HTTP/3 "SETTINGS" frame is prohibited by this profile.		The HTTP/3 "SETTINGS" frame is prohibited by this profile.
	Participants MUST NOT make any attempt to send this frame type.		Participants MUST NOT make any attempt to send this frame type.
	Reception of this frame MUST be handled as described in Section 5.6.		Reception of this frame MUST be handled as described in Section 5.7.
	5.2. Server Push		5.2. Server Push
	Server push is, by default, disabled for HTTP/3 connections. A		Server push is, by default, disabled for HTTP/3 connections. A
	conventional HTTP/3 client enables and manages server push by		conventional HTTP/3 client enables and manages server push by
	controlling the maximum Push ID ([QUIC-HTTP], Section 7.2.7),		controlling the maximum Push ID ([QUIC-HTTP], Section 7.2.7),
	achieved by sending the HTTP/3 "MAX_PUSH_ID" frame.		achieved by sending the HTTP/3 "MAX_PUSH_ID" frame.
	This profile mandates the use of server push, and specifies no means		This profile mandates the use of server push, and specifies no means
	to disable it. The maximum Push ID for multicast QUIC sessions		to disable it. The maximum Push ID for multicast QUIC sessions
	(initial and always) is 2^62. Values of Push ID SHALL be allocated		(initial and always) is 2^62. Values of Push ID SHALL be allocated
	in accordance with [QUIC-HTTP].		in accordance with [QUIC-HTTP].
	Server push concurrency in multicast QUIC is described in		Server push concurrency in multicast QUIC is described in
	Section 3.5. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and		Section 3.5. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and
	it is prohibited. Participants MUST NOT send this frame type.		it is prohibited. Participants MUST NOT send this frame type.
	Reception of this frame type MUST be handled as described in		Reception of this frame type MUST be handled as described in
	Section 5.6.		Section 5.7.
	For this profile, the Stream Type for any new server-initiated		For this profile, the Stream Type for any new server-initiated
	unidirectional stream MUST be Server Push ("0x01").		unidirectional stream MUST be Server Push ("0x01").
	The HTTP/3 "CANCEL_PUSH" frame MAY be used by sending participants to		The HTTP/3 "CANCEL_PUSH" frame MAY be used by sending participants to
	abort sending a response for the identified server push. Usage of		abort sending a response for the identified server push. Usage of
	this frame SHALL follow the guidance for servers in [QUIC-HTTP].		this frame SHALL follow the guidance for servers in [QUIC-HTTP].
	Receiving participants MUST NOT make any attempt to send HTTP/3		Receiving participants MUST NOT make any attempt to send HTTP/3
	"CANCEL_PUSH" frames to the multicast group.		"CANCEL_PUSH" frames to the multicast group.
			Receiving participants SHOULD ignore all frames on server-initiated
			unidirectional streams for which the packet containing the Push ID
			has not been received. Receiving participants SHOULD ignore all
			frames on server-initiated unidirectional streams carrying a Push ID
			that was not previously promised to the receiver.
	Conventionally, pushed responses are associated with an explicit		Conventionally, pushed responses are associated with an explicit
	request from a client. This is not possible when using a		request from a client. This is not possible when using a
	unidirectional transport such as multicast IP. This profile reserves		unidirectional transport such as multicast IP. This profile reserves
	the first client-initiated, bidirectional QUIC stream. HTTP/3		the first client-initiated, bidirectional QUIC stream. HTTP/3
	"PUSH_PROMISE" frames MUST be sent on this reserved Stream ID.		"PUSH_PROMISE" frames MUST be sent on this reserved Stream ID.
	5.3. Metadata Compression		5.3. Metadata Compression
	The compression of HTTP header fields is considered in QPACK		The compression of HTTP header fields is considered in QPACK
	[QUIC-QPACK], which describes two methods for the compression of HTTP		[QUIC-QPACK], which describes two methods for the compression of HTTP
	skipping to change at page 24, line 25 ¶		skipping to change at page 24, line 32 ¶
	A multicast QUIC session MAY be explicitly torn down by means of the		A multicast QUIC session MAY be explicitly torn down by means of the
	"Connection: close" HTTP header described in section 6.6 of		"Connection: close" HTTP header described in section 6.6 of
	[RFC7230]. A sender intending to leave the session SHOULD include		[RFC7230]. A sender intending to leave the session SHOULD include
	the "Connection: close" header in its response metadata. A sender		the "Connection: close" header in its response metadata. A sender
	SHOULD transmit all outstanding frames related to remaining request/		SHOULD transmit all outstanding frames related to remaining request/
	response exchanges before ending transmission to the multicast group.		response exchanges before ending transmission to the multicast group.
	A receiver SHOULD continue to receive and process frames until all		A receiver SHOULD continue to receive and process frames until all
	outstanding request/response exchanges are complete.		outstanding request/response exchanges are complete.
	The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send		The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send
	this and reception MUST be handled as described in Section 5.6.		this and reception MUST be handled as described in Section 5.7.
	5.5. HTTP/3 Extension frames		5.5. Effects of Packet Loss
	HTTP/3 extension frames (e.g. "ALTSVC") are prohibited by this		Since multicast QUIC is an inherently unreliable delivery mechanism,
	profile. Participants MUST NOT make any attempt to send extension		portions of HTTP messages sent by the sender may not be received by
	frame types. Reception of these MUST be handled as described in		the receiver. Conventional HTTP/3 frames assume reliable, in-order
	Section 5.6.		delivery by the underlying QUIC stream. HTTP/3 frames do not
			therefore carry any information indicating their position within the
			stream, because this information is instead carried in the QUIC
			"STREAM" frame header.
	5.6. Prohibited HTTP/3 Frames		In multicast QUIC, packet loss leaves gaps in the flow of a stream,
			and therefore gaps in the HTTP/3 frame(s) that are carried on that
			stream.
			1. Loss of an HTTP/3 "PUSH_PROMISE" frame renders the reception of
			an entire stream impossible, since the receiver ignores the new
			push stream that has not been promised as described in
			Section 5.2.
			2. Loss of a QUIC packet comprising all or part of an HTTP/3
			"HEADERS" frame will likely prevent the QPACK decoder from
			successfully parsing the received metadata, leaving the receiver
			unable to make use of the affected HTTP representation.
			3. Loss of a QUIC packet containing an HTTP/3 "DATA" frame header
			leaves a receiver unsure where to look for the start of the next
			HTTP/3 frame on the same stream. In the unlikely event that the
			receiver manages to resynchronise to the start of a subsequent
			HTTP/3 "DATA" frame, the position of the payload in the HTTP
			representation data is unknown because it is not explicitly
			signalled in the "DATA" frame header. The Offset field in the
			QUIC "STREAM" header describes the offset within the stream, but
			it is impossible for the receiver to know the size of any "DATA"
			frame headers that were lost.
			4. Loss of QUIC packets that only contain part of an HTTP/3 "DATA"
			frame Data field (i.e. beyond the frame header) can be recovered
			using the unicast repair mechanism described in Section 7.2.
			[H3-DATA-OFFSET] describes the "DATA_WITH_OFFSET" HTTP/3 extension
			frame type, which can be used to solve the third problem described
			above. Multicast QUIC sessions that make use of the
			"DATA_WITH_OFFSET" extension frame MUST advertise the session with
			the appropriate non-compatible experiment identifier "data-offset" in
			the ALPN string, as specified in Section 9.1.
			5.6. HTTP/3 Extension frames
			Except where explicitly allowed by this specification (e.g. in
			Section 5.5 above), HTTP/3 extension frames (e.g. "ALTSVC") are
			prohibited by this profile. Participants MUST NOT make any attempt
			to send prohibited extension frame types. Reception of these MUST be
			handled as described in Section 5.7.
			5.7. Prohibited HTTP/3 Frames
	The following HTTP/3 frames MUST NOT be transmitted by participants:		The following HTTP/3 frames MUST NOT be transmitted by participants:
	"GOAWAY", "MAX_PUSH_ID", "SETTINGS".		"GOAWAY", "MAX_PUSH_ID", "SETTINGS".
	In addition, all HTTP/3 extension frame types MUST NOT be transmitted		In addition, all HTTP/3 extension frame types MUST NOT be transmitted
	by participants.		by participants.
	The following HTTP/3 frames MUST NOT be transmitted by receivers:		The following HTTP/3 frames MUST NOT be transmitted by receivers:
	"CANCEL_PUSH".		"CANCEL_PUSH".
	skipping to change at page 34, line 12 ¶		skipping to change at page 35, line 12 ¶
	signature-algorithm=rsa-sha256		signature-algorithm=rsa-sha256
	The requirements for endpoint usage of "signature-algorithm" are		The requirements for endpoint usage of "signature-algorithm" are
	described in Section 3.8.		described in Section 3.8.
	10.2.10. Extensions		10.2.10. Extensions
	This document specifies the "extensions" parameter for Alt-Svc, which		This document specifies the "extensions" parameter for Alt-Svc, which
	carries a list of extension types potentially in use by a multicast		carries a list of extension types potentially in use by a multicast
	QUIC session. "extensions" MUST only contain values from the QUIC		QUIC session. "extensions" MUST only contain values from the QUIC
	Transport Parameter registry ([QUIC-TRANSPORT], section 22.2) that		Transport Parameter registry ([QUIC-TRANSPORT], section 22.3) that
	have explicit support for multicast QUIC. Each entry in the list		have explicit support for multicast QUIC. Each entry in the list
	consists of a key identifying the transport parameter, and an		consists of a key identifying the transport parameter, and an
	optional value. Both the key and the value are hex-encoded.		optional value. Both the key and the value are hex-encoded.
	Syntax:		Syntax:
	extensions = DQUOTE ext-transport-param *[ "," ext-transport-param ] DQUOTE		extensions = DQUOTE ext-transport-param
	ext-transport-param = ext-key [ "=" ext-value ]		*[ "," ext-transport-param ] DQUOTE
	ext-key = 4*4HEXDIG; Transport Parameter key		ext-transport-param = ext-key [ "=" ext-value ]
	ext-value = *HEXDIG; Optional Transport Parameter value		ext-key = 4*4HEXDIG; Transport Parameter key
			ext-value = *HEXDIG; Optional Transport Parameter value
	For example, the following specifies two extensions:		For example, the following specifies two extensions:
	extensions="0094,0d0d=f00"		extensions="0094,0d0d=f00"
	The requirements for endpoint usage of "extensions" are described in		The requirements for endpoint usage of "extensions" are described in
	Section 3.6		Section 3.6
	11. Security and Privacy Considerations		11. Security Considerations
	This document specifies a profile of QUIC and HTTP/3 that changes the		This document specifies a profile of QUIC and HTTP/3 that changes the
	security model. In order to address this, application-level security		security model. In order to address this, application-level security
	methods are described in Section 6. This document does not preclude		methods are described in Section 6. This document does not preclude
	the use of secure multicast approaches that may provide additional		the use of secure multicast approaches that may provide additional
	security assurances required for certain use cases.		security assurances required for certain use cases.
	The use of side-channel or out-of-band technologies (potentially		The use of side-channel or out-of-band technologies (potentially
	bidirectional interactions) to support multicast QUIC sessions are		bidirectional interactions) to support multicast QUIC sessions are
	considered out of this document's scope. Services using such		considered out of this document's scope. Services using such
	skipping to change at page 35, line 43 ¶		skipping to change at page 36, line 44 ¶
	Sessions that use a symmetric key for packet protection are subject		Sessions that use a symmetric key for packet protection are subject
	to the possibility of a malicious actor modifying traffic at some		to the possibility of a malicious actor modifying traffic at some
	point in the network between a legitimate sender and one (or more)		point in the network between a legitimate sender and one (or more)
	receivers. Receiver-side validation, as specified in Section 6 of		receivers. Receiver-side validation, as specified in Section 6 of
	the present document, and also in [QUIC-TRANSPORT], allows for the		the present document, and also in [QUIC-TRANSPORT], allows for the
	detection of such modification. Two approaches help mitigate the		detection of such modification. Two approaches help mitigate the
	impact of modification; the first is application-level methods that		impact of modification; the first is application-level methods that
	protect data (Section 6.1) and metadata (Section 6.2); the second is		protect data (Section 6.1) and metadata (Section 6.2); the second is
	reduction of the QUIC packet attack surface by means of removal of		reduction of the QUIC packet attack surface by means of removal of
	many frame types (Section 4.12 and Section 5.6).		many frame types (Section 4.12 and Section 5.7).
	11.2. Protection of Discovery Mechanism		11.2. Protection of Discovery Mechanism
	Multicast QUIC session advertisements SHOULD be conveyed over a		Multicast QUIC session advertisements SHOULD be conveyed over a
	secure transport that guarantees authenticity and integrity in order		secure transport that guarantees authenticity and integrity in order
	to mitigate attacks related to a malicious service advertisement, for		to mitigate attacks related to a malicious service advertisement, for
	example a "man in the middle" directing endpoints to a service that		example a "man in the middle" directing endpoints to a service that
	may lead to other attacks or exploitations.		may lead to other attacks or exploitations.
	*Authors' Note:* We invite review comments on mandating the use of		*Authors' Note:* We invite review comments on mandating the use of
	a secure transport for advertising sessions.		a secure transport for advertising sessions.
	Endpoints that make use of multicast QUIC session advertisements		Endpoints that make use of multicast QUIC session advertisements
	SHOULD have reasonable assurance that the alternative service is		SHOULD have reasonable assurance that the alternative service is
	under control of, and valid for, the whole origin, as described in		under control of, and valid for, the whole origin, as described in
	Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be		Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be
	used to fulfil this requirement.		used to fulfil this requirement.
	11.3. Spoofing		11.3. Spoofing
	11.3.1. Spoofed Ack Attacks		11.3.1. Sender Spoofing
	The Spoofed "ACK" attack described in Section 13.1 of
	[QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame
	is prohibited (Section 4.11) by the present document.
	11.3.2. Sender Spoofing
	A malicious actor may be able to stage a spoof attack by sending fake		A malicious actor may be able to stage a spoof attack by sending fake
	QUIC packets to a multicast QUIC session. This could affect the		QUIC packets to a multicast QUIC session. This could affect the
	operation or behaviour of receivers. In a multicast scenario, this		operation or behaviour of receivers. In a multicast scenario, this
	form of attack has the potential to scale massively.		form of attack has the potential to scale massively.
	The feasibility of spoofing a multicast sender is governed by the		The feasibility of spoofing a multicast sender is governed by the
	characteristics of the multicast deployment and network		characteristics of the multicast deployment and network
	infrastructure. The use of source-specific multicast [RFC4607] may		infrastructure. The use of source-specific multicast [RFC4607] may
	reduce the feasibility. The use of content authenticity		reduce the feasibility. The use of content authenticity
	(Section 6.2) may mitigate concerns for the application-level		(Section 6.2) may mitigate concerns for the application-level
	messages. However, there remains the possibility for transport-level		messages. However, there remains the possibility for transport-level
	messages to be spoofed. Multicast applications should consider		messages to be spoofed. Multicast applications should consider
	further mitigations to address this concern.		further mitigations to address this concern.
	11.3.3. Receiver Spoofing
	Client source address concerns discussed in Section 7.5 of
	[QUIC-TRANSPORT] are out of scope because the connection
	establishment is replaced with session establishment in the present
	document. Further, the impact that spoofed receivers would have on
	the sender is minimal. The impact of malicious participants on the
	network is discussed in Section 11.6.2.
	11.4. Replay Attacks		11.4. Replay Attacks
	Conventional QUIC strategies for protecting against replay attacks		Conventional QUIC strategies for protecting against replay attacks
	apply similarly here.		apply similarly here.
	Certain multicast QUIC sessions may use a shared key for transport-		Certain multicast QUIC sessions may use a shared key for transport-
	level encryption, which would allow an attacker to record, decrypt,		level encryption, which would allow an attacker to record, decrypt,
	repackage and replay QUIC packets. Section 6.2 discusses how the		repackage and replay QUIC packets. Section 6.2 discusses how the
	application-level contents may be protected from replay (by signing		application-level contents may be protected from replay (by signing
	the "Date" HTTP header), which provides some mitigation to the		the "Date" HTTP header), which provides some mitigation to the
	skipping to change at page 37, line 18 ¶		skipping to change at page 38, line 4 ¶
	application-level contents may be protected from replay (by signing		application-level contents may be protected from replay (by signing
	the "Date" HTTP header), which provides some mitigation to the		the "Date" HTTP header), which provides some mitigation to the
	success rate or effects of replay attacks.		success rate or effects of replay attacks.
	11.5. Message Deletion		11.5. Message Deletion
	Since HTTP over multicast QUIC is designed to tolerate unreliable		Since HTTP over multicast QUIC is designed to tolerate unreliable
	delivery, the impacts of message deletion attacks are presumed to be		delivery, the impacts of message deletion attacks are presumed to be
	small. Deletion of packets carrying HTTP headers will cause a		small. Deletion of packets carrying HTTP headers will cause a
	receiver to ignore subsequent packets carrying body data.		receiver to ignore subsequent packets carrying body data.
	Furthermore, the use of multicast QUIC sessions is opportunistic;		Furthermore, the use of multicast QUIC sessions is opportunistic;
	disruption in service (for example, deleting packets and causing a		disruption in service (for example, deleting packets and causing a
	receiver to fail in construction of a content object) is mitigated by		receiver to fail in construction of a content object) is mitigated by
	falling back to a unicast service. Considerations for how this may		falling back to a unicast service. Considerations for how this may
	affect the performance of the unicast service are given in		affect the performance of the unicast service are given in
	Section 11.6.3.		Section 11.6.3.
	11.6. Denial of Service		11.6. Denial of Service
	11.6.1. Unprotected Frames and Packets		11.6.1. Unprotected Frames and Packets
	The handling of unprotected QUIC packets is discussed in section		The profile described in the present document provides the means for
	9.1.4 of [QUIC-TLS]. The profile described in the present document		a multicast sender to protect QUIC packets with a shared key, which
	provides the means for a multicast sender to protect QUIC packets		is not a strong protection. The weak protection of QUIC packets
	with a shared key, which is not a strong protection. The weak		could present a denial-of-service risk. To mitigate the impact of
	protection of QUIC packets could present a denial-of-service risk.		handling such QUIC packets, certain frames and packets are prohibited
	To mitigate the impact of handling such QUIC packets, certain frames		as described in (Section 4.12 and Section 5.7).
	and packets are prohibited as described in (Section 4.12 and
	Section 5.6).
	The frame types that are allowed by this profile do not present a		The frame types that are allowed by this profile do not present a
	risk of denial of service. Concerns over authenticity and integrity		risk of denial of service. Concerns over authenticity and integrity
	are addressed by the application-layer protection mechanisms		are addressed by the application-layer protection mechanisms
	described in Section 6.		described in Section 6.
	11.6.2. Network Performance Degradation		11.6.2. Network Performance Degradation
	The possibility for malfunctioning or malicious participants to		The possibility for malfunctioning or malicious participants to
	degrade the network is a broad issue and considered out of scope for		degrade the network is a broad issue and considered out of scope for
	skipping to change at page 41, line 9 ¶		skipping to change at page 41, line 39 ¶
	12.2.11. Extension		12.2.11. Extension
	Parameter name: extension		Parameter name: extension
	Specification: This document, Section 10.2.10		Specification: This document, Section 10.2.10
	13. References		13. References
	13.1. Normative References		13.1. Normative References
			[H3-DATA-OFFSET]
			Hurst, S., "An Offset Extension Frame For HTTP/3 Data",
			draft-hurst-quic-http-data-offset-frame-00 (work in
			progress).
	[I-D.cavage-http-signatures]		[I-D.cavage-http-signatures]
	Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-		Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
	cavage-http-signatures-12 (work in progress), October		cavage-http-signatures-12 (work in progress), October
	2019.		2019.
	[QUIC-HTTP]		[QUIC-HTTP]
	Bishop, M., Ed., "Hypertext Transfer Protocol Version 3		Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", draft-ietf-quic-http-29 (work in progress).		(HTTP/3)", draft-ietf-quic-http-34 (work in progress).
	[QUIC-QPACK]		[QUIC-QPACK]
	Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed.,		Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed.,
	"QPACK: Header Compression for HTTP over QUIC", draft-		"QPACK: Header Compression for HTTP over QUIC", draft-
	ietf-quic-qpack-16 (work in progress).		ietf-quic-qpack-21 (work in progress).
	[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", draft-ietf-quic-		Multiplexed and Secure Transport", draft-ietf-quic-
	transport-29 (work in progress).		transport-34 (work in progress).
	[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>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<https://www.rfc-editor.org/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc3168>.
	skipping to change at page 42, line 41 ¶		skipping to change at page 43, line 26 ¶
	April 2016, <https://www.rfc-editor.org/info/rfc7838>.		April 2016, <https://www.rfc-editor.org/info/rfc7838>.
	[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>.
	13.2. Informative References		13.2. Informative References
	[QUIC-RECOVERY]		[QUIC-RECOVERY]
	Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection		Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
	and Congestion Control", draft-ietf-quic-recovery-29 (work		and Congestion Control", draft-ietf-quic-recovery-34 (work
	in progress).		in progress).
	[QUIC-TLS]		[QUIC-TLS]
	Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport		Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport
	Layer Security (TLS) to Secure QUIC", draft-ietf-quic-		Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
	tls-29 (work in progress).		tls-34 (work in progress).
	[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,		[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
	RFC 1112, DOI 10.17487/RFC1112, August 1989,		RFC 1112, DOI 10.17487/RFC1112, August 1989,
	<https://www.rfc-editor.org/info/rfc1112>.		<https://www.rfc-editor.org/info/rfc1112>.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	DOI 10.17487/RFC1191, November 1990,		DOI 10.17487/RFC1191, November 1990,
	<https://www.rfc-editor.org/info/rfc1191>.		<https://www.rfc-editor.org/info/rfc1191>.
	[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session		[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
	skipping to change at page 61, line 44 ¶		skipping to change at page 62, line 44 ¶
	| | 0. | |		| | 0. | |
	+-------------+----------------------------------+------------------+		+-------------+----------------------------------+------------------+
	Table 7: HTTP Metadata Compression Layer		Table 7: HTTP Metadata Compression Layer
	Appendix D. Changelog		Appendix D. Changelog
	*RFC Editor's Note:* Please remove this section prior to		*RFC Editor's Note:* Please remove this section prior to
	publication of a final version of this document.		publication of a final version of this document.
	D.1. Since draft-pardue-quic-http-mcast-06		D.1. Since draft-pardue-quic-http-mcast-07
	o Update references to QUIC I-Ds.		o Update references to QUIC WG I-Ds.
			o Remove stale references to sections of the QUIC WG I-Ds that don't
			exist any more.
			o Add references to the DATA_WITH_OFFSET frame I-D.
			D.2. Since draft-pardue-quic-http-mcast-06
			o Update references to QUIC WG I-Ds.
	o Clarify that only the first source-address parameter should be		o Clarify that only the first source-address parameter should be
	used if duplicated.		used if duplicated.
	o Fix source-address example to not be a quoted string.		o Fix source-address example to not be a quoted string.
	o Fix bytes in the ALPN identification sequence following change to		o Fix bytes in the ALPN identification sequence following change to
	h3m.		h3m.
	o Update language around QUIC Connection IDs to reflect the core		o Update language around QUIC Connection IDs to reflect the core
	skipping to change at page 62, line 27 ¶		skipping to change at page 63, line 36 ¶
	o Update language around QPACK static and dynamic table indexing to		o Update language around QPACK static and dynamic table indexing to
	more closely align with the core spec.		more closely align with the core spec.
	o Update Session Idle Timeout to match core specs, including		o Update Session Idle Timeout to match core specs, including
	removing limitation of 600 seconds and expressing in milliseconds,		removing limitation of 600 seconds and expressing in milliseconds,
	not seconds.		not seconds.
	o Preface Session Termination with a statement clarifying that		o Preface Session Termination with a statement clarifying that
	participants may leave at any time.		participants may leave at any time.
	D.2. Since draft-pardue-quic-http-mcast-05		D.3. Since draft-pardue-quic-http-mcast-05
	o Update references to QUIC I-Ds.		o Update references to QUIC WG I-Ds.
	o Sender packet number size is now fixed for the duration of a		o Sender packet number size is now fixed for the duration of a
	session.		session.
	o Change how to handle multiple session IDs: sessions are now only		o Change how to handle multiple session IDs: sessions are now only
	allowed a single ID.		allowed a single ID.
	o Remove incompatible requirements set by [QUIC-TRANSPORT]'s		o Remove incompatible requirements set by [QUIC-TRANSPORT]'s
	"Required Operations".		"Required Operations".
	skipping to change at page 63, line 5 ¶		skipping to change at page 64, line 14 ¶
	o Remove HTTP Prioritization references.		o Remove HTTP Prioritization references.
	o Add new "extensions" Alt-Svc parameter.		o Add new "extensions" Alt-Svc parameter.
	o Broaden peak flow rate to QUIC payload to encompass all frame		o Broaden peak flow rate to QUIC payload to encompass all frame
	types.		types.
	o Change ALPN identifier to h3m.		o Change ALPN identifier to h3m.
	D.3. Since draft-pardue-quic-http-mcast-04		D.4. Since draft-pardue-quic-http-mcast-04
	o Update references to QUIC I-Ds, remove QUIC-SPIN. (draft-ietf-		o Update references to QUIC WG I-Ds, remove QUIC-SPIN. (draft-ietf-
	quic-transport-20)		quic-transport-20)
	o Update session ID length to match new connection ID length.		o Update session ID length to match new connection ID length.
	(draft-ietf-quic-transport-22)		(draft-ietf-quic-transport-22)
	o Clarify the mapping for the new "active_connection_id_limit"		o Clarify the mapping for the new "active_connection_id_limit"
	session parameter. (draft-ietf-quic-transport-21)		session parameter. (draft-ietf-quic-transport-21)
	o Update text to conform with latest version negotiation text from		o Update text to conform with latest version negotiation text from
	[QUIC-TRANSPORT].		[QUIC-TRANSPORT].
	skipping to change at page 63, line 37 ¶		skipping to change at page 64, line 46 ¶
	o Clarify difference between connection and session migration.		o Clarify difference between connection and session migration.
	o Move GOAWAY frame to HTTP/3 profile.		o Move GOAWAY frame to HTTP/3 profile.
	o Renamed Session Shutdown to Connection Shutdown to mirror concept		o Renamed Session Shutdown to Connection Shutdown to mirror concept
	in [QUIC-TRANSPORT].		in [QUIC-TRANSPORT].
	o Clarify the layer of each frame type when referred to.		o Clarify the layer of each frame type when referred to.
	D.4. Since draft-pardue-quic-http-mcast-03		D.5. Since draft-pardue-quic-http-mcast-03
	o Update references to QUIC I-Ds.		o Update references to QUIC WG I-Ds.
	o Change crypto handshake text now that it's no longer done on		o Change crypto handshake text now that it's no longer done on
	Stream ID 0.		Stream ID 0.
	o Update to reference Source and Destination Connection IDs.		o Update to reference Source and Destination Connection IDs.
	o Prohibit the use of connection coalescing, migration and ECN.		o Prohibit the use of connection coalescing, migration and ECN.
	o Update allowed and disallowed packets and frames to match the core		o Update allowed and disallowed packets and frames to match the core
	specs.		specs.
	skipping to change at page 64, line 20 ¶		skipping to change at page 65, line 30 ¶
	o Clarify packet number space (only use application data space, not		o Clarify packet number space (only use application data space, not
	initial or handshake).		initial or handshake).
	o Add statement on QUIC latency spin bit.		o Add statement on QUIC latency spin bit.
	o Removed sentence stating that multiple Connection IDs cannot be		o Removed sentence stating that multiple Connection IDs cannot be
	used concurrently in a unicast QUIC session, in accordance with		used concurrently in a unicast QUIC session, in accordance with
	[QUIC-TRANSPORT] section 5.1.2.		[QUIC-TRANSPORT] section 5.1.2.
	D.5. Since draft-pardue-quic-http-mcast-02		D.6. Since draft-pardue-quic-http-mcast-02
	o No changes.		o No changes.
	D.6. Since draft-pardue-quic-http-mcast-01		D.7. Since draft-pardue-quic-http-mcast-01
	o Explicit guidance on maximum stream ID value permitted.		o Explicit guidance on maximum stream ID value permitted.
	o Updated guidance on PING (and PONG) frame.		o Updated guidance on PING (and PONG) frame.
	o Added a comparison table to appendix.		o Added a comparison table to appendix.
	o Remove invalid use of trailing headers.		o Remove invalid use of trailing headers.
	o Use the new HTTP/QUIC DATA frame.		o Use the new HTTP/QUIC DATA frame.
	skipping to change at page 64, line 48 ¶		skipping to change at page 66, line 10 ¶
	o Redefine server push to reflect core document changes.		o Redefine server push to reflect core document changes.
	o Remove default idle time out value.		o Remove default idle time out value.
	o Clarify session parameter requirements (session-idle-timeout		o Clarify session parameter requirements (session-idle-timeout
	became mandatory).		became mandatory).
	o Update frame notation convention.		o Update frame notation convention.
	D.7. Since draft-pardue-quic-http-mcast-00		D.8. Since draft-pardue-quic-http-mcast-00
	o Update references to QUIC I-Ds.		o Update references to QUIC WG I-Ds.
	o Relax session leaving requirements language.		o Relax session leaving requirements language.
	o Clarify handling of omitted session parameter advertisements.		o Clarify handling of omitted session parameter advertisements.
	o Rename "Idle" state to "Quiescent".		o Rename "Idle" state to "Quiescent".
	o Add digest algorithm session parameter.		o Add digest algorithm session parameter.
	o Add signature algorithm session parameter.		o Add signature algorithm session parameter.
End of changes. 54 change blocks.
	137 lines changed or deleted		189 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/