Draft: draft-ietf-quic-http

Commentary: Fixes several nits from the gen - art review , which basically all come down to defining terms appropriately and/or referencing their definitions . modifies definition of " stream " and " stream error " ; pulls in more terms from SEMANTICS references SEMANTICS for definition of fields rewords to avoid the term " hop " and describes intermediation more explicitly rewords to avoid saying " not possible " and copies language from SEMANTICS advising against retries updates reference to definition of CONNECT in SEMANTICS . your review would be appreciated . 
 In the HTTP genart review , writes : 
 Yes , CONNECT only supports TCP , and there 's no short - term plan to change that . There is separate relevant work such as but I do n't think we need to change anything in the draft here - it pretty clearly mentions TCP so I do n't see any ambiguity . 
 This question should be addressed by the definition of CONNECT the spec is referring to . It 's worth double - checking the references in that section , though ; it points to HTTP11 , when I think there should be a definition in SEMANTICS . 
 In the HTTP genart review , writes : 
 Presumably a reference into SEMANTICS ; I 'll look for the right section to point to . 
 In the HTTP genart review , writes : 
 In the HTTP genart review , writes : 
 In the HTTP genart review , writes : " HTTP/3 stream " . Perhaps it 's worth defining " HTTP/3 stream " explicitly , in analogy to " HTTP/3 connection " . Perhaps it 's worth defining " message " , too ( this is only an HTTP concept , correct ? ) . The document should make sure it clearly distinguishes terms and concept of QUIC vs. of HTTP/3 in all cases . In particular , what is the relationship between HTTP/3 frames and QUIC frames ? It 's important to make their difference and relationship explicit , as the document uses several other terms interchangeably between HTTP/3 and QUIC , like " connection " and perhaps " stream " . 
 A few minor suggestions , but this is a good change . This looks good to me , thanks !
Paragraph (version A):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the
SETTINGS_MAX_FIELD_SECTION_SIZE parameter.  An implementation that
has received this parameter SHOULD NOT send an HTTP message header
that exceeds the indicated size, as the peer will likely refuse to
process it.  However, an HTTP message can traverse one or more
intermediaries (see Section 3.7 of SEMANTICS) before reaching the
origin server.  Because this limit is applied separately by each
implementation which processes the message, messages below this limit
are not guaranteed to be accepted.
Paragraph (version B):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the
SETTINGS_MAX_FIELD_SECTION_SIZE parameter.  An implementation that
has received this parameter SHOULD NOT send an HTTP message header
that exceeds the indicated size, as the peer will likely refuse to
process it.  However, an HTTP message can traverse one or more
intermediaries before reaching the origin server; see Section 3.7 of
SEMANTICS.  Because this limit is applied separately by each
implementation which processes the message, messages below this limit
are not guaranteed to be accepted.
Paragraph (version A):
If a stream is canceled after receiving a complete response, the
client MAY ignore the cancellation and use the response.  However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used.  Only idempotent actions (such as GET,
PUT, or DELETE) can be safely retried; a client SHOULD NOT
automatically retry a request with a non-idempotent method unless it
has some means to know that the request semantics are actually
idempotent, regardless of the method, or some means to detect that
the original request was never applied.  See Section 8.2.2 of
SEMANTICS for more details.
Paragraph (version B):
If a stream is canceled after receiving a complete response, the
client MAY ignore the cancellation and use the response.  However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used.  Only idempotent actions such as GET,
PUT, or DELETE can be safely retried; a client SHOULD NOT
automatically retry a request with a non-idempotent method unless it
has some means to know that the request semantics are idempotent
independent of the method or some means to detect that the original
request was never applied.  See Section 8.2.2 of SEMANTICS for more
details.