On Mon, 22 Nov 2021 at 16:09, Dan Romascanu via Datatracker <nore...@ietf.org> wrote: > > Reviewer: Dan Romascanu > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-httpbis-http2bis-06 > Reviewer: Dan Romascanu > Review Date: 2021-11-22 > IETF LC End Date: 2021-11-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This document is Ready from a GenART point of view, with a number of minor > issues which I recommend to be clarified before approval. > > Major issues: > > Minor issues: > > 1. It seems to me that a better clarification of the issues related to > backward > compatibility is needed. RFC 7540 included the following sentence in the > Abstract: > > > This specification is an alternative to, but does not obsolete, the > HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. > > Why was this taken out?
This was requested as https://github.com/httpwg/http2-spec/issues/889 and removed in https://github.com/httpwg/http2-spec/pull/891. Those issues don't do a good job laying out the rationale, but the core specifications have split out the semantics from the messaging formats. This means that it no longer makes sense to claim that HTTP/2 (a messaging spec) doesn't change the semantics: it's implied by the new core specifications drafts. > 2. I noticed changes in Section 5.5 that describes the mechanisms for > extending > HTTP/2. > > RFC 7540 > > > Extensions that could change the semantics of existing protocol > components MUST be negotiated before being used. For example, an > extension that changes the layout of the HEADERS frame cannot be used > until the peer has given a positive signal that this is acceptable. > In this case, it could also be necessary to coordinate when the > revised layout comes into effect. Note that treating any frames > other than DATA frames as flow controlled is such a change in > semantics and can only be done through negotiation. > > draft-ietf-httpbis-http2bis-06 > > >Extensions SHOULD avoid changing protocol elements defined in this > document or elements for which no extension mechanism is defined. > This includes changes to the layout of frames, additions or changes > to the way that frames are composed into HTTP messages (Section 8.1), > the definition of pseudo-header fields, or changes to any protocol > element that a compliant endpoint might treat as a connection error > (Section 5.4.1). > > An extension that changes existing elements MUST be negotiated before > being used. For example, an extension that changes the layout of the > HEADERS frame cannot be used until the peer has given a positive > signal that this is acceptable. In this case, it could also be > necessary to coordinate when the revised layout comes into effect. > For example, treating frames other than DATA frames as flow > controlled requires a change in semantics that both endpoints need to > understand, so this can only be done through negotiation. > > This seems to me like a change as the SHOULD recommendation is dropped. Is > this > just editorial, or is it rather a more substantive change that should be > mentioned in Appendix B. You say that SHOULD is dropped, but was it not added? In either case, yes, I think we should probably add it. I think the SHOULD was implied by the prior text, but it was never anywhere close to explicitly stated, and we should probably do so. > 3. RFC 7540 included a section (9.1.2) about the 421 Status Code, including > description of behavior of clients and proxies. This was eliminated in the new > version, which includes only one reference to servers that do not wish clients > to reuse connections. Was the rest of former section 9.1.2 considered > unnecessary? Why? Status code 421 is now defined in the -semantics draft of the core specifications: https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#status.421. > 4. Should not be [RFC7540] be a Normative Reference? It is referred to around > 20 times in the document. The discussion about priority signaling in 5.3 seems > to require reading text from RFC 7540 that was not taken in this document. > Also > in Section 5.5 > > > Registries > for managing these extension points are defined in Section 11 of > [RFC7540]. > > Nits/editorial comments: The section in 5.3 does not require reading from RFC 7540. The necessary parts required for implementation of the specification are present in this draft. RFC 7540 is necessary to understand why these elements are the way they are, but that seems an informative use, not a normative one. The registries seems like a better case. I think I'll have to defer to the more experienced RFC editors here: I'm not sure whether the deference to the registries defined in RFC 7540 requires us to make the reference normative. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
