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

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.

On Tue, Jan 4, 2022, at 03:46, Roman Danyliw via Datatracker wrote:
> ** 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.

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.

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

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.

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

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.

Received on Monday, 3 January 2022 23:42:21 UTC