Draft: draft-ietf-quic-http

Commentary: Collection of editorial changes from review . if no one objects . 
 said 
 said 
 Arguably . I 've included it in the PR for your comments , but it feels borderline . 
 said 
 0x0 actually seems to be an oversight that someone plugged at some point -- I ca n't find anything in RFC 7540 that reserves the value . The range begins at 0x0 , but defined values begin at 0x1 ; IANA has marked 0x0 as reserved and points to 7540 . No harm in marking 0x0 as reserved here as well , I suppose . 
 said : 
 said 
 said 
 said : 
 notes that the text for avoiding conflicting registrations with HTTP/2 does n't actually empower the expert to refuse a registration if the registrant really really wants to stomp a value already assigned in the other protocol . Add a sentence that expert reviewers MAY refuse a registration on those grounds . 
 One change here looks a little off .
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 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 B):
This document defines HTTP/3, a mapping of HTTP semantics over the
QUIC transport protocol, drawing heavily on the design of HTTP/2.
HTTP/3 relies on QUIC to provide confidentiality and integrity
protection of data; peer authentication; and reliable, in-order, per-
stream delivery.  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):
An HTTP origin advertises the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame (ALTSVC), using the "h3" ALPN token.
Paragraph (version B):
An HTTP origin can advertise the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame (ALTSVC), using the "h3" ALPN token.
Paragraph (version B):
See other-schemes for guidance on using a scheme other than
"https".
Paragraph (version B):
Since CONNECT creates a tunnel to an arbitrary server, proxies that
support CONNECT SHOULD restrict its use to a set of known ports or a
list of safe request targets; see Section 9.3.6 of SEMANTICS for more
detail.
Paragraph (version B):
Because the contents of the control stream are used to manage the
behavior of other streams, endpoints SHOULD provide enough flow
control credit to keep the peer's control stream from becoming
blocked.
Paragraph (version A):
Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements.  Implementations MUST discard frames
and unidirectional streams that have unknown or unsupported types.
This means that any of these extension points can be safely used by
extensions without prior arrangement or negotiation.  However, where
a known frame type is required to be in a specific location, such as
the SETTINGS frame as the first frame of the control stream (see
control-streams), an unknown frame type does not satisfy that
requirement and SHOULD be treated as an error.
Paragraph (version B):
Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements.  Implementations MUST discard frames
and abort reading on unidirectional streams that have unknown or
unsupported types.  This means that any of these extension points can
be safely used by extensions without prior arrangement or
negotiation.  However, where a known frame type is required to be in
a specific location, such as the SETTINGS frame as the first frame of
the control stream (see control-streams), an unknown frame type does
not satisfy that requirement and SHOULD be treated as an error.
Paragraph (version A):
The CONNECT method can be used to create disproportionate load on a
proxy, since stream creation is relatively inexpensive when compared
to the creation and maintenance of a TCP connection.  A proxy might
also maintain some resources for a TCP connection beyond the closing
of the stream that carries the CONNECT request, since the outgoing
TCP connection remains in the TIME_WAIT state.  Therefore, a proxy
cannot rely on QUIC stream limits alone to control the resources
consumed by CONNECT requests.
Paragraph (version B):
The CONNECT method can be used to create disproportionate load on a
proxy, since stream creation is relatively inexpensive when compared
to the creation and maintenance of a TCP connection.  Therefore, a
proxy that supports CONNECT might be more conservative in the number
of simultaneous requests it accepts.
Paragraph (version B):
A proxy might also maintain some resources for a TCP connection
beyond the closing of the stream that carries the CONNECT request,
since the outgoing TCP connection remains in the TIME_WAIT state.  To
account for this, a proxy might delay increasing the QUIC stream
limits for some time after a TCP connection terminates.
Paragraph (version A):
The use of 0-RTT with HTTP/3 creates an exposure to replay attack.
The anti-replay mitigations in HTTP-REPLAY MUST be applied when using
HTTP/3 with 0-RTT.
Paragraph (version B):
The use of 0-RTT with HTTP/3 creates an exposure to replay attack.
The anti-replay mitigations in HTTP-REPLAY MUST be applied when using
HTTP/3 with 0-RTT.  When applying HTTP-REPLAY to HTTP/3, references
to the TLS layer refer to the handshake performed within QUIC, while
all references to application data refer to the contents of streams.
Paragraph (version A):
While this registry is separate from the "HTTP/2 Frame Type" registry
defined in HTTP2, it is preferable that the assignments parallel each
other where the code spaces overlap.  If an entry is present in only
one registry, every effort SHOULD be made to avoid assigning the
corresponding value to an unrelated operation.
Paragraph (version B):
While this registry is separate from the "HTTP/2 Frame Type" registry
defined in HTTP2, it is preferable that the assignments parallel each
other where the code spaces overlap.  If an entry is present in only
one registry, every effort SHOULD be made to avoid assigning the
corresponding value to an unrelated operation.  Expert reviewers MAY
reject unrelated registrations which would conflict with the same
value in the corresponding registry.
Paragraph (version A):
While this registry is separate from the "HTTP/2 Settings" registry
defined in HTTP2, it is preferable that the assignments parallel each
other.  If an entry is present in only one registry, every effort
SHOULD be made to avoid assigning the corresponding value to an
unrelated operation.
Paragraph (version B):
While this registry is separate from the "HTTP/2 Settings" registry
defined in HTTP2, it is preferable that the assignments parallel each
other.  If an entry is present in only one registry, every effort
SHOULD be made to avoid assigning the corresponding value to an
unrelated operation.  Expert reviewers MAY reject unrelated
registrations which would conflict with the same value in the
corresponding registry.
Paragraph (version A):
Registrations for error codes are required to include a description
of the error code.  An expert reviewer is advised to examine new
registrations for possible duplication with existing error codes.
Use of existing registrations is to be encouraged, but not mandated.
Use of values that are registered in the "HTTP/2 Error Code" registry
is discouraged.
Paragraph (version B):
Registrations for error codes are required to include a description
of the error code.  An expert reviewer is advised to examine new
registrations for possible duplication with existing error codes.
Use of existing registrations is to be encouraged, but not mandated.
Use of values that are registered in the "HTTP/2 Error Code" registry
is discouraged, and expert reviewers MAY reject such registrations.