Subject: Roman Danyliw's No Objection on draft-ietf-httpbis-http2bis-06: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 03 Jan 2022 08:46:44 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-httpbis-http2bis-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Sean Turner for the SECDIR review.

** Section 2.  Editorial.  Could this section provide a summary of what’s
getting obsoleted from RFC7540 in one place?  The text already explicitly says
that the RFC7540 prioritization scheme is deprecated.  Should the text also
note that the upgrade mechanism of HTTP2-Settings header field (per Section 3.2
of RFC7540) is obsolete?  This detail is buried in Section 11 and Section 3.1
could be clearer.

** Section 5.3.2
  Servers SHOULD use other contextual information in determining
  priority of requests in the absence of any priority signals.

Given that “the prioritization signaling in RFC7540 [RFC7540] was not
successful.”  Can more be said to guide implementers on what contextual
information could be used?

** Section 6.5.1.  Editorial.   After Figure 7, should this section have the
boiler plate text “The Length, Type, Unused Flag(s), Reserved, and Stream
Identifier fields are described in Section 4”?

** Section 8.1.1.  Per Section 6.1, padding octets must be zero and a recipient
may treat non-zero padding as a connection error (no change in guidance from
RFC7540).  In this new section, would it be worth reiterating this guidance and
categorizing non-zero padding as a malformed frame?

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 04 Jan 2022 10:41:47 +1100

Thanks for reviewing Roman,

I've made some changes: https://github.com/httpwg/http2-spec/pull/1007

Some things are not exactly as you might have imagined, so see below.

> of RFC7540) is obsolete?  This detail is buried in Section 11 and Section 3.1

I've amended the note in Section 1 to refer to the comprehensive list of changes.  It's a short enough list that I'm almost inclined to move it into Section 2 wholesale, rather than try to repeat it.

The previous use of "contextual" says: 

> A good prioritization scheme benefits from the application of contextual knowledge such as the content of resources, how resources are interrelated, and how those resources will be used by a peer.  

That's in the introduction of the same section (5.3), so I think that's enough.

> categorizing non-zero padding as a malformed frame?

I'm not 100% on what you refer to here.  Do you refer to this text?

>  For example, 204 or 304 responses contain no content, as does the response to a HEAD request. A response that is defined to have no content, as described in Section 6.4.1 of [HTTP], MAY have a non-zero content-length header field, even though no content is included in DATA frames.

That is talking about a field (content-length) that HTTP/1.1 sometimes uses for marking the length of messages.  There is no padding involved here.  This is just saying that if you receive a 304 response, it might include a content-length, but that content-length doesn't match the length of the content (that is, the number of bytes you receive in DATA frames).

You can pad those DATA frames, but it probably wouldn't help to bring that detail in.