Draft: draft-ietf-quic-http

Commentary: I split a few things out into separate commits in case they need to be excised / reverted . May be relevant for . 
 review of -http identified use of the subject : commonName field in validating server identity . We should not elevate CN - ID to MUST . In doing so , we invalidate what  has done : 7.1.4.2.2 clause a of the marks subject : commonName as deprecated and discouraged . My understanding ( which I can confirm ) is that browsers do not use CN - ID ( concretely , the CN field of the certificate subject ) and so we might want to just mention the dNSName type of subjectAltName here . We can mention that some clients might use subject : commonName , but that this is a deprecated practice . This accounts for some of the older certificate validation code that still exists in some places . Some of that does rely on the common name . I realize that this likely breaks new ground for the RFC series , and it likely needs more discussion , but maybe we can keep up with the times with this document . ( I apologize for not having caught this earlier ; I think that this is copied from elsewhere and that too needs a refresh . ) Originally posted by in 
 There is some probably relevant discussion for http - semantics at ( though as was noted recently the change that closed that issue had some issues of its own ) 
 Marking as design , since is . 
 Reopening for consensus call . 
 Closing this now that the IESG have approved the document and it 's with the RFC editor . 
 said 
 I suspect this will be fixed by the resolution to . 
 FWIW I have some changes staged in my forthcoming editorial PR that harmonizes the requirements language here , even though that is perhaps a little speculative for " just " an editorial PR . 
 Labeling this design , since is . 
 Reopening for consensus call . 
 Closing this now that the IESG have approved the document and it 's with the RFC editor . 
 I 've identified what I think is something worth discussing further . I 'll open an issue for that .
