W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2022

Re: Artart last call review of draft-ietf-httpbis-binary-message-04

From: Martin Thomson <mt@lowentropy.net>
Date: Tue, 31 May 2022 09:18:59 +1000
Message-Id: <4ee62cbf-e46e-472d-b8e4-1bc5a4e2ef19@beta.fastmail.com>
To: "james.ietf@gmail.com" <james.ietf@gmail.com>, art@ietf.org
Cc: draft-ietf-httpbis-binary-message.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
Hi James,

Thanks for the review.

I tried to move the definition of "invalid message" up, but I think that having it in the table of contents is useful enough that having it after Section 3 is necessary.  I get that the repeated references are a little annoying, but once you jump forward, I hope that the content of Section 4 is narrow enough to internalize.

Moving the normative text from Section 6 makes a lot of sense.

I made some other editorial changes as a result of trying to shuffle Section 4 around.  You can see the changes here: 
https://github.com/httpwg/http-extensions/pull/2140
or spelled out https://httpwg.org/http-extensions/binary-artart/draft-ietf-httpbis-binary-message.html (including the changes David suggested)

Cheers,
Martin


On Mon, May 30, 2022, at 23:33, James Gruessing via Datatracker wrote:
> Reviewer: James Gruessing
> Review result: Ready
>
> This is my review of draft-ietf-httpbis-binary-message-04 as part of 
> ART Last Call review.
>
> Overall this is a concisely written document, and although the specification
> makes it clear that its format is distinct from existing framing defined within
> HTTP/2 and HTTP/3 (in addition to borrowing elements from QUIC) readers who are
> not already familiar with these may be at a considerable disadvantage trying to
> understand this document.
>
> Editorial Comments:
>
> Section 3 is quite difficult to grok, and I agree with the suggestions made by
> David Schinazi in his Gen-ART review. However as one additional minor suggestion
> is that references to section 4 within section 3 appear repetitiously, and as
> section 4 doesn't provide specific guidance for each of the invalid message
> scenarios but generic text I'd suggest you include "invalid message" as a
> definition in section 2 that states all usage of the word is applicable to
> section 4.
>
> Section 6 - As a suggestion I would propose the normative text around
> pseudo-fields instead be placed within appropriate sub-sections of section 3,
> keeping section 6 exclusively informative.
>
> Asides from this there are no further nits or major issues to mention.
Received on Monday, 30 May 2022 23:19:30 UTC

This archive was generated by hypermail 2.4.0 : Monday, 30 May 2022 23:19:32 UTC