Subject: Re: Working Group Last Call: HTTP/2 revision

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Aug 2021 15:34:24 +0200

Am 23.07.2021 um 02:05 schrieb Mark Nottingham:
> Hello everyone,
>
> This is the start of Working Group Last Call announcement for this document:
>    https://www.ietf.org/archive/id/draft-ietf-httpbis-http2bis-03.html
>
> Please take time to review it carefully and raise any remaining issues you see (keeping in mind the scope of work),[1] either on the issues list[2] or on this mailing list. Also, we'd like to hear whether you think this document is ready to progress (on this list, please).
>
> Working Group Last Call will end on 13 August 2021.
> ...

I'd really like to spend more time on this LC, but the http-core drafts
are currently taking my available time. It really would be good if the
LC could be extended untila few days after the new drafts for http-core
have shipped - which should be sometime this week.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 17 Aug 2021 16:49:08 +0200

> have shipped - which should be sometime this week.

I agree as well, as I've found a small paragraph a bit difficult to read
but am currently busy dealing with some bugs and couldn't devote time to
this.

Thanks,
Willy

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 18 Aug 2021 07:59:04 +1000

On Tue, Aug 17, 2021, at 23:34, Julian Reschke wrote:
> I'd really like to spend more time on this LC, 

I would like to finalize this work.  Given ongoing work on core drafts, it seems like we could get this document into the same cluster for publication if we move on.

That doesn't mean we can't take reasonable feedback given after this call concludes.  That is, after all, the state the core drafts have been in for a while now.  I can only speak for myself, but I hope Cory will agree: we'll take editorial input at any time as much as the process permits.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Aug 2021 10:35:31 +1000

Hi folks,

Tommy and I have discussed this and agree that we'll extend the WGLC until end of day Sunday, the 22nd, AOE. Please get your comments in promptly.

Cheers,

> On 18 Aug 2021, at 7:59 am, Martin Thomson <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 18 Aug 2021 04:25:28 +0200

On Wed, Aug 18, 2021 at 10:35:31AM +1000, Mark Nottingham wrote:
> Hi folks,
> 
> Tommy and I have discussed this and agree that we'll extend the WGLC until
> end of day Sunday, the 22nd, AOE. Please get your comments in promptly.

Thanks you!

Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Aug 2021 07:05:46 +0200

> I would like to finalize this work.  Given ongoing work on core drafts, it seems like we could get this document into the same cluster for publication if we move on.

I was going to ask about this... It definitively makes sense, but it
will delay publication of HTTP/3 somehwat.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Aug 2021 15:31:26 +0200

Hi there.

I have opened a bunch of PRs fixing minor ediorial issues that seemed
directly actionable.

I'll also stress that Roy's issue about field name syntax
(<https://github.com/httpwg/http2-spec/issues/902>) is important.

The remaining comments are below:

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).

Maybe just say

"Specifically, it allows interleaving of messages 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.

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)

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."?

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

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)

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 21 Aug 2021 07:59:00 +0200

Hi Julian,

> 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.

> "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..."

> 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] ?

> (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.

> SHOULD use the :authority pseudo-header field instead of the Host header

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.

> 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:

> 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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 21 Aug 2021 10:04:57 +0200

>    https://www.ietf.org/archive/id/draft-ietf-httpbis-http2bis-03.html
What I meant is that there is prose before and after each message
artwork, for instance in:

--- snip ---
Note that data contributing to any given field line could be spread
between field block fragments. The allocation of field lines to frames
in this example is illustrative only.

A response that includes control data and a response header and message
content is transmitted as a HEADERS frame, followed by zero or more
CONTINUATION frames, followed by one or more DATA frames, with the last
DATA frame in the sequence having the END_STREAM flag set:
--- snip ---

The first paragraph is about the example above, while the second one is
about the example below.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Aug 2021 13:00:31 +0200

> codes, pseudo header fields)

I just tried this for the stream states; it indeed avoids deeply nested
lists. The issue here is the organization of the surrounding text
(trailing text that applies to all stream states, plus to subsections,
5.1.8. Stream Identifiers and 5.1.9. Stream Concurrency, which might
actually be better placed on the same level as stream states...).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Aug 2021 17:51:22 +0200

Am 23.07.2021 um 02:05 schrieb Mark Nottingham:
> 1. https://www.w3.org/mid/[email-masked]
> 2. https://github.com/httpwg/http2-spec/issues/

Checked for downrefs given the new intended status... (with
<https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>).

Messaging:

