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 <mt@xxxxxxxxxxxxxx> 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://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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
