< draft-pardue-quic-http-mcast-04.txt   draft-pardue-quic-http-mcast-05.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 9, 2019 S. Hurst Expires: February 9, 2020 S. Hurst
BBC Research & Development BBC Research & Development
February 5, 2019 August 8, 2019
Hypertext Transfer Protocol (HTTP) over multicast QUIC Hypertext Transfer Protocol (HTTP) over multicast QUIC
draft-pardue-quic-http-mcast-04 draft-pardue-quic-http-mcast-05
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 9, 2019. This Internet-Draft will expire on February 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 43 skipping to change at page 2, line 43
3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 17 3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 17
4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 18 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Packet Numbers . . . . . . . . . . . . . . . . . . . 18 4.2.1. Packet Numbers . . . . . . . . . . . . . . . . . . . 18
4.2.2. Spin Bit . . . . . . . . . . . . . . . . . . . . . . 19 4.2.2. Spin Bit . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 19 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 19
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. Session 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 . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . 22
5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 23 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 23
5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 24 5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 24
5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24 5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24
5.6. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24 5.6. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24
5.7. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24 5.7. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24
6. Application-Layer Security . . . . . . . . . . . . . . . . . 24 6. Application-Layer Security . . . . . . . . . . . . . . . . . 25
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. Version . . . . . . . . . . . . . . . . . . . . . . 30 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 30
10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30 10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30
10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 31 10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 31
10.2.4. Session Cipher Initialization Vector . . . . . . . . 31 10.2.4. Session Cipher Initialization Vector . . . . . . . . 31
10.2.5. Session Identification . . . . . . . . . . . . . . . 31 10.2.5. Session Identification . . . . . . . . . . . . . . . 31
10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 32 10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 32
10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 32 10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 32
10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 32 10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 33
10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 33 10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 33
10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 33 10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 33
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 . . . . . 34 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 . . . . . . . . . . . . . . . . . . . . . . . . 35 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 36
11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 35 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 36
11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . . . 36 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 37
11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . 37
11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 37 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 38
11.8. Unicast Repair Information Leakage . . . . . . . . . . . 37 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 38
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.1. Registration of Protocol Identification String . . . . . 38 12.1. Registration of Protocol Identification String . . . . . 38
12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 38 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 . . . . . . . . . . . . . . . 39
12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 39 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 39
12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 39 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 40
12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 39 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
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . 40 13.1. Normative References . . . . . . . . . . . . . . . . . . 40
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 . . . . . . . 44
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 . . . . . . . . . . 44 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 . . . . . . . . . . . . . . . . . . . . 45 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 . . . . . . . . . . . . . . . . . . . . 47
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 . . . . . . . . . . . . . . . . . . . . . 60 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 61
D.1. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 60 D.1. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 61
D.2. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 60 D.2. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 61
D.3. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 60 D.3. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 62
D.4. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 61 D.4. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 D.5. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
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 5, line 36 skipping to change at page 5, line 38
summarised in Appendix C. summarised in Appendix C.
This profile prohibits the transmission of QUIC packets from receiver This profile prohibits the transmission of QUIC packets from receiver
to sender via multicast IP. The use of side-channel or out-of-band to sender via multicast IP. The use of side-channel or out-of-band
feedback mechanisms is not prohibited by this specification, but is feedback mechanisms is not prohibited by this specification, but is
out of scope and these are not considered further by the present out of scope and these are not considered further by the present
document. document.
Experience indicates that a generally available multicast deployment Experience indicates that a generally available multicast deployment
is difficult to achieve on the Internet notwithstanding the is difficult to achieve on the Internet notwithstanding the
improvements that IPv6 [RFC2460] makes in this area. There is improvements that IPv6 [RFC8200] makes in this area. There is
evidence that discretely referenced multicast "islands" can more evidence that discretely referenced multicast "islands" can more
pragmatically be deployed. Discovery of such islands by receivers, pragmatically be deployed. Discovery of such islands by receivers,
as they become available, is typically difficult, however. To as they become available, is typically difficult, however. To
address the problem, this document describes an HTTP-based discovery address the problem, this document describes an HTTP-based discovery
mechanism that uses HTTP Alternative Services [RFC7838] to advertise mechanism that uses HTTP Alternative Services [RFC7838] to advertise
the existence of multicast QUIC sessions (Section 3). This provides the existence of multicast QUIC sessions (Section 3). This provides
the means for multicast-capable endpoints to learn about and make use the means for multicast-capable endpoints to learn about and make use
of them in an opportunistic and user-imperceptible manner. This of them in an opportunistic and user-imperceptible manner. This
mechanism results in a common HTTP application layer for both the mechanism results in a common HTTP application layer for both the
discovery and delivery of services across unicast and multicast discovery and delivery of services across unicast and multicast
skipping to change at page 10, line 38 skipping to change at page 10, line 38
This document defines an optional session identifier used to identify This document defines an optional session identifier used to identify
a session. This "Session ID" affords independence from multicast IP, a session. This "Session ID" affords independence from multicast IP,
creating the possibility for a session to span multiple multicast creating the possibility for a session to span multiple multicast
groups, or to migrate a session to a different multicast group. groups, or to migrate a session to a different multicast group.
Assignment of Session ID is considered out of this document's scope. Assignment of Session ID is considered out of this document's scope.
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 144 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.5). If no "session-id" parameter is advertised, then (Section 10.2.5). If no "session-id" parameter is advertised, then
this session has no explicit session ID, and the Destination this session has no explicit 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
skipping to change at page 12, line 30 skipping to change at page 12, line 30
Senders MAY also advertise the availability of alternative sessions Senders MAY also advertise the availability of alternative sessions
by carrying Alt-Svc in a multicast QUIC session. by carrying Alt-Svc in a multicast QUIC session.
3.1. Version Advertisement 3.1. Version Advertisement
*Authors' Note:* Version negotiation (as described in WG *Authors' Note:* Version negotiation (as described in WG
documents) is in flux. This section will track developments and documents) is in flux. This section will track developments and
will be updated accordingly. will be updated accordingly.
Conventional QUIC connection establishment begins with version Conventional QUIC has a concept of version negotiation. To start a
session, a client selects a version number and sends a packet to
initiate the connection. On receipt, if the server identifies that
it does not support that version then it may begin version
negotiation. In a unidirectional multicast environment, there is no negotiation. In a unidirectional multicast environment, there is no
reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an
Alt-Svc "quic" parameter that can be advertised to clients for use as Alt-Svc "quic" parameter that can be advertised to clients for use as
a version negotiation hint. This specification uses "quic" as a a version negotiation hint. This specification uses "quic" as a
session parameter for a similar purpose. This mechanism replaces the session parameter for a similar purpose. This mechanism replaces the
use of the Version field in the QUIC packet long header (see use of the Version field in the QUIC packet long header (see
Section 4.2). Section 4.2).
The Alt-Svc "quic" parameter is mandatory. Session advertisements The Alt-Svc "quic" parameter is mandatory. Session advertisements
MUST contain exactly one instance of it and it MUST NOT be repeated. MUST contain exactly one instance of it and it MUST NOT be repeated.
skipping to change at page 19, line 13 skipping to change at page 19, line 13
data packet number space. The initial and handshake packet number data packet number space. The initial and handshake packet number
spaces are not used by this profile, as the handshake is replaced by spaces are not used by this profile, as the handshake is replaced by
an out-of-band mechanism (see Section 2.4). an out-of-band mechanism (see Section 2.4).
Because a recevier may join a session after the sender has already Because a recevier may join a session after the sender has already
sent several packets, it MUST NOT assume that the first packet number sent several packets, it MUST NOT assume that the first packet number
will be 0. will be 0.
4.2.2. Spin Bit 4.2.2. Spin Bit
[QUIC-TRANSPORT] reserves a bit in the short packet header for the [QUIC-TRANSPORT] specifies a bit in the short packet header as the
latency spin bit [QUIC-SPIN] that may be used to measure network latency spin bit that may be used to measure network round trip
round trip latency between a client and a server. This mechanism is latency between a client and a server. This mechanism is not usable
not usable in a unidirectional multicast packet flow. Senders SHALL in a unidirectional multicast packet flow. Senders SHALL set the
set the spin bit to zero in all packets. Receivers SHOULD ignore the spin bit to zero in all packets. Receivers SHOULD ignore the spin
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 present in every QUIC
packet if the session was advertised with a "session-id" session packet if the session was advertised with a "session-id" session
parameter (Section 10.2.5). If there is no Session ID session parameter (Section 10.2.5). If there is no Session ID session
parameter, then the Destination Connection ID MUST NOT be present in parameter, then the Destination Connection ID MUST NOT be present in
skipping to change at page 20, line 21 skipping to change at page 20, line 21
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. Session 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 "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the
Stateless Reset packet are prohibited. Participants MUST NOT send Stateless Reset packet are prohibited. Participants MUST NOT send
these and reception MUST be handled as described in Section 4.12. these and reception MUST be handled as described in Section 4.12.
The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send
this and reception MUST be handled as described in Section 5.7.
*Author's Note*: Richard: Should the above be moved to the HTTP/3
profile section? (REMOVE BEFORE PUBLISHING)
Explicit session tear-down using HTTP semantics is allowed, as Explicit session tear-down using HTTP semantics is allowed, as
described in Section 5.5. described in Section 5.5.
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.4. described in Section 3.4.
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
connection to survive changes to endpoint addresses. This profile connection to survive changes to endpoint addresses. This profile
does not currently support connection migration, and as such the does not currently support connection migration, and as such the QUIC
"NEW_CONNECTION_ID" and "RETIRE_CONNECTION_ID" frames are prohibited. "NEW_CONNECTION_ID" and "RETIRE_CONNECTION_ID" frames are prohibited.
Similarly, the "PATH_CHALLENGE" and "PATH_RESPONSE" frames are also Similarly, the QUIC "PATH_CHALLENGE" and "PATH_RESPONSE" frames are
prohibited, but additionally because they require bidirectional also prohibited, but additionally because they require bidirectional
capability that this profile does not provide. capability that this profile does not provide.
Endpoints participating in a session conforming to this profile
should only expect to use a single session ID for the duration of the
session, and as such there is no mapping for the
"active_connection_id_limit" transport parameter specified in section
5.1.1 of [QUIC-TRANSPORT] in this profile.
*Author's Note*: Seamless migration from one multicast QUIC
session to another is described in Section 2.1.3.
4.9. Explicit Congestion Notification 4.9. Explicit Congestion Notification
[QUIC-TRANSPORT] specifies that clients may use Explicit Congestion [QUIC-TRANSPORT] specifies that clients may use Explicit Congestion
Notification (ECN) [RFC3168]. ECN allows receivers to inform senders Notification (ECN) [RFC3168]. ECN allows receivers to inform senders
of impending congestion before packets are dropped, and the sender of impending congestion before packets are dropped, and the sender
may then reduce its transmission rate. As ECN requires bidirectional may then reduce its transmission rate. As ECN requires bidirectional
communication for the receiver to inform the sender of the communication for the receiver to inform the sender of the
congestion, the use of ECN for this profile is prohibited. congestion, the use of ECN for this profile is prohibited.
*Author's Note*: It is the responsibility of a receiver to *Author's Note*: It is the responsibility of a receiver to
skipping to change at page 23, line 13 skipping to change at page 23, line 23
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.6. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and Section 3.6. 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.7. Section 5.7.
When opening a stream for a new server-pushed resource, the first For this profile, the Stream Type for any new server-initiated
byte on the stream is the Stream Type. For this profile, the Stream unidirectional stream MUST be Server Push ("0x01").
Type for any new server-initiated unidirectional stream MUST be
Server Push ("P", "0x50").
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.
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
skipping to change at page 24, line 22 skipping to change at page 24, line 26
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
this and reception MUST be handled as described in Section 5.7.
5.6. HTTP/3 Extension frames 5.6. 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.7. Section 5.7.
5.7. Prohibited HTTP/3 Frames 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:
skipping to change at page 26, line 22 skipping to change at page 26, line 28
discard or ignore any related metadata and/or data without processing discard or ignore any related metadata and/or data without processing
it further. it further.
Note that the signature proves the authenticity of the metadata in a Note that the signature proves the authenticity of the metadata in a
single HTTP message. A "Signature" header MAY be included separately single HTTP message. A "Signature" header MAY be included separately
in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata) in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata)
and in the final (or only) HTTP/3 "HEADERS" frame relating to a and in the final (or only) HTTP/3 "HEADERS" frame relating to a
particular resource (protecting the response metadata). In order to particular resource (protecting the response metadata). In order to
provide an additional level of protection, however, it is RECOMMENDED provide an additional level of protection, however, it is RECOMMENDED
that the signature be computed over the combined request metadata that the signature be computed over the combined request metadata
(from the "PUSH_PROMISE" frame) and the corresponding response (from the HTTP/3 "PUSH_PROMISE" frame) and the corresponding response
metadata (from the HTTP/3 "HEADERS" frames) of the same resource. metadata (from the HTTP/3 "HEADERS" frames) of the same resource.
This binds the request metadata and response metadata together, This binds the request metadata and response metadata together,
providing the receiver with additional reassurance of authenticity. providing the receiver with additional reassurance of authenticity.
In this latter case, the combined digital signature SHALL be conveyed In this latter case, the combined digital signature SHALL be conveyed
in the final (or only) HTTP/3 "HEADERS" frame. in the final (or only) HTTP/3 "HEADERS" frame.
In applications where the detection of replay attacks is a In applications where the detection of replay attacks is a
requirement, it is RECOMMENDED that the "Date" header be included in requirement, it is RECOMMENDED that the "Date" header be included in
the scope of the signature. It is RECOMMENDED that receivers use the the scope of the signature. It is RECOMMENDED that receivers use the
value of the "Date" header for replay detection using appropriate value of the "Date" header for replay detection using appropriate
skipping to change at page 40, line 29 skipping to change at page 40, line 41
Parameter name: signature-algorithm Parameter name: signature-algorithm
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
[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-10 (work in progress), May 2018. cavage-http-signatures-11 (work in progress), April 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-18 (work in progress). (HTTP/3)", draft-ietf-quic-http-22 (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-06 (work in progress). ietf-quic-qpack-09 (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-18 (work in progress). transport-22 (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 13 skipping to change at page 42, line 21
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-18 (work and Congestion Control", draft-ietf-quic-recovery-22 (work
in progress). in progress).
[QUIC-SPIN]
Trammell, B., Ed. and M. Kuehlewind, "The QUIC Latency
Spin Bit", draft-ietf-quic-spin-exp-01 (work 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-18 (work in progress). tls-22 (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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <https://www.rfc-editor.org/info/rfc2974>. October 2000, <https://www.rfc-editor.org/info/rfc2974>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
skipping to change at page 44, line 9 skipping to change at page 44, line 9
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>. <https://www.rfc-editor.org/info/rfc7450>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank the following for their contributions The authors would like to thank the following for their contributions
to the design described in the present document: Brandon Butterworth, to the design described in the present document: Brandon Butterworth,
Chris Poole, Craig Taylor and David Waring. Chris Poole, Craig Taylor and David Waring.
We are also grateful to Thomas Swindells and Magnus Westerlund for We are also grateful to Thomas Swindells and Magnus Westerlund for
their helpful review comments. their helpful review comments.
Appendix B. Examples Appendix B. Examples
skipping to change at page 45, line 12 skipping to change at page 45, line 19
globally-scoped source-specific multicast group address ff3e::1234 on globally-scoped source-specific multicast group address ff3e::1234 on
port 2000 with the source address 2001:db8::1. The session ID is 16 port 2000 with the source address 2001:db8::1. The session ID is 16
(0x10) and the idle timeout is one minute. At most 10 resources may (0x10) and the idle timeout is one minute. At most 10 resources may
be concurrently active in the session and the flow rate should not be concurrently active in the session and the flow rate should not
exceed 10 kbits/s. The multicast transport is encrypted using the exceed 10 kbits/s. The multicast transport is encrypted using the
AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the
shared session key and IV provided. shared session key and IV provided.
HTTP Alternative Service header field: HTTP Alternative Service header field:
Alt-Svc: Alt-Svc:
hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1;
session-id=10; session-idle-timeout=60; session-id=10; session-idle-timeout=60;
max-concurrent-resources=10; peak-flow-rate=10000; max-concurrent-resources=10; peak-flow-rate=10000;
cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e cipher-suite=1301; key=4adf1eab9c2a37fd;
iv=4dbe593acb4d1577ad6ba7dc3189834e
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 Encryption, Content Integrity and Authenticity
Advertisement of a multicast QUIC session operating on the IPv6 Advertisement of a multicast QUIC session operating on the IPv6
globally-scoped source-specific multicast group address ff3e::1234 on globally-scoped source-specific multicast group address ff3e::1234 on
port 2000 with the source address 2001:db8::1. The session ID is 16 port 2000 with the source address 2001:db8::1. The session ID is 16
(0x10) and the idle timeout is one minute. At most 10 resources may (0x10) and the idle timeout is one minute. At most 10 resources may
be concurrently active in the session and the flow rate should not be concurrently active in the session and the flow rate should not
exceed 10 kbits/s. The multicast transport is encrypted using the exceed 10 kbits/s. The multicast transport is encrypted using the
AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the
shared session key and IV provided. Content integrity is in use with shared session key and IV provided. Content integrity is in use with
the digest algorithm set restricted to SHA-256. Content authenticity the digest algorithm set restricted to SHA-256. Content authenticity
is in use with the signature algorithm set restricted to rsa-sha256. is in use with the signature algorithm set restricted to rsa-sha256.
HTTP Alternative Service header field: HTTP Alternative Service header field:
Alt-Svc: Alt-Svc:
hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1;
session-id=10; session-idle-timeout=60; session-id=10; session-idle-timeout=60;
max-concurrent-resources=10; peak-flow-rate=10000; max-concurrent-resources=10; peak-flow-rate=10000;
cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e cipher-suite=1301; key=4adf1eab9c2a37fd;
digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 iv=4dbe593acb4d1577ad6ba7dc3189834e;
digest-algorithm=SHA-256; signature-algorithm=rsa-sha256
B.2. Resource Transfer B.2. Resource Transfer
This section shows several different examples of the HTTP message This section shows several different examples of the HTTP message
patterns for a single resource. patterns for a single resource.
Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe
the contents of enclosed header block fragments. the contents of enclosed header block fragments.
B.2.1. Transfer without Content Integrity or Authenticity B.2.1. Transfer without Content Integrity or Authenticity
skipping to change at page 60, line 10 skipping to change at page 61, line 10
| | 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-03 D.1. Since draft-pardue-quic-http-mcast-04
o Update references to QUIC I-Ds, remove QUIC-SPIN. (draft-ietf-
quic-transport-20)
o Update session ID length to match new connection ID length.
(draft-ietf-quic-transport-22)
o Clarify the mapping for the new "active_connection_id_limit"
session parameter. (draft-ietf-quic-transport-21)
o Update text to conform with latest version negotiation text from
[QUIC-TRANSPORT].
o Update stream types for server push in accordance with draft-ietf-
quic-http-19.
o Fix some idnits warnings to do with line lengths in Alt-Svc
examples.
o Update IPv6 informative reference to RFC 8200 as it obsoletes RFC
2460.
o Clarify difference between connection and session migration.
o Move GOAWAY frame to HTTP/3 profile.
o Renamed Session Shutdown to Connection Shutdown to mirror concept
in [QUIC-TRANSPORT].
o Clarify the layer of each frame type when referred to.
D.2. 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.
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.
o Remove references to the PONG frame (draft-ietf-quic-transport-10) o Remove references to the PONG frame. (draft-ietf-quic-transport-
10)
o Change HTTP/QUIC to HTTP/3 (draft-ietf-quic-http-17) o Change HTTP/QUIC to HTTP/3. (draft-ietf-quic-http-17)
o Change HPACK to QPACK (draft-ietf-quic-http-10) o Change HPACK to QPACK. (draft-ietf-quic-http-10)
o Prohibit the DUPLICATE_PUSH frame o Prohibit the DUPLICATE_PUSH frame.
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.2. Since draft-pardue-quic-http-mcast-02 D.3. Since draft-pardue-quic-http-mcast-02
o No changes. o No changes.
D.3. Since draft-pardue-quic-http-mcast-01 D.4. 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 61, line 21 skipping to change at page 63, line 5
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.4. Since draft-pardue-quic-http-mcast-00 D.5. 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. 
90 lines changed or deleted 130 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/