AD review of draft-ietf-httpbis-bcp56bis-12

[Francesca Palombini <[e-mail]>]

Hi,

Thank you for this well written and easy to read document. Here is my review: please handle these minor comments together with the Last Call ones. I have opened an issue with the text below in the github: https://github.com/httpwg/http-extensions/issues/1568

Francesca

1. -----

As noted by the shepherd, the document should point to 3205 in the abstract and in the introduction to mention it obsoletes it. From https://www.ietf.org/standards/ids/checklist/: "If your document obsoletes or updates a previous RFC, then:
* Say so in the abstract.
* Explain in the introduction how and why this document updates or obsoletes an earlier document."

2. -----

   *  updates or modifies the IANA registries defined for HTTP.

FP: Not completely clear what "update or modify" means. What is the difference between updating and modifying an IANA registry? And I assume in this case updating or modifying only aims to indicate changes to the registry as a whole (for example, adding a new column, changing all values etc), and registering a new value is not considering modifying a registry, is this assumption correct? In any case, it would be good to clarify.

3. -----

   [I-D.ietf-httpbis-semantics], but also other specifications as
   appropriate).

FP: I understand the motivation for it, but I don't think this last part of the sentence helps the reader, because of its vagueness.

4. -----

   aspects of the protocol's operation; or, it might want to use a
   different set of methods.

FP: "different set of methods" than those it should according to ... (Might use some clarification)

5. ----

   Doing so brings more freedom to modify protocol operations, but loses
   at least a portion of the benefits outlined above, as most HTTP


FP: the benefits mentioned here are not specified above, is it those mentioned in section 3.3?

6. -----

   Applications using HTTP should not statically require HTTP features
   that are usually negotiated to be supported by clients.  For example,

FP: Since this affect interoperability, why is the "should not" not BCP 14 "SHOULD NOT"?

7. -----

   This means that in most cases, specifications for applications that
   use HTTP won't contain its URLs; 

FP: I am not sure about what "its" refers to.

8. -----

      using an already existing one if it's appropriate (e.g., HostMeta
      [RFC6415]).

FP: nit - s/using/use

9. -----

   First, status codes are often generated by components other the the

FP: nit - replace the first "the" with "then"

10. -----

   Common syntactic conventions for message contents include JSON
   [RFC8259], XML [XML], and CBOR [RFC7049]

FP: s/7049/8949 (and update reference)

11. -----

   either in the response's content or in a separate header field.  When
   this happens, the relationship between HTTP caching and that lifetime
   need to be carefully considered, since the response will be used as

FP. nit - s/need/needs

12. -----

   Section 4.4.2 requires support for 'https' URLs, and discourages the
   use of 'http' URLs, to provide authentication, integrity and
   confidentiality, as well as mitigate pervasive monitoring attacks.

FP: Section 4.4.2 does not require, but RECOMMENDS the use of https.