Paragraph (version A):
This document defines a mapping of HTTP semantics over the QUIC
transport protocol, drawing heavily on the design of HTTP/2.  While
delegating stream lifetime and flow control issues to QUIC, a similar
binary framing is used on each stream.  Some HTTP/2 features are
subsumed by QUIC, while other features are implemented atop QUIC.
Paragraph (version B):
This document defines a mapping of HTTP semantics over the QUIC
transport protocol, drawing heavily on the design of HTTP/2.  While
delegating stream lifetime and flow control issues to QUIC, a binary
framing similar to the HTTP/2 framing is used on each stream.  Some
HTTP/2 features are subsumed by QUIC, while other features are
implemented atop QUIC.
Paragraph (version A):
Within each stream, the basic unit of HTTP/3 communication is a frame
(frames).  Each frame type serves a different purpose.  For example,
HEADERS and DATA frames form the basis of HTTP requests and responses
(request-response).
Paragraph (version B):
Within each stream, the basic unit of HTTP/3 communication is a frame
(frames).  Each frame type serves a different purpose.  For example,
HEADERS and DATA frames form the basis of HTTP requests and responses
(request-response).  Frames that apply to the entire connection are
conveyed on a dedicated control stream.
Paragraph (version A):
A client MAY attempt access to a resource with an "https" URI by
resolving the host identifier to an IP address, establishing a QUIC
connection to that address on the indicated port, and sending an
HTTP/3 request message targeting the URI to the server over that
secured connection.  Unless some other mechanism is used to select
HTTP/3, the token "h3" is used in the Application Layer Protocol
Negotiation (ALPN; see RFC7301) extension during the TLS handshake.
Paragraph (version B):
A client MAY attempt access to a resource with an "https" URI by
resolving the host identifier to an IP address, establishing a QUIC
connection to that address on the indicated port (including
validation of the server certificate as described above), and sending
an HTTP/3 request message targeting the URI to the server over that
secured connection.  Unless some other mechanism is used to select
HTTP/3, the token "h3" is used in the Application Layer Protocol
Negotiation (ALPN; see RFC7301) extension during the TLS handshake.
Paragraph (version A):
Receipt of an invalid sequence of frames MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED; see errors.  In
particular, a DATA frame before any HEADERS frame, or a HEADERS or
DATA frame after the trailing HEADERS frame is considered invalid.
Other frame types, especially unknown frame types, might be permitted
subject to their own rules; see extensions.
Paragraph (version B):
Receipt of an invalid sequence of frames MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED; see errors.  In
particular, a DATA frame before any HEADERS frame, or a HEADERS or
DATA frame after the trailing HEADERS frame, is considered invalid.
Other frame types, especially unknown frame types, might be permitted
subject to their own rules; see extensions.
Paragraph (version A):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see Section 15.2 of SEMANTICS) precede a
final response to the same request.  Interim responses do not contain
content or trailers.
Paragraph (version B):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see Section 15.2 of SEMANTICS) precede a
final response to the same request.  Interim responses do not contain
content or trailer sections.
Paragraph (version A):
Pseudo-header fields are only valid in the context in which they are
defined.  Pseudo-header fields defined for requests MUST NOT appear
in responses; pseudo-header fields defined for responses MUST NOT
appear in requests.  Pseudo-header fields MUST NOT appear in
trailers.  Endpoints MUST treat a request or response that contains
undefined or invalid pseudo-header fields as malformed (malformed).
Paragraph (version B):
Pseudo-header fields are only valid in the context in which they are
defined.  Pseudo-header fields defined for requests MUST NOT appear
in responses; pseudo-header fields defined for responses MUST NOT
appear in requests.  Pseudo-header fields MUST NOT appear in trailer
sections.  Endpoints MUST treat a request or response that contains
undefined or invalid pseudo-header fields as malformed (malformed).
Paragraph (version A):
":scheme" is not restricted to "http" and "https" schemed URIs.  A
proxy or gateway can translate requests for non-HTTP schemes,
enabling the use of HTTP to interact with non-HTTP services.
Paragraph (version A):
Contains the authority portion of the target URI (Section 3.2 of
URI).  The authority MUST NOT include the deprecated "userinfo"
subcomponent for "http" or "https" schemed URIs.
Paragraph (version B):
":scheme" is not restricted to URIs with scheme "http" and
"https".  A proxy or gateway can translate requests for non-HTTP
schemes, enabling the use of HTTP to interact with non-HTTP
services.
Paragraph (version B):
Contains the authority portion of the target URI (Section 3.2 of
URI).  The authority MUST NOT include the deprecated "userinfo"
subcomponent for URIs of scheme "http" or "https".
Paragraph (version A):
Requests on Stream IDs less than the Stream ID in a GOAWAY frame
from the server might have been processed; their status cannot be
known until a response is received, the stream is reset
individually, another GOAWAY is received, or the connection
terminates.
Paragraph (version B):
Requests on Stream IDs less than the Stream ID in a GOAWAY frame
from the server might have been processed; their status cannot be
known until a response is received, the stream is reset
individually, another GOAWAY is received with a lower Stream ID
than that of the request in question, or the connection
terminates.
Paragraph (version A):
A QUIC stream provides reliable in-order delivery of bytes, but makes
no guarantees about order of delivery with regard to bytes on other
streams.  On the wire, data is framed into QUIC STREAM frames, but
this framing is invisible to the HTTP framing layer.  The transport
layer buffers and orders received QUIC STREAM frames, exposing the
data contained within as a reliable byte stream to the application.
Although QUIC permits out-of-order delivery within a stream, HTTP/3
does not make use of this feature.
Paragraph (version B):
A QUIC stream provides reliable in-order delivery of bytes, but makes
no guarantees about order of delivery with regard to bytes on other
streams.  On the wire, the stream data containing HTTP frames is
carried by QUIC STREAM frames, but this framing is invisible to the
HTTP framing layer.  The transport layer buffers and orders received
QUIC STREAM frames, exposing the data contained within as a reliable
byte stream to the application.  Although QUIC permits out-of-order
delivery within a stream, HTTP/3 does not make use of this feature.
Paragraph (version A):
A pair of unidirectional streams is used rather than a single
bidirectional stream.  This allows either peer to send data as soon
as it is able.  Depending on whether 0-RTT is enabled on the QUIC
connection, either client or server might be able to send stream data
first after the cryptographic handshake completes.
Paragraph (version B):
A pair of unidirectional streams is used rather than a single
bidirectional stream.  This allows either peer to send data as soon
as it is able.  Depending on whether 0-RTT is available on the QUIC
connection, either client or server might be able to send stream data
first.
Paragraph (version A):
Certain frames can only occur as the first frame of a particular
stream type; these are indicated in stream-frame-mapping with a (1).
Specific guidance is provided in the relevant section.
Paragraph (version B):
The SETTINGS frame can only occur as the first frame of a Control
stream; this is indicated in stream-frame-mapping with a (1).
Specific guidance is provided in the relevant section.
Paragraph (version A):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error of type H3_FRAME_ERROR; see errors.
Paragraph (version B):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error of type H3_FRAME_ERROR; see errors.  In particular, redundant
length encodings MUST be verified to be self-consistent; see frame-
parsing.
Paragraph (version A):
An implementation MUST ignore the contents for any SETTINGS
identifier it does not understand.
Paragraph (version B):
An implementation MUST ignore any parameter with an identifier it
does not understand.
Paragraph (version A):
An endpoint that does not monitor this behavior exposes itself to a
risk of denial-of-service attack.  Implementations SHOULD track the
use of these features and set limits on their use.  An endpoint MAY
treat activity that is suspicious as a connection error of type
H3_EXCESSIVE_LOAD (errors), but false positives will result in
disrupting valid connections and requests.
Paragraph (version B):
An endpoint that does not monitor such behavior exposes itself to a
risk of denial-of-service attack.  Implementations SHOULD track the
use of these features and set limits on their use.  An endpoint MAY
treat activity that is suspicious as a connection error of type
H3_EXCESSIVE_LOAD (errors), but false positives will result in
disrupting valid connections and requests.