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

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

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



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

This document seems to have unresolved IANA issues, so I am holding a DISCUSS
for IANA until the issues are resolved.


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

Section 9.1. , paragraph 2, comment:
>    protocols.  Each connection applies to only one transport link.

I'm not sure I understand what is meant by "transport link" and how connections
would "apply" to one.

Section 9.4. , paragraph 4, comment:
>    consumes server resources.  Furthermore, using multiple connections
>    can cause undesirable side effects in congested networks.

Using larger number of multiple connections can even cause side effects in
otherwise uncongested networks, because their aggregate and initially
synchronized sending behavior can *cause* congestion that would not have been
present if fewer parallel connections had been used.

Section 13.1. , paragraph 14, comment:
>    [Welch]    Welch, T. A., "A Technique for High-Performance Data
>               Compression", IEEE Computer 17(6), June 1984.

This can become an informative reference, so to not create a DOWNREF, since it's
only used in the description of an IANA codepoint.

Section 13.2. , paragraph 12, comment:
>    [RFC7230]  Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
>               Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
>               RFC 7230, DOI 10.17487/RFC7230, June 2014,
>               <https://www.rfc-editor.org/info/rfc7230>.

I think it is common practice to normatively cite an RFC that is being
obsoleted.

-------------------------------------------------------------------------------
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 9.3. , paragraph 3, nit:
-    Connection header field (Section 7.6.1 of [Semantics]), if any:
+    based on the protocol version and Connection header field in the

Section 11.2. , paragraph 2, nit:
-    Request smuggling ([Linhart]) is a technique that exploits
-                      -         -
+    Request smuggling [Linhart] is a technique that exploits

Section 12.3. , paragraph 3, nit:
-    |            | ([RFC1951]) inside the "zlib" | 7.2       |
-                   -         -
-    |            | data format ([RFC1950])       |           |
-                               -         ^
+    |            | [RFC1951] inside the "zlib"   | 7.2       |
+                                               ++
+    |            | data format [RFC1950]         |           |
+                                        ^^

Section 7.1.1. , paragraph 6, nit:
> to accept in the response, and whether or not the client is willing to prese
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 9.5. , paragraph 2, nit:
> tack has received the client's acknowledgement of the packet(s) containing th
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 9.8. , paragraph 2, nit:
> onse Splitting Response splitting (a.k.a, CRLF injection) is a common techni
>                                    ^^^^^
The abbreviation is missing a period after the last letter.

Section 10.2. , paragraph 17, nit:
>  such that it can be used over many different forms of encrypted connection,
>                                ^^^^^^^^^^^^^^
Consider using "many".

"Appendix B. ", paragraph 2, nit:
>  (which indicate that the client ought stop sending the header field), and t
>                                  ^^^^^^^^^^
Did you mean "ought to stop"?

"B.3. ", paragraph 2, 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.

"B.4. ", paragraph 1, 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.

"C.2.2. ", paragraph 4, nit:
> ction 12.4, update the APLN protocol id for HTTP/1.1 (<https://github.com/ht
>                                      ^^
This abbreviation for "identification" is spelled all-uppercase.

Uncited references: [RFC7231].

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-semantics-16
 * https://tools.ietf.org/html/draft-ietf-httpbis-cache-16

These URLs in the document can probably be converted to HTTPS:
 * http://packetstormsecurity.com/papers/general/whitepaper_httpresponse.pdf