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

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

Lars Eggert has entered the following ballot position for
draft-ietf-httpbis-semantics-16: 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/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-semantics/



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

Dale Worley's GenART review hasn't been responded to yet.

Section 3. , paragraph 2, comment:
>    HTTP was created for the World Wide Web (WWW) architecture and has
>    evolved over time to support the scalability needs of a worldwide
>    hypertext system.  Much of that architecture is reflected in the

Given the degree to which HTTP is now used a a transport for things other than
the HTML web, the last part of this sentence seems dated.

Section 5.6.7. , paragraph 25, comment:
>    Recipients of a timestamp value in rfc850-date format, which uses a

Suggest to add an actual reference to RFC850.

Section 10.2.2. , paragraph 9, comment:
>    A recipient with a clock that receives a response with an invalid
>    Date header field value MAY replace that value with the time that
>    response was received.

"Invalid" as in not well-formed, or as in inaccurate?

Possible DOWNREF from this Standards Track doc to [Welch]. If so, the IESG
needs to approve it.

-------------------------------------------------------------------------------
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.

"Table of Contents", paragraph 1, nit:
> Table of Contents

Not all section headings consistently use title case.

Section 1.2. , paragraph 4, nit:
>    HTTP/2 ([RFC7540]) introduced a multiplexed session layer on top of

It's unusual to put a reference (also) in parenthesis; suggest to remove the
parenthesis here and check similar occurrences throughout the document.

Section 3.8. , paragraph 2, nit:
>    requests.  Any client or server MAY employ a cache, though a cache
>    cannot be used while acting as a tunnel.

cannot -> MUST NOT?

Section 3.8. , paragraph 7, nit:
-    caching to optimise regional and global distribution of popular
-                     ^
+    caching to optimize regional and global distribution of popular
+                     ^

Section 5.6.7. , paragraph 2, nit:
-    implementations, all three are defined here.  The preferred format is
-                                                      ^^^^^^^^^
+    implementations, all three are defined here.  The RECOMMENDED format is
+                                                      ^^^^^^^^^^^

Section 5.6.7. , paragraph 4, nit:
-    An example of the preferred format is
-                      ^^^^^^^^^
+    An example of the RECOMMENDED format is
+                      ^^^^^^^^^^^

Section 5.6.7. , paragraph 10, nit:
-    Preferred format:
+   RECOMMENDED format:

Section 8.3.1. , paragraph 6, nit:
-    the first is preferred for consistency (the "charset" parameter value
-                 ^^^^^^^^^
+    the first is RECOMMENDED for consistency (the "charset" parameter value
+                 ^^^^^^^^^^^

Section 8.8.3. , paragraph 9, nit:
-    preferable to send Etag as a header field unless the entity-tag is
-    ^^^^^^^^^^
+    RECOMMENDED to send Etag as a header field unless the entity-tag is
+    ^^^^^^^^^^^

Section 8.8.4. , paragraph 6, nit:
-    In other words, the preferred behavior for an origin server is to
-                        ^^^^^^^^^
+    In other words, the RECOMMENDED behavior for an origin server is to
+                        ^^^^^^^^^^^

Section 11.6.1. , paragraph 10, nit:
-    Some user agents do not recognise this form, however.  As a result,
-                                   ^
+    Some user agents do not recognize this form, however.  As a result,
+                                   ^

Section 14.1.1. , paragraph 2, nit:
-    following gramar is generic: each range unit is expected to specify
+    following grammar is generic: each range unit is expected to specify
+                 +

Section 15.5.5. , paragraph 2, nit:
-    permanent; the 410 (Gone) status code is preferred over 404 if the
-                                             ^^^^^^^^^
+    permanent; the 410 (Gone) status code is RECOMMENDED over 404 if the
+                                             ^^^^^^^^^^^

"B.2. ", paragraph 9, nit:
-    comma from the allowed set of charaters for a host name in received-
+    comma from the allowed set of characters for a host name in received-
+                                       +

Section 1.1. , paragraph 3, nit:
> sual to put a reference (also) in parenthesis; suggest to remove the parenth
>                                ^^^^^^^^^^^^^^
Did you mean "in parentheses"? "parenthesis" is the singular.

Section 1.1. , paragraph 3, nit:
> erence (also) in parenthesis; suggest to remove the parenthesis here and chec
>                               ^^^^^^^^^^^^^^^^^
The verb "suggest" is used with the gerund form.

Section 2.4. , paragraph 2, nit:
> the degree to which HTTP is now used a a transport for things other than the
>                                      ^^^
Two determiners in a row. Choose either "a" or "a".

Section 5.6.3. , paragraph 3, nit:
>  )) ; e.g., Jun 2 HTTP-date is case sensitive. Note that Section 4.2 of [Cach
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 5.6.4. , paragraph 4, nit:
>  describe and route the message, a headers lookup table of key/value pairs fo
>                                    ^^^^^^^
An apostrophe may be missing.

Section 5.6.4. , paragraph 6, nit:
> nbounded stream of content, and a trailers lookup table of key/value pairs f
>                                   ^^^^^^^^
An apostrophe may be missing.

Section 6.2. , paragraph 6, nit:
> located within a _trailer section_ are are referred to as "trailer fields" (o
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 7.3.2. , paragraph 2, nit:
> age with a field value that is the lesser of a) the received value decrement
>                                    ^^^^^^
Use "least", "lessest", "littlest" to express an extreme with this adjective.

Section 14.1. , paragraph 2, nit:
> n use three-digit integer values outside of that range (i.e., 600..999) for
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 14.4. , paragraph 8, nit:
> ubsections below, if the field would have been sent in a 200 (OK) response to
>                                ^^^^^^^^^^^^^^^
Did you mean "had been"?

Section 15.4. , paragraph 19, nit:
>  what (if any) content codings would have been accepted in the request. On t
>                                ^^^^^^^^^^^^^^^
Did you mean "had been"?

Section 16. , paragraph 1, nit:
> d. Registrations happen on a "First Come First Served" basis (see Section 4.4
>                                     ^^^^
It seems that a comma is missing.

Section 19.1. , paragraph 3, nit:
> Range units are compared in a case insensitive fashion. (Section 14.1) The p
>                               ^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 19.1. , paragraph 16, nit:
> ferring to RFC 723x. * Remove acknowledgements specific to RFC 723x. * Move
>                               ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 19.1. , paragraph 16, nit:
> pecific to RFC 723x. * Move "Acknowledgements" to the very end and make them
>                              ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

"Appendix A. ", paragraph 18, nit:
> s/6>) * In Section 16.6.1, advise to make new content codings self-descriptiv
>                                   ^^^^^^^
Did you mean "making"? Or maybe you should add a pronoun? In active voice,
"advise" + "to" takes an object, usually a pronoun.

"C.3. ", paragraph 1, nit:
> , RFC 7234, and RFC 7235. The acknowledgements within those documents still
>                               ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Uncited references: [RFC2145], [RFC7617], [RFC7234], [RFC2617].

Obsolete reference to RFC2145, obsoleted by RFC7230 (this may be on purpose).

Obsolete reference to RFC2068, obsoleted by RFC2616 (this may be on purpose).

These URLs point to tools.ietf.org, which is being deprecated:
 * https://tools.ietf.org/html/draft-ietf-httpbis-messaging-16
 * https://tools.ietf.org/html/draft-ietf-httpbis-cache-16
 * https://tools.ietf.org/html/draft-ietf-quic-http-34

These URLs in the document can probably be converted to HTTPS:
 * http://arxiv.org/abs/cs.SE/0105018