Reviewer: Sean Turner
Review result: Has Nits
Ready with nits. And by nits I mean editorial nits. I could not think of
anything security/privacy-related.
BTW - this I-D was a pleasure to read. Thanks to everybody who made it that way.
I read the GENART and TSVDIR reviews so I hopefully did not duplicate anything
they raised. I will admit that I did not just focus on new text. If, as a
result, I have unwittingly stumbled onto a hard fought WG consensus, then I do
not want my questions/comments to be see as restarting that discussion.
s3.3 (editorial): Even though s3 is clear that this section is about starting
with http, I would have thought that the last sentence in para 2 would have
been the very 1st sentence in the section to make that point very clear in case
it missed in s3.
s4.1 (editorial): s/Frames defined in this documented/
Frames defined in this document
s4.1 (editorial): s/Implementations MUST ignore and discard any frame that has
a type that is unknown./Implementations MUST ignore and discard frames of
unknown types.
s4.1 (editorial): s/Unused flags are those that have no defined semantics for a
particular frame type, and MUST be ignored and MUST be left unset (0x0) when
sending./Unused flags are those that have no defined semantics for a particular
frame type; unused flags MUST be ignored and MUST be left unset (0x0) when
sending.
s4.3 (editorial): s/END_HEADERS flag cleared/END_HEADERS flag unset
“unset” is used in s4.1.
s5 (editorial): s/Streams can be established and used unilaterally or shared by
either the client or server./Streams can be established and used unilaterally
or shared by either endpoint.
5.2.1/s5.2.2 (question): s5.2.1 indicates flow control cannot be disabled, but
in s5.2.2 you explain how to do exactly that. In s5.2.1, are you really saying
you can’t skip implementing the flow control mechanism and frames related to
connection control, i.e., WINDOW_UPDATE?
s5.3 (compliment): I think this is a great way to describe deprecating features
that did not work.
s7 (question): Since we already have h3, is it worth adding an h3 required
error?
s8.3.1 (question): s8.3.1 includes this:
The recipient of a HTTP/2 request MUST ignore
the Host header field if :authority is present.
And, it also includes this:
A server SHOULD treat a request as malformed if
it contains a Host header field that identifies a
different entity to the :authority pseudo-header field.
If I follow the MUST, then is the SHOULD ever followed?
s9.2.1, last para, 1st sentence (editorial): Should the DHE suites reference
[TLS13] or [TLS1.2] in the TLS1.2 section?
s11 (confirmation, and I guess this is somewhat related to the last GENART
comment): Because you obsolete RFC 7540 with this I-D, I am going with the
assumption that the obsoleting is about the protocol and not about the
registries. As a result, there’s no need to copy the IANA instructions for
what’s in 7540 to this I-D.
s12.1 (question): Is it worth referring to 8446bis instead of RFC 8446?
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
