- From: Lars Eggert via Datatracker <noreply@ietf.org>
- Date: Mon, 03 Jan 2022 00:31:28 -0800
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-http2bis@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net, mnot@mnot.net
Lars Eggert has entered the following ballot position for draft-ietf-httpbis-http2bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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
Received on Monday, 3 January 2022 08:31:43 UTC