Lars Eggert's Discuss on draft-ietf-httpbis-bcp56bis-14: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-httpbis-bcp56bis-14: Discuss

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The IANA review of this document seems to not have concluded yet; I am holding
a DISCUSS for IANA until it has.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2. , paragraph 5, comment:
>    *  uses an ALPN protocol ID [RFC7301] that generically identifies
>       HTTP (e.g., "http/1.1", "h2", "h2c"), or

Might want to mention "h3" as part of the examples.

-------------------------------------------------------------------------------
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 2.1. , paragraph 4, nit:
> ric/application-specific split allows a HTTP message to be handled by common
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour". (Also elsewhere.)

Section 4. , paragraph 2, nit:
> mple, HTTP/2's multiplexing), this ought be noted. Applications using HTTP MU
>                                    ^^^^^^^^
Did you mean "ought to be"?

Section 4.4.1. , paragraph 6, nit:
> s can also be defined. When defining an URI scheme for an application using H
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 4.4.2. , paragraph 2, nit:
> uests don't get sent to a "normal" Web site is likely to fail. * Features th
>                                    ^^^^^^^^
Nowadays, it's more common to write this as one word. (Also elsewhere.)

Section 4.4.3. , paragraph 2, nit:
> trieval semantics allow caching, side-effect free linking and underlies many
>                                  ^^^^^^^^^^^
Did you mean "side effect" (=adverse effect, unintended consequence)? Open
compounds are not hyphenated.

Section 4.5. , paragraph 3, nit:
> nt; doing so avoids encoding overhead and URL length limits in implementation
>                                      ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 4.5. , paragraph 4, nit:
> el a need to allow POST queries ought consider allowing both methods. Applica
>                                 ^^^^^^^^^^^^^^
Did you mean "ought to consider"?

Section 7.2. , paragraph 9, nit:
> Best Current Practice in the early 2000's, based on the concerns facing prot
>                                    ^^^^^^
Apostrophes aren't needed for decades.

Document references draft-ietf-httpbis-messaging-17, but -18 is the latest
available revision.

Obsolete reference to RFC5246, obsoleted by RFC8446 (this may be on purpose).

These URLs in the document can probably be converted to HTTPS:
 * http://httpwg.github.io/