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

James Gruessing via Datatracker <noreply@ietf.org> Mon, 30 May 2022 13:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 339DAC15C0AF; Mon, 30 May 2022 06:33:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: James Gruessing via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-httpbis-binary-message.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165391763820.5057.1266957641248861982@ietfa.amsl.com>
Reply-To: James Gruessing <james.ietf@gmail.com>
Date: Mon, 30 May 2022 06:33:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/UTGaEWDXHSFP8RokAwXT3h7XCgg>
Subject: [art] Artart last call review of draft-ietf-httpbis-binary-message-04
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.34
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2022 13:33:58 -0000

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.