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
tsv-art@ietf.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.