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

[Francesca Palombini <[e-mail]>]

James: thank you very much for this review, and authors thank you for the updates addressing James’ comments.

Francesca

From: James <[e-mail]>
Date: Tuesday, 31 May 2022 at 23:33
To: Martin Thomson <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Artart last call review of draft-ietf-httpbis-binary-message-04
Hi Martin,
These changes on top of those you did as part of David's suggestions look good, and I've got nothing more to bring up.

Thanks,

- J

> On 31 May 2022, at 01:18, Martin Thomson <[e-mail]> wrote:
>
> 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-ae1ca1949cfff524&q=1&e=441857bb-7219-4935-9fdc-7314b702c0ec&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fpull%2F2140
> or spelled out https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a2d79805b1bea469&q=1&e=441857bb-7219-4935-9fdc-7314b702c0ec&u=https%3A%2F%2Fhttpwg.org%2Fhttp-extensions%2Fbinary-artart%2Fdraft-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.