[Tsv-art] Tsvart last call review of draft-ietf-httpbis-bcp56bis-12
David Black via Datatracker <email@example.com> Wed, 14 July 2021 01:23 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C6B3A0DEB; Tue, 13 Jul 2021 18:23:55 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: David Black via Datatracker <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: David Black <email@example.com>
Date: Tue, 13 Jul 2021 18:23:55 -0700
Subject: [Tsv-art] Tsvart last call review of draft-ietf-httpbis-bcp56bis-12
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 14 Jul 2021 01:23:55 -0000
Reviewer: David Black Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC firstname.lastname@example.org if you reply to or forward this review. This draft provides guidance on application use of HTTP - it is a complete replacement of RFC 3205, reflecting considerable changes to HTTP and the associated ecosystem over the nearly 2 decades since publication of RFC 3205. The draft is clear and well-written - the one Issue that I found is a relatively minor one concerning a reference. Most of the material in this draft is about application-level use of HTTP. The one core transport topic, transport ports, is covered in Section 4.4.3, which is a fine example of how to deal with transport ports. That section contains a mercifully short discussion that includes the specific ports used by HTTP (tcp/80 and tcp/443) complemented by a reference to RFC 7605 for further guidance. I tip my virtual hat in the author's direction for arranging for that section to be numbered 4.4.3 ;-). I did notice one non-Transport ISSUE of potential concern - Section 4.3 on Specifying Client Behavior leads off with these two paragraphs: An application's expectations for client behaviour ought to be closely aligned with those of Web browsers, to avoid interoperability issues when they are used. One way to do this is to define it in terms of [FETCH], since that is the abstraction that browsers use for HTTP. Based on this text, I was surprised to see that not only is [FETCH] an informative reference, but that it is also a reference to a non-archival source (WHATWG, "Fetch - Living Standard"). Given the prominent use of that citation, I'd think that the reference ought to be a normative reference to an archival document, perhaps complemented with advice on where to find updated versions of that document.
- [Tsv-art] Tsvart last call review of draft-ietf-h… David Black via Datatracker
- Re: [Tsv-art] Tsvart last call review of draft-ie… Mark Nottingham