Re: Working Group Last Call: HTTP/2 revision

Hi Julian,

On Fri, Aug 20, 2021 at 03:31:26PM +0200, Julian Reschke wrote:
> Section 1
> 
> "Specifically, it allows interleaving of request and response messages
> on the same connection..."
> 
> This really reads strange, as request and responses travel in different
> directions. FWIW, HTTP/1.1 also allows that, no? (You can send a request
> while a response is already received).

Sure, I think that "request and response" were serving as an adjective
for "messages" here, but that doesn't read well after all.

> Maybe just say
> 
> "Specifically, it allows interleaving of messages on the same connection..."
> 
> ?

Probably, or maybe we can instead drop "messages" and put the emphasis on
the fact that multiple requests and responses can be processed in parallel:

  "Specifically, it allows interleaving of requests and responses on
   the same connection..."

> Section 3.2
> 
> "A client that makes a request to an "https" URI uses TLS [TLS13] with
> the application-layer protocol negotiation (ALPN) extension [TLS-ALPN]."
> 
> For a moment I thought that the document requires use of TLS 1.3 (which
> it does not later on). Maybe this should be clarified here.

That was also my implicit understanding reading the sentence you copied
(which surprised me). Or should the shortcut simply be renamed to [TLS] ?

> Section 4.3
> 
> "A field section is a collection of zero or more field lines"
> 
> Which is the same as "A field section is a collection of field lines",
> right?
> 
> I understand that using "zero or more" is used with the intention to be
> precise, but I'd really prefer to avoid it or just say "optional" where
> appropriate.
> 
> (yes, this is a matter of taste)

I think "zero or more" could easily be dropped since there must always
be a few pseudo-header fields in requests and responses anyway. Sending
empty trailers frames is certainly possible but that's probably not the
most interesting aspect of the protocol. I think that placing "optional"
could be difficult or confusing, possibly making some believe that the
frames that carry them are optional.

> Section 8.8
> 
> 1) The H2 parts of the examples use "host", not "authority:". Isn't this
> in conflict with 8.3.1: "Clients that generate HTTP/2 requests directly
> SHOULD use the :authority pseudo-header field instead of the Host header
> field."?

I noticed this one when reporting my concenrs between host and :authority,
and I thought I was maybe focused a bit too much on :authority. But if
we are two to notice this, it's not just me anymore, probably that some
":authority" should be used instead. It could also attract the reader's
eye on this difference with older HTTP versions.

> 2) I think giving each example a subsection would make it clearer where
> examples begin and end; and also would improve linkability.

In the HTML version they're cleanly delimited, so I think they're
properly marked in the original document:

  https://www.ietf.org/archive/id/draft-ietf-httpbis-http2bis-03.html

> Organization:
> 
> In several sections, replacing lists by subsections would improve the
> ToC and make it easier to refer to specific items (frame types, error
> codes, pseudo header fields)
 
I'm not sure for all of them, but probably for the stream states in
5.1 it could significantly help, as for now, only indenting allows
them to be spotted. In this case, "5.1.1 Stream Identifiers" can
become its own 5.2 subsection, and "5.1.2 Stream Concurrency" can
become its own 5.3 subsection. These are not directly related to
stream states anyway.

Willy

Received on Saturday, 21 August 2021 05:59:16 UTC