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

Genart last call review of draft-ietf-httpbis-binary-message-04

From: David Schinazi via Datatracker <noreply@ietf.org>
Date: Tue, 24 May 2022 06:59:38 -0700
To: <gen-art@ietf.org>
Cc: draft-ietf-httpbis-binary-message.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
Message-ID: <165340077863.8642.7728497225957989470@ietfa.amsl.com>
Reviewer: David Schinazi
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-binary-message-04
Reviewer: David Schinazi
Review Date: 2022-05-24
IETF LC End Date: 2022-06-03
IESG Telechat date: Not scheduled for a telechat

Summary: Well written concise draft, apart from section 3 - see below.

Major issues: None

Minor issues: While this is an editorial comment, I'm raising it as a minor
issue because it significantly hampers comprehension in my mind. I find Section
3 incredibly hard to reason about. In order to get to the actual format, the
reader is forced to repeatedly jump forward and backwards using a notepad to
track state. The draft seems somewhat akin to a game like Myst if you'll pardon
the analogy. I believe that this could be resolved by the editors without too
much work by doing the following: - keep the preface to Section 3 as-is, it
does a great job of introducing the concepts - split up the "Message with
Known-Length" diagram into two diagrams, one for known-length request and one
for known-length response - similarly split up "Indeterminate-Length Message"
diagram - reorder diagrams to avoid forward references, for example
"Known-Length Field Section" should appear before "Message with Known-Length"
since the latter relies on the former - define every field using a separate
bullet following the style from RFC 9000. Currently the draft uses the
notational conventions from RFC 9000 albeit incorrectly, for example
"Known-Length Informational Response" does not appear in all "Message with
Known-Length" structs but the square brackets indicating optionality are
missing.

While this is fundamentally an editorial issue that is theoretically the
purview of the editors, such readability difficulties are worth discussing by
the GEN Area Director if they agree with this assessment.

Nits/editorial comments: None
Received on Tuesday, 24 May 2022 13:59:51 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 24 May 2022 13:59:52 UTC