> Normative References:
> CACHING: not checked
> HTTP: not checked
> RFC1950: [INFORMATIONAL] -- intended standards level of internet incompatible with this document's standard level!
> RFC1951: [INFORMATIONAL] -- intended standards level of internet incompatible with this document's standard level!
> RFC1952: [INFORMATIONAL] -- intended standards level of internet incompatible with this document's standard level!
> RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014)
> RFC5234: [INTERNET STANDARD] (-> STD0068)
> RFC7405: [PROPOSED STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC8174: [BEST CURRENT PRACTICE] (-> BCP0014)
> RFC8446: [PROPOSED STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC3986: [INTERNET STANDARD] (-> STD0066)
> USASCII: not checked
> Welch: not checked

Semantics:

> Normative References:
> CACHING: not checked
> RFC1950: [INFORMATIONAL] -- intended standards level of internet incompatible with this document's standard level!
> RFC1951: [INFORMATIONAL] -- intended standards level of internet incompatible with this document's standard level!
> RFC1952: [INFORMATIONAL] -- intended standards level of internet incompatible with this document's standard level!
> RFC2046: [DRAFT STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014)
> RFC4647: [BEST CURRENT PRACTICE] (-> BCP0047)
> RFC4648: [PROPOSED STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC5234: [INTERNET STANDARD] (-> STD0068)
> RFC5280: [PROPOSED STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC5322: [DRAFT STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC5646: [BEST CURRENT PRACTICE] (-> BCP0047)
> RFC6125: [PROPOSED STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC6365: [BEST CURRENT PRACTICE] (-> BCP0166)
> RFC7405: [PROPOSED STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC8174: [BEST CURRENT PRACTICE] (-> BCP0014)
> RFC0793: [INTERNET STANDARD] (-> STD0007)
> RFC8446: [PROPOSED STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC3986: [INTERNET STANDARD] (-> STD0066)
> USASCII: not checked
> Welch: not checked

Caching:

> Normative References:
> HTTP: not checked
> RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014)
> RFC5234: [INTERNET STANDARD] (-> STD0068)
> RFC7405: [PROPOSED STANDARD] -- intended standards level of internet incompatible with this document's standard level!
> RFC8174: [BEST CURRENT PRACTICE] (-> BCP0014)

Looking at the details:

RFC1950, RFC1951, RFC1952: [INFORMATIONAL] -- specs for the compression
codings, have been a downref before

RFC2046: [DRAFT STANDARD] -- Media Types. ?

RFC4648: [PROPOSED STANDARD] -- Base 16/32/64 ?

RFC5280: [PROPOSED STANDARD] -- Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile ?

RFC5322: [DRAFT STANDARD] -- Internet Message Format ?

RFC6125: [PROPOSED STANDARD] -- Representation and Verification of
Domain-Based Application Service Identity within Internet Public Key
Infrastructure Using X.509 (PKIX) Certificates in the Context of
Transport Layer Security (TLS) ?

RFC7405: [PROPOSED STANDARD] -- these are ABNF extensions, so I'll
assume that the downref will be permitted

RFC8446: [PROPOSED STANDARD] -- TLS - Martin T. is already looking into
this.

So we have a few downrefs that were downrefs before, a few to specs that
really should be full standards as well (Base16/32/64), and some more
where the answer is not clear, and the IESG would need to sanction the
downref.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Aug 2021 18:06:04 +0200

Am 25.08.2021 um 17:51 schrieb Julian Reschke:
>> Please take time to review it carefully and raise any remaining issues
>> you see (keeping in mind the scope of work),[1] either on the issues
>> list[2] or on this mailing list. Also, we'd like to hear whether you
>> think this document is ready to progress (on this list, please).
>>

Oh, wrong thread. Please ignore.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Aug 2021 18:37:41 +0200

A few more nits:

Abstract

"HTTP/2 enables a more efficient use of network resources and a reduced
perception of latency by introducing field compression..."

Maybe drop "perception of"...?

1.

First occurance of TCP should have the bibl. reference.

4.1

s/and semantics of the frame./and semantics of the frame payload/?

5.

"The order in which frames are sent on a stream is significant"

That makes it sound like only the order *within* a stream is
significant, and that would be incorrect, right?

5.1

Maybe move legend out of artwork.

Best regards, Julian

PS: I'll be happy to create PRs if desired.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 30 Aug 2021 09:22:12 +1000

> PS: I'll be happy to create PRs if desired.

I'd appreciate that, thanks.

(most of these are changes in old text, but I see no reason not to make improvements where possible)

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Aug 2021 16:56:07 +0200

> (most of these are changes in old text, but I see no reason not to make improvements where possible)

Done that.

Below a few more nits about Section 8:

8.1.1

A malformed request or response is one that is an otherwise valid
sequence of HTTP/2 frames but is invalid due to the presence of
extraneous frames, prohibited fields or pseudo-header fields, the
absence of mandatory fields or pseudo-header fields, the inclusion of
uppercase field names, or invalid field names and/or values (in certain
circumstances; see Section 8.2).

Q: are there any mandatory fields that are not pseudo-header fields?

8.2

To improve efficiency and interoperability, field names MUST be
converted to lowercase when constructing an HTTP/2 message.

Q: I think this is somewhat misleading, it just provides the motivation
why the lowercase format was introduced initially. I would just remove
the sentence and potentially insert a note about lower-casing into the
field name validity statements.

8.3

The prose keeps re-referencing 8.1.1; doing so once (while just
hyperlinking the term "malformed") would be sufficient (I believe this
style of over-referencing is present in other parts of the spece as well).

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Sep 2021 05:39:34 +0200

Hi Julian,

> Q: are there any mandatory fields that are not pseudo-header fields?

We could say "Host" if there's no ":authority", but in general if we
defer to semantics the rules for validating a HEADERS frame, I find
it useful to just give rough examples of what could be covered by
the core spec.
 
> field name validity statements.

Or maybe just turn it like this:

  To improve efficiency and interoperability, HTTP/2 only uses lowercase
  header field names, so all field names MUST be converted to lowercase
  when constructing an HTTP/2 message.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 1 Sep 2021 08:35:49 +0200

> it useful to just give rough examples of what could be covered by

Well, the way it's written had me wonder what HTTP fields can be
mandatory now that control data is in pseudo fields. To call "Host"
mandatoy is just confusing. Maybe the whole statement should be
simplified somewhat.

>    when constructing an HTTP/2 message.

That's somehat better. Maybe:

"To improve compression efficiency and interoperability, HTTP/2 uses
lowercase field names only. All field names MUST be converted to
lowercase when constructing an HTTP/2 message."

(note that also drops one instance of "header")

Best regards, Julian