- From: Martin Thomson <mt@lowentropy.net>
- Date: Tue, 04 Jan 2022 10:21:24 +1100
- To: "Lars Eggert" <lars@eggert.org>, "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-http2bis@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, "Mark Nottingham" <mnot@mnot.net>
Hi Lars, Nothing controversial there, thanks for the grammar check :) In case you care to review: https://github.com/httpwg/http2-spec/pull/1006 On Mon, Jan 3, 2022, at 19:31, Lars Eggert via Datatracker wrote: > 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 23:21:59 UTC