Subject: Lars Eggert's No Objection on draft-ietf-httpbis-http2bis-06: (with COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Mon, 03 Jan 2022 00:31:28 -0800

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

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 04 Jan 2022 10:21:24 +1100

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:
>  * 
> http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf