Ballot for draft-ietf-httpbis-http2bis
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Thanks for this eminently readable document. I do have one piffling little question. Appendix A ends with | Note: This list was assembled from the set of registered TLS | cipher suites when [RFC7540] was developed. This list includes | those cipher suites that do not offer an ephemeral key exchange | and those that are based on the TLS null, stream, or block | cipher type (as defined in Section 6.2.3 of [TLS12]). | Additional cipher suites with these properties could be | defined; these would not be explicitly prohibited. This text leaves me with the strong impression that the authors think it would be in exceedingly poor taste to make use of additional cipher suites with these properties, even if you can’t a priori forbid them. Then again you haven’t even explicitly prohibited the ones you do list, just said that implementations MAY reject them. What I’m getting around to here, is the question of whether you can and should be a little more concrete about the “in exceedingly poor taste” thing if indeed that is what you intend. E.g., something like “although future cipher suites can’t be explicitly listed here for obvious reasons, implementations may wish to consider giving such future suites equivalent treatment.” The language about “explicitly prohibited” also makes me wonder if you believe you’ve explicitly prohibited the suites you list. As mentioned above, you haven’t, strictly speaking.
Thank you to Sean Turner for the SECDIR review. ** Section 2. Editorial. Could this section provide a summary of what’s getting obsoleted from RFC7540 in one place? The text already explicitly says that the RFC7540 prioritization scheme is deprecated. Should the text also note that the upgrade mechanism of HTTP2-Settings header field (per Section 3.2 of RFC7540) is obsolete? This detail is buried in Section 11 and Section 3.1 could be clearer. ** Section 5.3.2 Servers SHOULD use other contextual information in determining priority of requests in the absence of any priority signals. Given that “the prioritization signaling in RFC7540 [RFC7540] was not successful.” Can more be said to guide implementers on what contextual information could be used? ** Section 6.5.1. Editorial. After Figure 7, should this section have the boiler plate text “The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in Section 4”? ** Section 8.1.1. Per Section 6.1, padding octets must be zero and a recipient may treat non-zero padding as a connection error (no change in guidance from RFC7540). In this new section, would it be worth reiterating this guidance and categorizing non-zero padding as a malformed frame?
Thank you for the work put into this document. As a side note, I am impressed that the WG only needed 6 revisions for such a major document! The introduction section is also crystal clear and to the points. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Mark Nottingham for the (short) shepherd's write-up including the section about the WG consensus (even if very terse). I hope that this helps to improve the document, Regards, -éric -- Section 3.1 -- Beside the history associated to "h2c", I really wonder why it is described in the document (just out of curiosity). -- Section 5.1.1 -- In "The identifier of a newly established stream MUST be numerically greater", is the increment interval 1 or can it be any positive non-nul integer ? -- Section 5.2.1 -- In the bullet 1. in "Both types of flow control", it is unclear to me what "both" refers to especially after reading the previous "allow a variety of flow-control algorithms", which hints to several (and not 2) mechanisms. Or is it per direction ? -- Section 6.1 -- The SEC AD will obviously have the final word on this but wouldn't random padding be more secure (at the expense of later compression of course) ? -- Section 6.7 -- In figure 9, suggest to indicate that the Length is 8 octets. -- Section 9.1 -- In "Clients SHOULD NOT open more than one HTTP/2 connection", should some words be added when the client has multiple interfaces (e.g., Wi-Fi & mobile) ? I understand that this is probably beyond HTTP... -- Appendix A -- Some justifications (beyond the note at the end of the appendix) would be welcome. Should a pointer to section 9.2.2 be added ?
Thanks for addressing my discuss point, and those of my Comment-level points for which a change was appropriate!
Section 3.1. , paragraph 6, comment: > The "h2c" string was previously used as a token for use in the > HTTP Upgrade mechanism's Upgrade header field (Section 7.8 of > [HTTP]). This usage was never widely deployed, and is no longer > specified in this document. Does that mean its deprecated? Since this RFC obsoletes the earlier specs, it would be good to clarify what that means for anything that got dropped. Thanks to Dan Romascanu for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/EwzPC-Ttz_9fX8_I3tvw-Din_GQ). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3.1. , paragraph 7, nit: > The "h2c" string is reserved from the ALPN identifier space but > describes a protocol that does not use TLS. The security > properties of this protocol do not hold unless TLS is used; see > Section 10. s|this protocol|HTTP/2| for clarity? Section 8.2.1. , paragraph 2, nit: - The definitions of field names and values in HTTP prohibits some - - Section 8.4. , paragraph 2, nit: - HTTP/2 allows a server to pre-emptively send (or "push") responses - - Section 5.1. , paragraph 33, nit: > as an error after receiving an acknowledgement of the settings. Other things > ^^^^^^^^^^^^^^^ Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Section 5.5. , paragraph 3, nit: > r is not obligated to verify padding but MAY treat non-zero padding as a con > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). Section 6.1. , paragraph 2, nit: > r is not obligated to verify padding but MAY treat non-zero padding as a con > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). Section 6.2. , paragraph 12, nit: > nal frames for that stream, with the exception of PRIORITY. However, after s > ^^^^^^^^^^^^^^^^^^^^^ Consider using "except" or "except for". Section 6.5. , paragraph 8, nit: > INGS frame does not receive an acknowledgement within a reasonable amount of > ^^^^^^^^^^^^^^^ Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Section 6.5.2. , paragraph 5, nit: > r is not obligated to verify padding but MAY treat non-zero padding as a con > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). Section 6.5.2. , paragraph 8, nit: > this setting and has received acknowledgement MUST treat the receipt of a PU > ^^^^^^^^^^^^^^^ Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Section 6.6. , paragraph 23, nit: > l activity is not possible, with the exception of idempotent actions like HTT > ^^^^^^^^^^^^^^^^^^^^^ Consider using "except" or "except for". Section 7. , paragraph 16, nit: > Z', ASCII 0x41 to 0x5a). * With the exception of pseudo-header fields (Sectio > ^^^^^^^^^^^^^^^^^^^^^ Consider using "except" or "except for". Section 8.1. , paragraph 10, nit: > ilers". An intermediary transforming a HTTP/1.x message to HTTP/2 MUST remov > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Section 8.1. , paragraph 11, nit: > kie header field [COOKIE] uses a semi-colon (";") to delimit cookie-pairs (o > ^^^^^^^^^^ This word is normally spelled as one. Section 8.1.1. , paragraph 6, nit: > ion 7.1 of [HTTP]). The recipient of a HTTP/2 request MUST ignore the Host h > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Document references draft-ietf-httpbis-semantics-18, but -19 is the latest available revision. Document references draft-ietf-httpbis-cache-18, but -19 is the latest available revision. Reference [TLS12] to RFC5246, which was obsoleted by RFC8446 (this may be on purpose). Document references draft-ietf-httpbis-priority-10, but -11 is the latest available revision. Document references draft-ietf-httpbis-messaging-18, but -19 is the latest available revision. These URLs in the document did not return content: * http://w2spconf.com/2011/papers/websocket.pdf These URLs in the document can probably be converted to HTTPS: * http://dx.doi.org/10.6028/NIST.FIPS.186-4 * http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
Thanks for this document. Please address Joerg's TSVART review. Although it doesn't use an RFC2119 keyword, the reference to httpbis-priority in Sec. 5.3.2 feels normative to me. There's no need to argue it out with me, but as both drafts are done it seems harmless to make it a normative reference (assuming you're going for PS).
Not much to say - another well written document update - I only reviewed the diff. One minor comment/nit, Section 5.3.1. Background of Priority in HTTP/2 HTTP/2 included a rich system for signaling priority of requests. However, this system proved to be complex and it was not uniformly implemented. Given that this document obsoletes RFC7540 and becomes the reference for HTTP/2 then I would suggest that this section would be better introduced as "RFC7540 included a rich system ..." Regards, Rob