< draft-pardue-quic-http-mcast-06.txt		draft-pardue-quic-http-mcast-07.txt >
	Network Working Group L. Pardue		Network Working Group L. Pardue
	Internet-Draft		Internet-Draft
	Intended status: Informational R. Bradbury		Intended status: Informational R. Bradbury
	Expires: August 10, 2020 S. Hurst		Expires: February 8, 2021 S. Hurst
	BBC Research & Development		BBC Research & Development
	February 7, 2020		August 7, 2020
	Hypertext Transfer Protocol (HTTP) over multicast QUIC		Hypertext Transfer Protocol (HTTP) over multicast QUIC
	draft-pardue-quic-http-mcast-06		draft-pardue-quic-http-mcast-07
	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 August 10, 2020.		This Internet-Draft will expire on February 8, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 49 ¶		skipping to change at page 2, line 49 ¶
	4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 19		4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 19
	4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 19		4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 19
	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 . . . . . . . . . . . . . . . . 22		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 . . . . . . . . . . . . . . . . . . 23
	5.4. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24		5.4. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24
	5.5. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24		5.5. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24
	5.6. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24		5.6. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24
	6. Application-Layer Security . . . . . . . . . . . . . . . . . 24		6. Application-Layer Security . . . . . . . . . . . . . . . . . 24
	6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 25		6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 25
	6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 25		6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 25
	6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 26		6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 27
	7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 27		7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.1. Forward Error Correction . . . . . . . . . . . . . . . . 27		7.1. Forward Error Correction . . . . . . . . . . . . . . . . 27
	7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 27		7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 27
	8. Transmission of Partial Content . . . . . . . . . . . . . . . 28		8. Transmission of Partial Content . . . . . . . . . . . . . . . 28
	9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 28		9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 28
	9.1. Draft Version Identification . . . . . . . . . . . . . . 28		9.1. Draft Version Identification . . . . . . . . . . . . . . 28
	10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 29		10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 29
	10.1. Source-specific Multicast Advertisement . . . . . . . . 29		10.1. Source-specific Multicast Advertisement . . . . . . . . 30
	10.2. Session Parameter Advertisement . . . . . . . . . . . . 30		10.2. Session Parameter Advertisement . . . . . . . . . . . . 30
	10.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30		10.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30
	10.2.2. Session Key . . . . . . . . . . . . . . . . . . . . 30		10.2.2. Session Key . . . . . . . . . . . . . . . . . . . . 31
	10.2.3. Session Cipher Initialization Vector . . . . . . . . 31		10.2.3. Session Cipher Initialization Vector . . . . . . . . 31
	10.2.4. Session Identification . . . . . . . . . . . . . . . 31		10.2.4. Session Identification . . . . . . . . . . . . . . . 31
	10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 31		10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 32
	10.2.6. Resource Concurrency . . . . . . . . . . . . . . . . 32		10.2.6. Resource Concurrency . . . . . . . . . . . . . . . . 32
	10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 32		10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 32
	10.2.8. Digest Algorithm . . . . . . . . . . . . . . . . . . 33		10.2.8. Digest Algorithm . . . . . . . . . . . . . . . . . . 33
	10.2.9. Signature Algorithm . . . . . . . . . . . . . . . . 33		10.2.9. Signature Algorithm . . . . . . . . . . . . . . . . 33
	10.2.10. Extensions . . . . . . . . . . . . . . . . . . . . . 33		10.2.10. Extensions . . . . . . . . . . . . . . . . . . . . . 34
	11. Security and Privacy Considerations . . . . . . . . . . . . . 34		11. Security and Privacy Considerations . . . . . . . . . . . . . 34
	11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 34		11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 34
	11.1.1. Large-scale Data Gathering and Correlation . . . . . 35		11.1.1. Large-scale Data Gathering and Correlation . . . . . 35
	11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 35		11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 35
	11.2. Protection of Discovery Mechanism . . . . . . . . . . . 35		11.2. Protection of Discovery Mechanism . . . . . . . . . . . 35
	11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 36		11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 36
	11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 36		11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 36
	11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 36		11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 36
	11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 36		11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 36
	11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 36		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 . . . . . . . . . . . . . . . . . . . 37
	11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 37		11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 37
	11.6.2. Network Performance Degradation . . . . . . . . . . 37		11.6.2. Network Performance Degradation . . . . . . . . . . 37
	11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 37		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 . . . . . . . . . . . 38
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	12.1. Registration of Protocol Identification String . . . . . 38		12.1. Registration of Protocol Identification String . . . . . 39
	12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 39		12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 39
	12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 39		12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 39
	12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 39		12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 39
	12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 39		12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 39
	12.2.4. Initialization Vector . . . . . . . . . . . . . . . 39		12.2.4. Initialization Vector . . . . . . . . . . . . . . . 40
	12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 39		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 . . . . . . . . . . . . 40
	12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 40		12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 40
	12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 40		12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 40
	12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 40		12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 40
	12.2.11. Extension . . . . . . . . . . . . . . . . . . . . . 40		12.2.11. Extension . . . . . . . . . . . . . . . . . . . . . 40
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
	13.1. Normative References . . . . . . . . . . . . . . . . . . 40		13.1. Normative References . . . . . . . . . . . . . . . . . . 41
	13.2. Informative References . . . . . . . . . . . . . . . . . 42		13.2. Informative References . . . . . . . . . . . . . . . . . 42
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 44		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 44
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 44		Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 44
	B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 44		B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 44
	B.1.1. Source-specific Multicast QUIC Session . . . . . . . 44		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 . . . . . . . . . . 45
	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 . . . 45
	B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 46		B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 46
	B.2.1. Transfer without Content Integrity or Authenticity . 46		B.2.1. Transfer without Content Integrity or Authenticity . 46
	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 . . . . . . . . . . . . . . . . . . . 46
	B.2.3. Transfer with Content Integrity and without		B.2.3. Transfer with Content Integrity and without
	Authenticity . . . . . . . . . . . . . . . . . . . . 47		Authenticity . . . . . . . . . . . . . . . . . . . . 47
	B.2.4. Partial Transfer with Content Integrity and without		B.2.4. Partial Transfer with Content Integrity and without
	Authenticity . . . . . . . . . . . . . . . . . . . . 47		Authenticity . . . . . . . . . . . . . . . . . . . . 48
	B.2.5. Transfer with Content Integrity and Authenticity . . 48		B.2.5. Transfer with Content Integrity and Authenticity . . 48
	B.2.6. Partial Transfer with Content Integrity and		B.2.6. Partial Transfer with Content Integrity and
	Authenticity . . . . . . . . . . . . . . . . . . . . 49		Authenticity . . . . . . . . . . . . . . . . . . . . 49
	Appendix C. Summary of differences from unicast QUIC and HTTP/3 50		Appendix C. Summary of differences from unicast QUIC and HTTP/3 50
	Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 61		Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 61
	D.1. Since draft-pardue-quic-http-mcast-05 . . . . . . . . . . 61		D.1. Since draft-pardue-quic-http-mcast-06 . . . . . . . . . . 61
	D.2. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 62		D.2. Since draft-pardue-quic-http-mcast-05 . . . . . . . . . . 62
	D.3. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 62		D.3. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 63
	D.4. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 63		D.4. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 63
	D.5. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 63		D.5. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 64
	D.6. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 64		D.6. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 64
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64		D.7. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 64
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
	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 7, line 21 ¶		skipping to change at page 7, line 21 ¶
	o session parameter: Characteristic of a multicast QUIC session.		o session parameter: Characteristic of a multicast QUIC session.
	2. Multicast QUIC Sessions		2. Multicast QUIC Sessions
	A QUIC connection [QUIC-TRANSPORT] carried over bidirectional unicast		A QUIC connection [QUIC-TRANSPORT] carried over bidirectional unicast
	is defined as a conversation between two QUIC endpoints that		is defined as a conversation between two QUIC endpoints that
	multiplexes several logical streams within a single encryption		multiplexes several logical streams within a single encryption
	context. This is a one-to-one relationship. Furthermore, QUIC		context. This is a one-to-one relationship. Furthermore, QUIC
	connections achieve decoupling from the underlying network (IP and		connections achieve decoupling from the underlying network (IP and
	port) by means of a pair of Connection IDs, each uniquely identifying		port) by means of a set of Connection IDs, with each endpoint
	the flow in one direction. Use of a consistent connection identifier		generating these IDs and using them to identify the direction of
	allows QUIC connections to survive changes to the network		flow. Use of a consistent connection identifier allows QUIC
	connectivity. The establishment of a QUIC connection relies upon an		connections to survive changes to the network connectivity. The
	up-front, in-band exchange (and possible negotiation) of		establishment of a QUIC connection relies upon an up-front, in-band
	cryptographic and transport parameters (conveyed in QUIC handshake		exchange (and possible negotiation) of cryptographic and transport
	messages).		parameters (conveyed in QUIC handshake messages).
	The mapping of HTTP semantics over the QUIC transport protocol		The mapping of HTTP semantics over the QUIC transport protocol
	[QUIC-HTTP] facilitates the transfer of hypermedia over QUIC		[QUIC-HTTP] facilitates the transfer of hypermedia over QUIC
	connections. The establishment of a HTTP/3 connection relies upon		connections. The establishment of a HTTP/3 connection relies upon
	all the requirements stipulated for the transport, as well as		all the requirements stipulated for the transport, as well as
	communication of HTTP-specific settings (conveyed in HTTP/3		communication of HTTP-specific settings (conveyed in HTTP/3
	"SETTINGS" frames). Such parameters may be required or optional and		"SETTINGS" frames). Such parameters may be required or optional and
	may be used by either endpoint to control the characteristics of		may be used by either endpoint to control the characteristics of
	connection usage.		connection usage.
	skipping to change at page 9, line 14 ¶		skipping to change at page 9, line 14 ¶
	from Half-Established to Fully-Established occurs when at least one		from Half-Established to Fully-Established occurs when at least one
	receiver joins the session.		receiver joins the session.
	It is equally valid for a receiver to join a session in the Quiescent		It is equally valid for a receiver to join a session in the Quiescent
	state, triggering the transition to Half-Established. In this case,		state, triggering the transition to Half-Established. In this case,
	the transition to Fully-Established takes place only when a sender		the transition to Fully-Established takes place only when a sender
	joins the session.		joins the session.
	2.1.2. Session Termination		2.1.2. Session Termination
	A session enters the Finished state when all participants leave it.		Participants MAY leave a session at any time. A session enters the
	The methods for leaving a session are either explicit shutdown		Finished state when all participants have left it. Senders MAY
	(Section 5.4), implicit shutdown (i.e. idle timeout, Section 3.3) or		signal their intent to leave using explicit session tear-down
	migration away (described in the next section).		(Section 5.4). Receivers can detect that a sender has left via idle
			timeout (Section 3.3) and take that as a signal to leave, or
			receivers may leave as part of session migration (described in the
			next section).
	In a typical case, a session that is in the Fully-Established state		In a typical case, a session that is in the Fully-Established state
	would be closed in two stages. In the first stage the sender sends		would be closed in two stages. In the first stage the sender sends
	explicit shutdown messages to the multicast group and subsequently		explicit shutdown messages to the multicast group and subsequently
	stops transmitting packets. This causes the session to transition		stops transmitting packets. This causes the session to transition
	from Fully-Established to Half-Established. In the second stage,		from Fully-Established to Half-Established. In the second stage,
	receivers that have received explicit shutdown messages leave the		receivers that have received explicit shutdown messages leave the
	multicast group. Once all receivers have left the session it		multicast group. Once all receivers have left the session it
	transitions from Half-Established to Finished.		transitions from Half-Established to Finished.
	skipping to change at page 10, line 43 ¶		skipping to change at page 10, line 45 ¶
	The Session ID is carried in the Destination Connection ID field of		The Session ID is carried in the Destination Connection ID field of
	the QUIC packet (see Section 4.3). Source Connection IDs are not		the QUIC packet (see Section 4.3). Source Connection IDs are not
	used.		used.
	The maximum size of a Session ID is 160 bits. The size of the		The maximum size of a Session ID is 160 bits. The size of the
	Destination Connection ID field used to convey the Session ID SHALL		Destination Connection ID field used to convey the Session ID SHALL
	be the smallest number of full bytes required to represent the full		be the smallest number of full bytes required to represent the full
	Session ID value advertised in the "session-id" session parameter		Session ID value advertised in the "session-id" session parameter
	(Section 10.2.4). If no "session-id" parameter is advertised, then		(Section 10.2.4). If no "session-id" parameter is advertised, then
	this session has no explicit session ID, and the Destination		this session has a zero-length session ID, and the Destination
	Connection ID field SHALL be omitted from all QUIC packets related to		Connection ID field SHALL be omitted from all QUIC packets related to
	the session.		the session.
	A multicast sender participating in a session with an advertised		A multicast sender participating in a session with an advertised
	"session-id" session parameter MUST send QUIC packets with a matching		"session-id" session parameter MUST send QUIC packets with a matching
	Session ID. Conversely, a multicast sender participating in a		Session ID. Conversely, a multicast sender participating in a
	session without an advertised "session-id" session parameter MUST NOT		session without an advertised "session-id" session parameter MUST NOT
	send QUIC packets with a Destination Connection ID field.		send QUIC packets with a non-zero-length Destination Connection ID
			field.
	A multicast receiver participating in a session with an advertised		A multicast receiver participating in a session with an advertised
	"session-id" session parameter MUST validate that the Session ID of		"session-id" session parameter MUST validate that the Session ID of
	received QUIC packets matches that advertised in the session		received QUIC packets matches that advertised in the session
	parameters (Section 10.2.4) before any HTTP-level processing is done.		parameters (Section 10.2.4) before any HTTP-level processing is done.
	In the case of validation failure, the receiver SHOULD ignore the		In the case of validation failure, the receiver SHOULD ignore the
	packet in order to protect itself from denial-of-service attacks.		packet in order to protect itself from denial-of-service attacks.
	2.4. Session Security		2.4. Session Security
	skipping to change at page 18, line 9 ¶		skipping to change at page 18, line 9 ¶
	A multicast sender participating in a session MUST NOT use algorithms		A multicast sender participating in a session MUST NOT use algorithms
	outside the signalled signature algorithm set. A receiver MAY leave		outside the signalled signature algorithm set. A receiver MAY leave
	any session where an algorithm outside the signature algorithm set is		any session where an algorithm outside the signature algorithm set is
	used.		used.
	4. QUIC Profile		4. QUIC Profile
	*Authors' Note:* The QUIC transport document is subject to change.		*Authors' Note:* The QUIC transport document is subject to change.
	This section is based on our best understanding of draft-ietf-		This section is based on our best understanding of draft-ietf-
	quic-transport-25. 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.4 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
	skipping to change at page 18, line 34 ¶		skipping to change at page 18, line 34 ¶
	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
	described in Section 14 of [QUIC-TRANSPORT]. Implementations of this		described in Section 14 of [QUIC-TRANSPORT]. Implementations of this
	specification SHOULD bear in mind that the Path Maximum Transmission		specification SHOULD bear in mind that the Path Maximum Transmission
	Unit (PTMU) may be affected by multicast IP technologies such as		Unit (PMTU) may be affected by multicast IP technologies such as
	Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally,		Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally,
	consideration should be given toward the applicability of maximum		consideration should be given toward the applicability of maximum
	transmission unit discovery methods (such as PLPMTUD [RFC4821] and		transmission unit discovery methods (such as PLPMTUD [RFC4821] and
	PMTUD [RFC1191]) to multicast IP.		PMTUD [RFC1191]) to multicast IP.
	4.2. Packet Format		4.2. Packet Format
	Endpoints implementing this specification MUST only send QUIC packets		Endpoints implementing this specification MUST only send QUIC packets
	with the short header form. As short header packets do not include a		with the short header form. As short header packets do not include a
	length, senders MUST NOT attempt to coalesce any QUIC packets in the		length, senders MUST NOT attempt to coalesce any QUIC packets in the
	skipping to change at page 19, line 28 ¶		skipping to change at page 19, line 28 ¶
	latency between a client and a server. This mechanism is not usable		latency between a client and a server. This mechanism is not usable
	in a unidirectional multicast packet flow. Senders SHALL set the		in a unidirectional multicast packet flow. Senders SHALL set the
	spin bit to zero in all packets. Receivers SHOULD ignore the spin		spin bit to zero in all packets. Receivers SHOULD ignore the spin
	bit.		bit.
	*Authors' Note:* The authors welcome suggestions for the use of		*Authors' Note:* The authors welcome suggestions for the use of
	the spin bit in a multicast context.		the spin bit in a multicast context.
	4.3. Connection Identifier		4.3. Connection Identifier
	The Destination Connection ID field MUST be present in every QUIC		The Destination Connection ID field MUST be non-zero-length in every
	packet if the session was advertised with a "session-id" session		QUIC packet if the session was advertised with a "session-id" session
	parameter (Section 10.2.4). If there is no Session ID session		parameter (Section 10.2.4). If the multicast QUIC session
	parameter, then the Destination Connection ID MUST NOT be present in		advertisement does not carry a "session identifier" session
			parameter, then the Destination Connection ID MUST be zero-length in
	any QUIC packet for that session. In the case where multiple		any QUIC packet for that session. In the case where multiple
	sessions are multiplexed on the same 5-tuple network association, the		sessions are multiplexed on the same 5-tuple network association, the
	Destination Connection ID field MUST be present in every QUIC packet		Destination Connection ID field MUST be non-zero-length in every QUIC
	and must be distinct for each session.		packet and must be distinct for each session.
	4.4. Stream Identifier		4.4. Stream Identifier
	The maximum Stream ID of a multicast QUIC session is 2^62, as		The maximum Stream ID of a multicast QUIC session is 2^62, as
	explained in Section 3.5. With the exception of the first client-		explained in Section 3.5. With the exception of the first client-
	initiated request Stream ID, which is reserved as described in		initiated request Stream ID, which is reserved as described in
	Section 5.2, all Stream ID values SHALL be of the server-initiated		Section 5.2, all Stream ID values SHALL be of the server-initiated
	unidirectional stream type.		unidirectional stream type.
	4.5. Flow Control		4.5. Flow Control
	Conventional QUIC provides stream- and connection-level flow control,		Conventional QUIC provides stream- and connection-level flow control,
	and endpoints manage this by sending QUIC "MAX_DATA" or		and endpoints manage this by sending QUIC "MAX_DATA" or
	"MAX_STREAM_DATA" frames as required. When a sender is blocked from		"MAX_STREAM_DATA" frames as required. When a sender is blocked from
	sending flow-controlled frames, it sends an informational QUIC		sending flow-controlled frames, it sends an informational QUIC
	"BLOCKED" or "STREAM_BLOCKED" frame.		"DATA_BLOCKED" or "STREAM_DATA_BLOCKED" frame.
	In a unidirectional environment, the sender never has a receive		In a unidirectional environment, the sender never has a receive
	window and the receiver cannot send in-band updates. Therefore, the		window and the receiver cannot send in-band updates. Therefore, the
	management of flow-control windows and transmission of blockage		management of flow-control windows and transmission of blockage
	information is not supported by this profile. The QUIC "MAX_DATA",		information is not supported by this profile. The QUIC "MAX_DATA",
	"MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" frames are		"MAX_STREAM_DATA", "DATA_BLOCKED" and "STREAM_DATA_BLOCKED" frames
	prohibited by this profile. Participants MUST NOT send these frame		are prohibited by this profile. Participants MUST NOT send these
	types. Reception of these frame types MUST be handled as described		frame types. Reception of these frame types MUST be handled as
	in Section 4.12.		described in Section 4.12.
	4.6. Stream Termination		4.6. Stream Termination
	A sender MAY prematurely terminate the transmission on any unreserved		A sender MAY prematurely terminate the transmission on any unreserved
	QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or		QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or
	by sending a QUIC "RESET_STREAM" frame (as specified in		by sending a QUIC "RESET_STREAM" frame (as specified in
	[QUIC-TRANSPORT] and [QUIC-HTTP]).		[QUIC-TRANSPORT] and [QUIC-HTTP]).
	Receiving participants MUST NOT make any attempt to send QUIC		Receiving participants MUST NOT make any attempt to send QUIC
	"RESET_STREAM" frames to the multicast group.		"RESET_STREAM" frames to the multicast group.
	4.7. Connection Shutdown		4.7. Connection Shutdown
	Explicit shutdown of a multicast QUIC session using QUIC methods is		Explicit shutdown of a multicast QUIC session using QUIC methods is
	not supported by this profile.		not supported by this profile.
	The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the		The QUIC "CONNECTION_CLOSE" frames and the Stateless Reset packet are
	Stateless Reset packet are prohibited. Participants MUST NOT send		prohibited. Participants MUST NOT send these and reception MUST be
	these and reception MUST be handled as described in Section 4.12.		handled as described in Section 4.12.
	Explicit session tear-down using HTTP semantics is allowed, as		Explicit session tear-down using HTTP semantics is allowed, as
	described in Section 5.4.		described in Section 5.4.
	Implicit shutdown by means of silent close is also supported, as		Implicit shutdown by means of silent close is also supported, as
	described in Section 3.3.		described in Section 3.3.
	4.8. Connection Migration		4.8. Connection Migration
	[QUIC-TRANSPORT] has a connection migration feature that allows a		[QUIC-TRANSPORT] has a connection migration feature that allows a
	skipping to change at page 22, line 32 ¶		skipping to change at page 22, line 34 ¶
	"PING", "RESET_STREAM".		"PING", "RESET_STREAM".
	Reception of a prohibited or non-advertised QUIC frame or packet is a		Reception of a prohibited or non-advertised QUIC frame or packet is a
	protocol error. Receivers MUST ignore all prohibited QUIC frames and		protocol error. Receivers MUST ignore all prohibited QUIC frames and
	packets.		packets.
	5. HTTP/3 Profile		5. HTTP/3 Profile
	*Authors' Note:* The HTTP/3 mapping document is subject to change.		*Authors' Note:* The HTTP/3 mapping document is subject to change.
	This section is based on our best understanding of draft-ietf-		This section is based on our best understanding of draft-ietf-
	quic-http-25. The authors will track developments and will update		quic-http-29. The authors will track developments and will update
	this section accordingly.		this section accordingly.
	HTTP over multicast QUIC depends on HTTP server push, as described in		HTTP over multicast QUIC depends on HTTP server push, as described in
	Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional		Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional
	constraint on the use of server push. A multicast sender		constraint on the use of server push. A multicast sender
	participating in a session pushes resources as a series of QUIC		participating in a session pushes resources as a series of QUIC
	"STREAM" frames carrying HTTP/3 "PUSH_PROMISE", "HEADERS" and "DATA"		"STREAM" frames carrying HTTP/3 "PUSH_PROMISE", "HEADERS" and "DATA"
	frames. Examples of this are provided in Appendix B.2. Senders MUST		frames. Examples of this are provided in Appendix B.2. Senders MUST
	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.
	skipping to change at page 23, line 39 ¶		skipping to change at page 23, line 45 ¶
	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.
	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.
	*Authors' Note:* The exact value of this Stream ID is currently in
	flux. This section will track developments and will be updated
	accordingly. It is currently expected to be Stream ID 0.
	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
	header fields: indexing (via static or dynamic tables) and Huffman		header fields: indexing (via static or dynamic tables) and Huffman
	encoding.		encoding.
	A multicast QUIC session, as described in the present document, does		A multicast QUIC session, as described in the present document, does
	not provide the assurances (receiver participation, transport		not provide the assurances (receiver participation, transport
	reliability) required to sufficiently maintain the dynamic decoding		reliability) required to sufficiently maintain the dynamic decoding
	context. Therefore, this document requires that endpoints SHALL NOT		context. Therefore, this document requires that endpoints SHALL NOT
	use dynamic indexing. It is RECOMMENDED that endpoints use static		use dynamic table indexing. It is RECOMMENDED that endpoints use
	indexing and/or Huffman encoding in order to benefit from the		static table indexing and/or Huffman encoding in order to benefit
	remaining compression methods available.		from the remaining compression methods available.
	5.4. Session Tear-down		5.4. Session Tear-down
	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
	skipping to change at page 24, line 33 ¶		skipping to change at page 24, line 37 ¶
	5.5. HTTP/3 Extension frames		5.5. HTTP/3 Extension frames
	HTTP/3 extension frames (e.g. "ALTSVC") are prohibited by this		HTTP/3 extension frames (e.g. "ALTSVC") are prohibited by this
	profile. Participants MUST NOT make any attempt to send extension		profile. Participants MUST NOT make any attempt to send extension
	frame types. Reception of these MUST be handled as described in		frame types. Reception of these MUST be handled as described in
	Section 5.6.		Section 5.6.
	5.6. Prohibited HTTP/3 Frames		5.6. 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:
	"DUPLICATE_PUSH", "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".
	Reception of a prohibited HTTP/3 frame is a protocol error.		Reception of a prohibited HTTP/3 frame is a protocol error.
	Receivers MUST ignore prohibited HTTP/3 frames.		Receivers MUST ignore prohibited HTTP/3 frames.
	skipping to change at page 30, line 14 ¶		skipping to change at page 30, line 22 ¶
	This document specifies the "source-address" parameter for Alt-Svc,		This document specifies the "source-address" parameter for Alt-Svc,
	which is used to provide the SSM source address to endpoints.		which is used to provide the SSM source address to endpoints.
	Syntax:		Syntax:
	source-address = uri-host; see RFC7230, Section 2.7		source-address = uri-host; see RFC7230, Section 2.7
	For example:		For example:
	source-address="192.0.2.1"		source-address=192.0.2.1
	When a multicast QUIC session is provided using SSM, the "source-		When a multicast QUIC session is provided using SSM, the "source-
	address" parameter MUST be advertised.		address" parameter MUST be advertised. If the parameter is repeated,
			the first occurrence MUST be used and subsequent occurrences MUST be
			ignored.
	10.2. Session Parameter Advertisement		10.2. Session Parameter Advertisement
	The concept of session parameters is introduced in Section 2.2. This		The concept of session parameters is introduced in Section 2.2. This
	section details how the session parameters are expressed as Alt-Svc		section details how the session parameters are expressed as Alt-Svc
	parameters.		parameters.
	10.2.1. Cipher Suite		10.2.1. Cipher Suite
	This document specifies the "cipher-suite" parameter for Alt-Svc,		This document specifies the "cipher-suite" parameter for Alt-Svc,
	skipping to change at page 31, line 40 ¶		skipping to change at page 32, line 4 ¶
	This document defines the "session-id" parameter for Alt-Svc, which		This document defines the "session-id" parameter for Alt-Svc, which
	carries the multicast QUIC session identifier.		carries the multicast QUIC session identifier.
	Syntax:		Syntax:
	session-id = *HEXDIG		session-id = *HEXDIG
	For example, the following specifies session 101 (0x65 hexadecimal):		For example, the following specifies session 101 (0x65 hexadecimal):
	session-id=65		session-id=65
	The requirements for endpoint usage of "session-id" are described in		The requirements for endpoint usage of "session-id" are described in
	Section 2.3. In the above example, the Destination Connection ID		Section 2.3. In the above example, the Destination Connection ID
	field in every QUIC packet header would be one byte in size. For a		field in every QUIC packet header would be one byte in size. For a
	session-id of BADBEEF then then Destintation Connection ID field in		session-id of BADBEEF then then Destintation Connection ID field in
	every QUIC packet header would be four bytes in size.		every QUIC packet header would be four bytes in size.
	10.2.5. Session Idle Timeout Period		10.2.5. Session Idle Timeout Period
	This document specifies the "session-idle-timeout" parameter for Alt-		This document specifies the "session-idle-timeout" parameter for Alt-
	Svc, which carries the idle timeout period of a multicast QUIC		Svc, which carries the idle timeout period in milliseconds of a
	session.		multicast QUIC session.
	Syntax:		Syntax:
	session-idle-timeout = *DIGIT ; number of seconds between 0 and 600		session-idle-timeout = *DIGIT ; integer milliseconds
	For example, the following specifies a one-minute session idle		For example, the following specifies a one-minute session idle
	timeout period:		timeout period:
	session-idle-timeout=60		session-idle-timeout=60
	The requirements for endpoint usage of "session-idle-timeout" are		The requirements for endpoint usage of "session-idle-timeout" are
	described in Section 3.3.		described in Section 3.3.
	10.2.6. Resource Concurrency		10.2.6. Resource Concurrency
	skipping to change at page 33, line 41 ¶		skipping to change at page 34, line 4 ¶
	(http://www.iana.org/assignments/signature-algorithms).		(http://www.iana.org/assignments/signature-algorithms).
	Syntax:		Syntax:
	signature-algorithm = token		signature-algorithm = token
	For example, the following specifies a signature algorithm of SHA-		For example, the following specifies a signature algorithm of SHA-
	256:		256:
	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.2) 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		extensions = DQUOTE ext-transport-param *[ "," ext-transport-param ] DQUOTE
	*[ "," ext-transport-param ] DQUOTE		ext-transport-param = ext-key [ "=" ext-value ]
	ext-transport-param = ext-key [ "=" ext-value ]		ext-key = 4*4HEXDIG; Transport Parameter key
	ext-key = 4*4HEXDIG; Transport Parameter key		ext-value = *HEXDIG; Optional Transport Parameter value
	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 and Privacy Considerations
	skipping to change at page 39, line 4 ¶		skipping to change at page 39, line 18 ¶
	This document creates a new registration for the identification of		This document creates a new registration for the identification of
	the HTTP over multicast QUIC protocol in the "Application-Layer		the HTTP over multicast QUIC protocol in the "Application-Layer
	Protocol Negotiation (ALPN) Protocol IDs" registry established by		Protocol Negotiation (ALPN) Protocol IDs" registry established by
	[RFC7301].		[RFC7301].
	The "h3m" string identifies HTTP semantics expressed as HTTP mapped		The "h3m" string identifies HTTP semantics expressed as HTTP mapped
	to a QUIC layer and carried over IP multicast:		to a QUIC layer and carried over IP multicast:
	Protocol: Bulk data transport using HTTP over multicast QUIC		Protocol: Bulk data transport using HTTP over multicast QUIC
	Identification Sequence: 0x68 0x71 0x6D ("h3m")
			Identification Sequence: 0x68 0x33 0x6D ("h3m")
	Specification: This document, Section 9		Specification: This document, Section 9
	This entry reserves an identifier that is not allowed to appear in		This entry reserves an identifier that is not allowed to appear in
	TLS Application-Layer Protocol Negotiation.		TLS Application-Layer Protocol Negotiation.
	12.2. Registration of Alt-Svc parameters		12.2. Registration of Alt-Svc parameters
	This document creates seven registrations for the identification of		This document creates seven registrations for the identification of
	parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc		parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc
	skipping to change at page 40, line 52 ¶		skipping to change at page 41, line 16 ¶
	13.1. Normative References		13.1. Normative References
	[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-25 (work in progress).		(HTTP/3)", draft-ietf-quic-http-29 (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-12 (work in progress).		ietf-quic-qpack-16 (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-25 (work in progress).		transport-29 (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 26 ¶		skipping to change at page 42, line 41 ¶
	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-25 (work		and Congestion Control", draft-ietf-quic-recovery-29 (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-22 (work in progress).		tls-29 (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 52, line 52 ¶		skipping to change at page 52, line 52 ¶
	| | | session optionally |		| | | session optionally |
	| | | advertised out of |		| | | advertised out of |
	| | | band via Alt-Svc |		| | | band via Alt-Svc |
	| | | "max-concurrent- |		| | | "max-concurrent- |
	| | | resources" |		| | | resources" |
	| | | parameter. |		| | | parameter. |
	+----------------------------+----------------+---------------------+		+----------------------------+----------------+---------------------+
	Table 2: Required Transport Parameters		Table 2: Required Transport Parameters
	+-------------------------+------------------+----------------------+		+------------------------------+---------------+--------------------+
	| Protocol feature | Unicast QUIC | Multicast QUIC |		| Protocol feature | Unicast QUIC | Multicast QUIC |
	| | | profile |		| | | profile |
	+-------------------------+------------------+----------------------+		+------------------------------+---------------+--------------------+
	| "original_connection_id | The value of the | Not used. No client |		| "original_destination_connec | The value of | Not used. No |
	| " | Destination | interaction. |		| tion_id" | the | client |
	| | Connection ID | |		| | Destination | interaction. |
	| | field from the | |		| | Connection ID | |
	| | first Initial | |		| | field from | |
	| | packet sent by | |		| | the first | |
	| | the client. | |		| | Initial | |
	| | | |		| | packet sent | |
	| "max_idle_timeout" | How long to keep | Not used. Advertised |		| | by the | |
	| | an idle | out of band via Alt- |		| | client. | |
	| | connection open | Svc "session-idle- |		| | | |
	| | for before | timeout" parameter; |		| "max_idle_timeout" | How long to | Not used. |
	| | closing. Takes a | defaults to 0 (never |		| | keep an idle | Advertised out of |
	| | default of 0 | close on idle) if |		| | connection | band via Alt-Svc |
	| | (never close on | not specified. |		| | open for | "session-idle- |
	| | idle) if not | |		| | before | timeout" |
	| | specified. | |		| | closing. | parameter; |
	| | | |		| | Takes a | defaults to 0 |
	| "stateless_reset_token" | Used in | Not used. Stateless |		| | default of 0 | (never close on |
	| | verifying a | reset is not used by |		| | (never close | idle) if not |
	| | stateless reset. | this profile. |		| | on idle) if | specified. |
	| | | |		| | not | |
	| "max_packet_size" | Limit of the | Not used. Maximum |		| | specified. | |
	| | size of packets | packet size for a |		| | | |
	| | that an endpoint | session optionally |		| "stateless_reset_token" | Used in | Not used. |
	| | is willing to | advertised out of |		| | verifying a | Stateless reset is |
	| | receive. | band via Alt-Svc |		| | stateless | not used by this |
	| | | "max-packet-size" |		| | reset. | profile. |
	| | | parameter. |		| | | |
	| | | |		| "max_udp_payload_size" | Limit of the | Not used. Maximum |
	| "ack_delay_exponent" | The exponent | Not used. "ACK" |		| | size of | packet size for a |
	| | used to decode | frames are |		| | packets that | session optionally |
	| | the ACK Delay | prohibited by this |		| | an endpoint | advertised out of |
	| | field in the | profile. |		| | is willing to | band via Alt-Svc |
	| | "ACK" frame. | |		| | receive. | "max-packet-size" |
	| | | |		| | | parameter. |
	| "max_ack_delay" | Maximum time in | Not used. "ACK" |		| | | |
	| | milliseconds by | frames are |		| "ack_delay_exponent" | The exponent | Not used. "ACK" |
	| | which an | prohibited by this |		| | used to | frames are |
	| | endpoint will | profile. |		| | decode the | prohibited by this |
	| | delay sending ac | |		| | ACK Delay | profile. |
	| | knowledgements. | |		| | field in the | |
	| | | |		| | "ACK" frame. | |
	| "disable_active_migrati | Signals if an | Not used. Session |		| | | |
	| on" | endpoint does | migration not |		| "max_ack_delay" | Maximum time | Not used. "ACK" |
	| | not support | currently supported |		| | in | frames are |
	| | connection | by this profile. |		| | milliseconds | prohibited by this |
	| | migration. | |		| | by which an | profile. |
	| | | |		| | endpoint will | |
	| "preferred_address" | Used to effect a | Not used. No |		| | delay sending | |
	| | change in server | handshake in this |		| | acknowledgeme | |
	| | address at the | profile. |		| | nts. | |
	| | end of the | |		| | | |
	| | handshake. | |		| "disable_active_migration" | Signals if an | Not used. Session |
	+-------------------------+------------------+----------------------+		| | endpoint does | migration not |
			| | not support | currently |
			| | connection | supported by this |
			| | migration. | profile. |
			| | | |
			| "preferred_address" | Used to | Not used. No |
			| | effect a | handshake in this |
			| | change in | profile. |
			| | server | |
			| | address at | |
			| | the end of | |
			| | the | |
			| | handshake. | |
			| | | |
			| "active_connection_id_limit" | | Not used. Only a |
			| | | single session |
			| | | identifier is used |
			| | | in this profile. |
			| | | |
			| "initial_source_connection_i | The value | Not used. No |
			| d" | that an | client |
			| | endpoint | interaction. |
			| | included in | |
			| | the Source | |
			| | Connection ID | |
			| | field of the | |
			| | first Initial | |
			| | packet it | |
			| | sent for the | |
			| | connection | |
			| | | |
			| "retry_source_connection_id" | The value | Not used. Retry |
			| | that the | packets are not |
			| | server | used in this |
			| | included in | profile. |
			| | the Source | |
			| | Connection ID | |
			| | field of a | |
			| | retry packet | |
			+------------------------------+---------------+--------------------+
	Table 3: Optional Transport Parameters		Table 3: Optional Transport Parameters
	+-------------+---------------------+-------------------------------+		+-------------+---------------------+-------------------------------+
	| Protocol | Unicast QUIC | Multicast QUIC profile |		| Protocol | Unicast QUIC | Multicast QUIC profile |
	| feature | | |		| feature | | |
	+-------------+---------------------+-------------------------------+		+-------------+---------------------+-------------------------------+
	| Maximum | Determined by path | Determined by path MTU |		| Maximum | Determined by path | Determined by path MTU |
	| packet size | MTU discovery or | discovery or other heuristic. |		| packet size | MTU discovery or | discovery or other heuristic. |
	| | other heuristic. | |		| | other heuristic. | |
	skipping to change at page 55, line 40 ¶		skipping to change at page 56, line 31 ¶
	| | the network can | |		| | the network can | |
	| | transmit packets of | |		| | transmit packets of | |
	| | at least this size.) | |		| | at least this size.) | |
	| | | |		| | | |
	| "PING" frame | Used by an endpoint | Used by the |		| "PING" frame | Used by an endpoint | Used by the |
	| | to verify that its | multicast sender as |		| | to verify that its | multicast sender as |
	| | peer is still alive. | a session keep- |		| | peer is still alive. | a session keep- |
	| | Acknowledged using a | alive notification. |		| | Acknowledged using a | alive notification. |
	| | regular "ACK" frame. | Never acknowledged. |		| | regular "ACK" frame. | Never acknowledged. |
	| | | |		| | | |
	| "ACK" frame | Used by a receiver | Both "ACK" frame |		| "ACK" frames | Used by a receiver | Both "ACK" frame |
	| | to acknowledge | types are |		| | to acknowledge | types are |
	| | receipt of data from | prohibited. |		| | receipt of data from | prohibited. |
	| | its peer. | |		| | its peer. | |
	| | | |		| | | |
	| "RESET_STREAM" frame | Request by receiver | Indication to |		| "RESET_STREAM" frame | Request by receiver | Indication to |
	| | for sender to | receivers that the |		| | for sender to | receivers that the |
	| | terminate a stream | multicast sender |		| | terminate a stream | multicast sender |
	| | transmission | has prematurely |		| | transmission | has prematurely |
	| | prematurely. | terminated a stream |		| | prematurely. | terminated a stream |
	| | | transmission. |		| | | transmission. |
	skipping to change at page 58, line 31 ¶		skipping to change at page 59, line 22 ¶
	| | | |		| | | |
	| "HANDSHAKE_DONE" frame | Used by a server to | Prohibited. |		| "HANDSHAKE_DONE" frame | Used by a server to | Prohibited. |
	| | inform a client that | |		| | inform a client that | |
	| | the cryptographic | |		| | the cryptographic | |
	| | handshake has | |		| | handshake has | |
	| | completed. | |		| | completed. | |
	+------------------------+----------------------+---------------------+		+------------------------+----------------------+---------------------+
	Table 5: QUIC Framing Layer		Table 5: QUIC Framing Layer
	+------------------+------------------+-----------------------------+		+----------------+------------------+-------------------------------+
	| Protocol feature | Unicast HTTP/3 | Multicast HTTP/3 profile |		| Protocol | Unicast HTTP/3 | Multicast HTTP/3 profile |
	+------------------+------------------+-----------------------------+		| feature | | |
	| Stream Type | Type of | Only Server Push type is |		+----------------+------------------+-------------------------------+
	| | unidirectional | permitted. |		| Stream Type | Type of | Only Server Push type is |
	| | stream. | |		| | unidirectional | permitted. |
	| | | |		| | stream. | |
	| Push ID | Identifies a | Identifies a promised |		| | | |
	| | promised | resource conveyed in an |		| Push ID | Identifies a | Identifies a promised |
	| | resource | earlier "PUSH_PROMISE" |		| | promised | resource conveyed in an |
	| | conveyed in an | frame. |		| | resource | earlier "PUSH_PROMISE" frame. |
	| | earlier | |		| | conveyed in an | |
	| | "PUSH_PROMISE" | |		| | earlier | |
	| | frame. | |		| | "PUSH_PROMISE" | |
	| | | |		| | frame. | |
	| "DATA" frame | Carriage of HTTP | Carriage of HTTP response |		| | | |
	| | request/response | message body. |		| "DATA" frame | Carriage of HTTP | Carriage of HTTP response |
	| | message body. | |		| | request/response | message body. |
	| | | |		| | message body. | |
	| "HEADERS" frame | Carriage of HTTP | Carriage of HTTP response |		| | | |
	| | request/response | message metadata. Trailing |		| "HEADERS" | Carriage of HTTP | Carriage of HTTP response |
	| | message | "HEADERS" frame is |		| frame | request/response | message metadata. Trailing |
	| | metadata. | permitted. |		| | message | "HEADERS" frame is permitted. |
	| | Trailing | |		| | metadata. | |
	| | "HEADERS" frame | |		| | Trailing | |
	| | is permitted. | |		| | "HEADERS" frame | |
	| | | |		| | is permitted. | |
	| "CANCEL_PUSH" | Used to request | Permitted only for senders. |		| | | |
	| frame | cancellation of | |		| "CANCEL_PUSH" | Used to request | Permitted only for senders. |
	| | server push | |		| frame | cancellation of | |
	| | prior to the | |		| | server push | |
	| | push stream | |		| | prior to the | |
	| | being created. | |		| | push stream | |
	| | | |		| | being created. | |
	| "SETTINGS" frame | Negotiation of | Prohibited. |		| | | |
	| | HTTP/3 | |		| "SETTINGS" | Negotiation of | Prohibited. |
	| | connection | |		| frame | HTTP/3 | |
	| | settings. | |		| | connection | |
	| | | |		| | settings. | |
	| "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- |		| | | |
	| frame | pseudo-request | request message metadata. |		| "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- |
	| | message | All HTTP representation |		| frame | pseudo-request | request message metadata. All |
	| | metadata. | transfers over multicast |		| | message | HTTP representation transfers |
	| | | begin this way. Stream ID |		| | metadata. | over multicast begin this |
	| | | of the first client- |		| | | way. Stream ID of the first |
	| | | initiated bidirectional |		| | | client-initiated |
	| | | stream is reserved and all |		| | | bidirectional stream is |
	| | | "PUSH_PROMISE" frames |		| | | reserved and all |
	| | | reference this as the |		| | | "PUSH_PROMISE" frames |
	| | | client request from which |		| | | reference this as the client |
	| | | they are notionally |		| | | request from which they are |
	| | | derived. This stream |		| | | notionally derived. This |
	| | | remains open while a sender |		| | | stream remains open while a |
	| | | is participating in the |		| | | sender is participating in |
	| | | multicast QUIC session. |		| | | the multicast QUIC session. |
	| | | |		| | | |
	| "GOAWAY" frame | Early | Prohibited. Use HTTP |		| "GOAWAY" frame | Early | Prohibited. Use HTTP explicit |
	| | notification (by | explicit session tear-down |		| | notification (by | session tear-down instead. |
	| | either endpoint) | instead. |		| | either endpoint) | |
	| | of future | |		| | of future | |
	| | connection | |		| | connection | |
	| | closure, | |		| | closure, | |
	| | allowing for | |		| | allowing for | |
	| | orderly | |		| | orderly | |
	| | completion of | |		| | completion of | |
	| | open streams. | |		| | open streams. | |
	| | | |		| | | |
	| "MAX_PUSH_ID" | Used by a | Prohibited. |		| "MAX_PUSH_ID" | Used by a | Prohibited. |
	| frame | receiver to | |		| frame | receiver to | |
	| | control the | |		| | control the | |
	| | number of server | |		| | number of server | |
	| | pushes that a | |		| | pushes that a | |
	| | sender can | |		| | sender can | |
	| | initiate. | |		| | initiate. | |
	| | | |		| | | |
	| "DUPLICATE_PUSH" | Used by servers | Prohibited. |		| "ALTSVC" | Signalling | Prohibited. |
	| frame | to indicate that | |		| HTTP/2 | alternative | |
	| | an existing | |		| extension | service for | |
	| | pushed resource | |		| frame | HTTP/3 session. | |
	| | is related to | |		| | | |
	| | multiple client | |		| Other HTTP/2 | | Prohibited. |
	| | requests. | |		| extension | | |
	| | | |		| frames | | |
	| "ALTSVC" HTTP/2 | Signalling | Prohibited. |		+----------------+------------------+-------------------------------+
	| extension frame | alternative | |
	| | service for | |
	| | HTTP/3 session. | |
	| | | |
	| Other HTTP/2 | | Prohibited. |
	| extension frames | | |
	+------------------+------------------+-----------------------------+
	Table 6: HTTP/3 Mapping		Table 6: HTTP/3 Mapping
	+-------------+----------------------------------+------------------+		+-------------+----------------------------------+------------------+
	| Protocol | Unicast HTTP/3 | Multicast HTTP/3 |		| Protocol | Unicast HTTP/3 | Multicast HTTP/3 |
	| feature | | profile |		| feature | | profile |
	+-------------+----------------------------------+------------------+		+-------------+----------------------------------+------------------+
	| Huffman | Header blocks may use Huffman | Header blocks |		| Huffman | Header blocks may use Huffman | Header blocks |
	| string | codes to compress literal string | may use Huffman |		| string | codes to compress literal string | may use Huffman |
	| compression | values. | codes to |		| compression | values. | codes to |
	skipping to change at page 61, line 36 ¶		skipping to change at page 61, 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-05		D.1. Since draft-pardue-quic-http-mcast-06
			o Update references to QUIC I-Ds.
			o Clarify that only the first source-address parameter should be
			used if duplicated.
			o Fix source-address example to not be a quoted string.
			o Fix bytes in the ALPN identification sequence following change to
			h3m.
			o Update language around QUIC Connection IDs to reflect the core
			specs.
			o Update frame and transport parameter names throughout to match
			core specifications.
			o Remove Author's Note about reserved stream ID for "PUSH_PROMISE"
			frames.
			o Update language around QPACK static and dynamic table indexing to
			more closely align with the core spec.
			o Update Session Idle Timeout to match core specs, including
			removing limitation of 600 seconds and expressing in milliseconds,
			not seconds.
			o Preface Session Termination with a statement clarifying that
			participants may leave at any time.
			D.2. Since draft-pardue-quic-http-mcast-05
	o Update references to QUIC I-Ds.		o Update references to QUIC 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
	skipping to change at page 62, line 14 ¶		skipping to change at page 63, line 5 ¶
	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.2. Since draft-pardue-quic-http-mcast-04		D.3. Since draft-pardue-quic-http-mcast-04
	o Update references to QUIC I-Ds, remove QUIC-SPIN. (draft-ietf-		o Update references to QUIC 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)
	skipping to change at page 62, line 46 ¶		skipping to change at page 63, line 37 ¶
	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.3. Since draft-pardue-quic-http-mcast-03		D.4. Since draft-pardue-quic-http-mcast-03
	o Update references to QUIC I-Ds.		o Update references to QUIC 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.
	skipping to change at page 63, line 30 ¶		skipping to change at page 64, line 20 ¶
	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.4. Since draft-pardue-quic-http-mcast-02		D.5. Since draft-pardue-quic-http-mcast-02
	o No changes.		o No changes.
	D.5. Since draft-pardue-quic-http-mcast-01		D.6. 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 10 ¶		skipping to change at page 64, line 48 ¶
	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.6. Since draft-pardue-quic-http-mcast-00		D.7. Since draft-pardue-quic-http-mcast-00
	o Update references to QUIC I-Ds.		o Update references to QUIC 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.
End of changes. 54 change blocks.
	239 lines changed or deleted		304 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/