Last Call Review of draft-ietf-quic-http-32

Request Review of draft-ietf-quic-http
Requested rev. no specific revision (document currently at 33)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-11-16
Requested 2020-10-21
Authors Mike Bishop
Draft last updated 2020-11-15
Completed reviews Genart Last Call review of -32 by Theresa Enghardt (diff)
Secdir Last Call review of -32 by Hilarie Orman (diff)
Genart Telechat review of -33 by Theresa Enghardt
Assignment Reviewer Theresa Enghardt 
State Completed
Review review-ietf-quic-http-32-genart-lc-enghardt-2020-11-15
Posted at
Reviewed rev. 32 (document currently at 33)
Review result Ready with Issues
Review completed: 2020-11-15


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-quic-http-32
Reviewer: Theresa Enghardt
Review Date: 2020-11-15
IETF LC End Date: 2020-11-16
IESG Telechat date: Not scheduled for a telechat

Summary: The document is basically ready, but still has some minor clarity issues. In particular, the distinction between HTTP and QUIC concepts should be made clearer before publication.

Major issues: None

Minor issues:

The document defines "stream" as a QUIC stream, but then also uses the term "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".

The concepts around error codes is not entirely clear to me, e.g., H3_REQUEST_INCOMPLETE or H3_NO_ERROR - Are these a separate concept from HTTP response status codes such as "200 OK" and "404 Not Found", etc.? Are these error codes related to QUIC errors?
Is the "application error code" mentioned in Section 5.3 the same concept or is it a different concept? Is the "application error code" an HTTP/3 concept of a QUIC concept? 
Is "connection error" used in Section 7 the same concept or is it a difference concept? Does a "connection error" as used in Section 7 always mean that the entire connection fails, as opposed to a single stream?
Section 8 aims to explain some of these concepts, and I think the document should reference to this section for more information when it starts mentioning all these different error types. (Or, if they are all the same, perhaps the terminology should be unified.)

Section 4.1.1.

"HTTP messages carry metadata as a series of key-value pairs, called HTTP fields."
Are these the same as HTTP headers and trailers? Or are HTTP fields a more general concept? Are they also allowed in bodies?


"because this limit is applied at each hop," ...
What is a hop in the context of HTTP? I think it's worth at least briefly introducing this concept to make things clearer, as the document includes many different concepts from different layers.

Section 4.1.2

"Automatically retrying such requests is
   not possible, unless this is otherwise permitted (e.g., idempotent
   actions like GET, PUT, or DELETE)."
Retrying is "not possible" means it's prohibited? Is there a reference to the exceptions to that rule, e.g., a list of actions that are considered idempotent? If so, please provide a reference.

Section 4.2

"A proxy that supports CONNECT establishes a TCP connection […]"
Is this necessarily always TCP, not QUIC? Can this change in the future?

Section 5.1

"HTTP/3 implementations will need to open a new HTTP/3
   connection for new requests if the existing connection has been idle
   for longer than the server's advertised idle timeout"
Only the server's timeout? Does "implementations" here mean only clients?

Section 6.2

"However, stream types that could modify the state or
   semantics of existing protocol components, including QPACK or other
   extensions, MUST NOT be sent until the peer is known to support them."
Is there a defined list of stream types that are not allowed to be used? If so, please provide a reference.

Is section 6 missing the request stream? It has subsections for Control Streams and Push Streams, but then Section 7 says that Request Stream is also a stream type.

Nits/editorial comments: None.