- 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