AD review for bcp56bis

[fpalombini]

• [x] 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."

• [x] 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.

• [x] 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.

• [x] 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)

• [x] 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?

• [x] 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"?

• [x] 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.

• [x] 8. -----

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

FP: nit - s/using/use

• [x] 9. -----

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

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

• [x] 10. -----

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

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

• [x] 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

• [x] 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.

[mnot]

I've mentioned 3205 in the abstract, although I'll once again register my scepticism about the utility of doing so, considering that the same information is a few lines above in the document header.

[mnot]

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

This document shies away from most requirements, since it's giving advice to protocol designers, rather than actually specifying a protocol. This was discussed at some length in community feedback to work on the IAB 'for the users' draft.

[mnot]

@fpalombini thanks so much - very helpful feedback. I think these are all addressed.

[fpalombini]

Thank you @mnot for addressing everything :) I assume you will close this when submitting the update?

[mnot]

Should I publish an update now, or wait until LC is done (tomorrow, I think)?

[fpalombini]

Might be worth waiting for the Genart and Secdir reviews, which are due tomorrow... but either way, whatever you prefer.