draft-ietf-quic-http-02.txt   draft-ietf-quic-http-03.txt 
QUIC M. Bishop, Ed. QUIC M. Bishop, Ed.
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track March 13, 2017 Intended status: Standards Track May 21, 2017
Expires: September 14, 2017 Expires: November 22, 2017
Hypertext Transfer Protocol (HTTP) over QUIC Hypertext Transfer Protocol (HTTP) over QUIC
draft-ietf-quic-http-02 draft-ietf-quic-http-03
Abstract Abstract
The QUIC transport protocol has several features that are desirable The QUIC transport protocol has several features that are desirable
in a transport for HTTP, such as stream multiplexing, per-stream flow in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC. This document also describes a mapping of HTTP semantics over QUIC. This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to QUIC. how HTTP/2 extensions can be ported to QUIC.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 14, 2017. This Internet-Draft will expire on November 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. QUIC Advertisement . . . . . . . . . . . . . . . . . . . . . 3 2. QUIC Advertisement . . . . . . . . . . . . . . . . . . . . . 3
2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . . . 4 2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . . . 4
3. Connection Establishment . . . . . . . . . . . . . . . . . . 4 3. Connection Establishment . . . . . . . . . . . . . . . . . . 4
3.1. Draft Version Identification . . . . . . . . . . . . . . 5 3.1. Draft Version Identification . . . . . . . . . . . . . . 5
4. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 5 4. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 5
4.1. Stream 3: Connection Control Stream . . . . . . . . . . . 6 4.1. Stream 1: Connection Control Stream . . . . . . . . . . . 6
4.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 6 4.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 6
4.2.1. Header Compression . . . . . . . . . . . . . . . . . 7 4.2.1. Header Compression . . . . . . . . . . . . . . . . . 7
4.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 8 4.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 8
4.3. Stream Priorities . . . . . . . . . . . . . . . . . . . . 9 4.3. Stream Priorities . . . . . . . . . . . . . . . . . . . . 9
4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9
5. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10 5. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10
5.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 10 5.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 10
5.2.1. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 11 5.2.2. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 11 skipping to change at page 3, line 11
9.1. Registration of HTTP/QUIC Identification String . . . . . 21 9.1. Registration of HTTP/QUIC Identification String . . . . . 21
9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 21 9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 21
9.3. Existing Frame Types . . . . . . . . . . . . . . . . . . 21 9.3. Existing Frame Types . . . . . . . . . . . . . . . . . . 21
9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 22 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 22
9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 23 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
B.1. Since draft-ietf-quic-http-01: . . . . . . . . . . . . . 26 B.1. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 26
B.2. Since draft-ietf-quic-http-00: . . . . . . . . . . . . . 27 B.2. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 27
B.3. Since draft-shade-quic-http2-mapping-00: . . . . . . . . 27 B.3. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 B.4. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The QUIC transport protocol has several features that are desirable The QUIC transport protocol has several features that are desirable
in a transport for HTTP, such as stream multiplexing, per-stream flow in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC, drawing heavily on describes a mapping of HTTP semantics over QUIC, drawing heavily on
the existing TCP mapping, HTTP/2. Specifically, this document the existing TCP mapping, HTTP/2. Specifically, this document
identifies HTTP/2 features that are subsumed by QUIC, and describes identifies HTTP/2 features that are subsumed by QUIC, and describes
how the other features can be implemented atop QUIC. how the other features can be implemented atop QUIC.
skipping to change at page 3, line 42 skipping to change at page 3, line 43
document. It's not shouting; when they are capitalized, they have document. It's not shouting; when they are capitalized, they have
the special meaning defined in [RFC2119]. the special meaning defined in [RFC2119].
2. QUIC Advertisement 2. QUIC Advertisement
An HTTP origin advertises the availability of an equivalent HTTP/QUIC An HTTP origin advertises the availability of an equivalent HTTP/QUIC
endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC
frame ([RFC7838]), using the ALPN token defined in Section 3. frame ([RFC7838]), using the ALPN token defined in Section 3.
For example, an origin could indicate in an HTTP/1.1 or HTTP/2 For example, an origin could indicate in an HTTP/1.1 or HTTP/2
response that HTTP/QUIC was available on UDP port 443 at the same response that HTTP/QUIC was available on UDP port 50781 at the same
hostname by including the following header in any response: hostname by including the following header in any response:
Alt-Svc: hq=":443" Alt-Svc: hq=":50781"
On receipt of an Alt-Svc header indicating HTTP/QUIC support, a On receipt of an Alt-Svc header indicating HTTP/QUIC support, a
client MAY attempt to establish a QUIC connection to the indicated client MAY attempt to establish a QUIC connection to the indicated
host and port and, if successful, send HTTP requests using the host and port and, if successful, send HTTP requests using the
mapping described in this document. mapping described in this document.
Connectivity problems (e.g. firewall blocking UDP) can result in QUIC Connectivity problems (e.g. firewall blocking UDP) can result in QUIC
connection establishment failure, in which case the client SHOULD connection establishment failure, in which case the client SHOULD
continue using the existing connection or try another alternative continue using the existing connection or try another alternative
endpoint offered by the origin. endpoint offered by the origin.
Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the
same port across all IP addresses that serve a single domain, and
SHOULD NOT change this port.
2.1. QUIC Version Hints 2.1. QUIC Version Hints
This document defines the "quic" parameter for Alt-Svc, which MAY be This document defines the "quic" parameter for Alt-Svc, which MAY be
used to provide version-negotiation hints to HTTP/QUIC clients. QUIC used to provide version-negotiation hints to HTTP/QUIC clients. QUIC
versions are four-octet sequences with no additional constraints on versions are four-octet sequences with no additional constraints on
format. Syntax: format. Syntax:
quic = version-number quic = version-number
version-number = 1*8HEXDIG; hex-encoded QUIC version version-number = 1*8HEXDIG; hex-encoded QUIC version
Leading zeros SHOULD be omitted for brevity. When multiple versions Leading zeros SHOULD be omitted for brevity. When multiple versions
are supported, the "quic" parameter MAY be repeated multiple times in are supported, the "quic" parameter MAY be repeated multiple times in
a single Alt-Svc entry. For example, if a server supported both a single Alt-Svc entry. For example, if a server supported both
version 0x00000001 and the version rendered in ASCII as "Q034", it version 0x00000001 and the version rendered in ASCII as "Q034", it
could specify the following header: could specify the following header:
Alt-Svc: hq=":443";quic=1;quic=51303334 Alt-Svc: hq=":49288";quic=1;quic=51303334
Where multiple versions are listed, the order of the values reflects Where multiple versions are listed, the order of the values reflects
the server's preference (with the first value being the most the server's preference (with the first value being the most
preferred version). Origins SHOULD list only versions which are preferred version). Origins SHOULD list only versions which are
supported by the alternative, but MAY omit supported versions for any supported by the alternative, but MAY omit supported versions for any
reason. reason.
3. Connection Establishment 3. Connection Establishment
HTTP/QUIC connections are established as described in HTTP/QUIC connections are established as described in
[QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support [QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support
is indicated by selecting the ALPN token "hq" in the crypto is indicated by selecting the ALPN token "hq" in the crypto
handshake. handshake.
While connection-level options pertaining to the core QUIC protocol While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, HTTP-specific settings are are set in the initial crypto handshake, HTTP-specific settings are
conveyed in the SETTINGS frame. After the QUIC connection is conveyed in the SETTINGS frame. After the QUIC connection is
established, a SETTINGS frame (Section 5.2.3) MUST be sent as the established, a SETTINGS frame (Section 5.2.3) MUST be sent as the
initial frame of the HTTP control stream (StreamID 3, see Section 4). initial frame of the HTTP control stream (Stream ID 1, see
The server MUST NOT send data on any other stream until the client's Section 4). The server MUST NOT send data on any other stream until
SETTINGS frame has been received. the client's SETTINGS frame has been received.
3.1. Draft Version Identification 3.1. Draft Version Identification
*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.
Only implementations of the final, published RFC can identify Only implementations of the final, published RFC can identify
themselves as "hq". Until such an RFC exists, implementations MUST themselves as "hq". Until such an RFC exists, implementations MUST
NOT identify themselves using this string. NOT identify themselves using this string.
skipping to change at page 5, line 37 skipping to change at page 5, line 37
4. Stream Mapping and Usage 4. Stream Mapping and Usage
A QUIC stream provides reliable in-order delivery of bytes, but makes A QUIC stream provides reliable in-order delivery of bytes, but makes
no guarantees about order of delivery with regard to bytes on other no guarantees about order of delivery with regard to bytes on other
streams. On the wire, data is framed into QUIC STREAM frames, but streams. On the wire, data is framed into QUIC STREAM frames, but
this framing is invisible to the HTTP framing layer. A QUIC receiver this framing is invisible to the HTTP framing layer. A QUIC receiver
buffers and orders received STREAM frames, exposing the data buffers and orders received STREAM frames, exposing the data
contained within as a reliable byte stream to the application. contained within as a reliable byte stream to the application.
QUIC reserves Stream 1 for crypto operations (the handshake, crypto QUIC reserves Stream 0 for crypto operations (the handshake, crypto
config updates). Stream 3 is reserved for sending and receiving HTTP config updates). Stream 1 is reserved for sending and receiving HTTP
control frames, and is analogous to HTTP/2's Stream 0. This control frames, and is analogous to HTTP/2's Stream 0. This
connection control stream is considered critical to the HTTP connection control stream is considered critical to the HTTP
connection. If the connection control stream is closed for any connection. If the connection control stream is closed for any
reason, this MUST be treated as a connection error of type reason, this MUST be treated as a connection error of type
QUIC_CLOSED_CRITICAL_STREAM. QUIC_CLOSED_CRITICAL_STREAM.
When HTTP headers and data are sent over QUIC, the QUIC layer handles When HTTP headers and data are sent over QUIC, the QUIC layer handles
most of the stream management. An HTTP request/response consumes a most of the stream management. An HTTP request/response consumes a
pair of streams: This means that the client's first request occurs on pair of streams: This means that the client's first request occurs on
QUIC streams 5 and 7, the second on stream 9 and 11, and so on. The QUIC streams 3 and 5, the second on stream 7 and 9, and so on. The
server's first push consumes streams 2 and 4. This amounts to the server's first push consumes streams 2 and 4. This amounts to the
second least-significant bit differentiating the two streams in a second least-significant bit differentiating the two streams in a
request. request.
The lower-numbered stream is called the message control stream and The lower-numbered stream is called the message control stream and
carries frames related to the request/response, including HEADERS. carries frames related to the request/response, including HEADERS.
The higher-numbered stream is the data stream and carries the The higher-numbered stream is the data stream and carries the
request/response body with no additional framing. Note that a request/response body with no additional framing. Note that a
request or response without a body will cause this stream to be half- request or response without a body will cause this stream to be half-
closed in the corresponding direction without transferring data. closed in the corresponding direction without transferring data.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
data stream is opened at the same time as the message control stream data stream is opened at the same time as the message control stream
is opened and is closed after transferring the body. The data stream is opened and is closed after transferring the body. The data stream
is closed immediately after sending the request headers if there is is closed immediately after sending the request headers if there is
no body. no body.
HTTP does not need to do any separate multiplexing when using QUIC - HTTP does not need to do any separate multiplexing when using QUIC -
data sent over a QUIC stream always maps to a particular HTTP data sent over a QUIC stream always maps to a particular HTTP
transaction. Requests and responses are considered complete when the transaction. Requests and responses are considered complete when the
corresponding QUIC streams are closed in the appropriate direction. corresponding QUIC streams are closed in the appropriate direction.
4.1. Stream 3: Connection Control Stream 4.1. Stream 1: Connection Control Stream
Since most connection-level concerns will be managed by QUIC, the Since most connection-level concerns will be managed by QUIC, the
primary use of Stream 3 will be for the SETTINGS frame when the primary use of Stream 1 will be for the SETTINGS frame when the
connection opens and for PRIORITY frames subsequently. connection opens and for PRIORITY frames subsequently.
4.2. HTTP Message Exchanges 4.2. HTTP Message Exchanges
A client sends an HTTP request on a new pair of QUIC streams. A A client sends an HTTP request on a new pair of QUIC streams. A
server sends an HTTP response on the same streams as the request. server sends an HTTP response on the same streams as the request.
An HTTP message (request or response) consists of: An HTTP message (request or response) consists of:
1. one header block (see Section 5.2.1) on the control stream 1. one header block (see Section 5.2.1) on the control stream
skipping to change at page 9, line 46 skipping to change at page 9, line 46
control stream of the dependent request, not the data stream. control stream of the dependent request, not the data stream.
4.4. Server Push 4.4. Server Push
HTTP/QUIC supports server push as described in [RFC7540]. During HTTP/QUIC supports server push as described in [RFC7540]. During
connection establishment, the client indicates whether it is willing connection establishment, the client indicates whether it is willing
to receive server pushes via the SETTINGS_DISABLE_PUSH setting in the to receive server pushes via the SETTINGS_DISABLE_PUSH setting in the
SETTINGS frame (see Section 3), which defaults to 1 (true). SETTINGS frame (see Section 3), which defaults to 1 (true).
As with server push for HTTP/2, the server initiates a server push by As with server push for HTTP/2, the server initiates a server push by
sending a PUSH_PROMISE frame containing the StreamID of the stream to sending a PUSH_PROMISE frame containing the Stream ID of the stream
be pushed, as well as request header fields attributed to the to be pushed, as well as request header fields attributed to the
request. The PUSH_PROMISE frame is sent on the control stream of the request. The PUSH_PROMISE frame is sent on the control stream of the
associated (client-initiated) request, while the Promised Stream ID associated (client-initiated) request, while the Promised Stream ID
field specifies the Stream ID of the control stream for the server- field specifies the Stream ID of the control stream for the server-
initiated request. initiated request.
The server push response is conveyed in the same way as a non-server- The server push response is conveyed in the same way as a non-server-
push response, with response headers and (if present) trailers push response, with response headers and (if present) trailers
carried by HEADERS frames sent on the control stream, and response carried by HEADERS frames sent on the control stream, and response
body (if any) sent via the corresponding data stream. body (if any) sent via the corresponding data stream.
5. HTTP Framing Layer 5. HTTP Framing Layer
Frames are used only on the connection (stream 3) and message Frames are used only on the connection (stream 1) and message
(streams 5, 9, etc.) control streams. Other streams carry data (streams 3, 7, etc.) control streams. Other streams carry data
payload and are not framed at the HTTP layer. payload and are not framed at the HTTP layer.
This section describes HTTP framing in QUIC and highlights some This section describes HTTP framing in QUIC and highlights some
differences from HTTP/2 framing. For more detail on differences from differences from HTTP/2 framing. For more detail on differences from
HTTP/2, see Section 7.1. HTTP/2, see Section 7.1.
5.1. Frame Layout 5.1. Frame Layout
All frames have the following format: All frames have the following format:
skipping to change at page 18, line 6 skipping to change at page 18, line 6
tree mutations): since operations on the dependency tree such as tree mutations): since operations on the dependency tree such as
reparenting a subtree are not commutative, both sender and receiver reparenting a subtree are not commutative, both sender and receiver
must apply them in the same order to ensure that both sides have a must apply them in the same order to ensure that both sides have a
consistent view of the stream dependency tree. HTTP/2 specifies consistent view of the stream dependency tree. HTTP/2 specifies
priority assignments in PRIORITY frames and (optionally) in HEADERS priority assignments in PRIORITY frames and (optionally) in HEADERS
frames. To achieve in-order delivery of priority changes in HTTP/ frames. To achieve in-order delivery of priority changes in HTTP/
QUIC, PRIORITY frames are sent on the connection control stream and QUIC, PRIORITY frames are sent on the connection control stream and
the PRIORITY section is removed from the HEADERS frame. the PRIORITY section is removed from the HEADERS frame.
Other than this issue, frame type HTTP/2 extensions are typically Other than this issue, frame type HTTP/2 extensions are typically
portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 3 portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 1
in HTTP/QUIC. in HTTP/QUIC.
Below is a listing of how each HTTP/2 frame type is mapped: Below is a listing of how each HTTP/2 frame type is mapped:
DATA (0x0): Instead of DATA frames, HTTP/QUIC uses a separate data DATA (0x0): Instead of DATA frames, HTTP/QUIC uses a separate data
stream. See Section 4. stream. See Section 4.
HEADERS (0x1): As described above, the PRIORITY region of HEADERS is HEADERS (0x1): As described above, the PRIORITY region of HEADERS is
not supported. A separate PRIORITY frame MUST be used. Padding not supported. A separate PRIORITY frame MUST be used. Padding
is not defined in HTTP/QUIC frames. See Section 5.2.1. is not defined in HTTP/QUIC frames. See Section 5.2.1.
skipping to change at page 25, line 35 skipping to change at page 25, line 35
| | | stream was | | | | | stream was | |
| | | RST | | | | | RST | |
+------------------------------+-----+--------------+---------------+ +------------------------------+-----+--------------+---------------+
10. References 10. References
10.1. Normative References 10.1. Normative References
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport". Multiplexed and Secure Transport", draft-ietf-quic-
transport (work in progress), May 2017.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 26, line 45 skipping to change at page 26, line 45
Appendix A. Contributors Appendix A. Contributors
The original authors of this specification were Robbie Shade and Mike The original authors of this specification were Robbie Shade and Mike
Warres. Warres.
Appendix B. Change Log Appendix B. Change Log
*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.
B.1. Since draft-ietf-quic-http-01: B.1. Since draft-ietf-quic-http-02
o Track changes in transport draft
B.2. Since draft-ietf-quic-http-01
o SETTINGS changes (#181): o SETTINGS changes (#181):
* SETTINGS can be sent only once at the start of a connection; no * SETTINGS can be sent only once at the start of a connection; no
changes thereafter changes thereafter
* SETTINGS_ACK removed * SETTINGS_ACK removed
* Settings can only occur in the SETTINGS frame a single time * Settings can only occur in the SETTINGS frame a single time
* Boolean format updated * Boolean format updated
o Alt-Svc parameter changed from "v" to "quic"; format updated o Alt-Svc parameter changed from "v" to "quic"; format updated
(#229) (#229)
o Closing the connection control stream or any message control o Closing the connection control stream or any message control
stream is a fatal error (#176) stream is a fatal error (#176)
skipping to change at page 27, line 21 skipping to change at page 27, line 31
o Closing the connection control stream or any message control o Closing the connection control stream or any message control
stream is a fatal error (#176) stream is a fatal error (#176)
o HPACK Sequence counter can wrap (#173) o HPACK Sequence counter can wrap (#173)
o 0-RTT guidance added o 0-RTT guidance added
o Guide to differences from HTTP/2 and porting HTTP/2 extensions o Guide to differences from HTTP/2 and porting HTTP/2 extensions
added (#127,#242) added (#127,#242)
B.2. Since draft-ietf-quic-http-00: B.3. Since draft-ietf-quic-http-00
o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
o Changed from using HTTP/2 framing within Stream 3 to new framing o Changed from using HTTP/2 framing within Stream 3 to new framing
format and two-stream-per-request model (#71,#72,#73) format and two-stream-per-request model (#71,#72,#73)
o Adopted SETTINGS format from draft-bishop-httpbis-extended- o Adopted SETTINGS format from draft-bishop-httpbis-extended-
settings-01 settings-01
o Reworked SETTINGS_ACK to account for indeterminate inter-stream o Reworked SETTINGS_ACK to account for indeterminate inter-stream
order (#75) order (#75)
o Described CONNECT pseudo-method (#95) o Described CONNECT pseudo-method (#95)
o Updated ALPN token and Alt-Svc guidance (#13,#87) o Updated ALPN token and Alt-Svc guidance (#13,#87)
o Application-layer-defined error codes (#19,#74) o Application-layer-defined error codes (#19,#74)
B.3. Since draft-shade-quic-http2-mapping-00: B.4. Since draft-shade-quic-http2-mapping-00
o Adopted as base for draft-ietf-quic-http. o Adopted as base for draft-ietf-quic-http
o Updated authors/editors list. o Updated authors/editors list
Author's Address Author's Address
Mike Bishop (editor) Mike Bishop (editor)
Microsoft Microsoft
Email: Michael.Bishop@microsoft.com Email: Michael.Bishop@microsoft.com
 End of changes. 24 change blocks. 
31 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/