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

Lars Eggert via Datatracker <noreply@ietf.org> Mon, 03 January 2022 08:34 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF653A0CAD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 3 Jan 2022 00:34:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si3CTk4RmTt1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 3 Jan 2022 00:34:10 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E34F3A0CB0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 3 Jan 2022 00:34:09 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1n4Ikr-0000Xb-O8 for ietf-http-wg-dist@listhub.w3.org; Mon, 03 Jan 2022 08:31:45 +0000
Resent-Date: Mon, 03 Jan 2022 08:31:45 +0000
Resent-Message-Id: <E1n4Ikr-0000Xb-O8@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <noreply@ietf.org>) id 1n4Ikp-0000WF-NS for ietf-http-wg@listhub.w3.org; Mon, 03 Jan 2022 08:31:43 +0000
Received: from mail.ietf.org ([4.31.198.44]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <noreply@ietf.org>) id 1n4Ikn-0006lJ-DT for ietf-http-wg@w3.org; Mon, 03 Jan 2022 08:31:43 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F8A3A0CA5; Mon, 3 Jan 2022 00:31:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
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
X-Test-IDTracker: no
X-IETF-IDTracker: 7.41.0
Auto-Submitted: auto-generated
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <164119868742.30571.5880690585775884792@ietfa.amsl.com>
Date: Mon, 03 Jan 2022 00:31:28 -0800
Received-SPF: pass client-ip=4.31.198.44; envelope-from=noreply@ietf.org; helo=mail.ietf.org
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1n4Ikn-0006lJ-DT 27d60822dcd3ce289fc8ccf418ac6b3b
X-Original-To: ietf-http-wg@w3.org
Subject: Lars Eggert's No Objection on draft-ietf-httpbis-http2bis-06: (with COMMENT)
Archived-At: <https://www.w3.org/mid/164119868742.30571.5880690585775884792@ietfa.amsl.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/39685
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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