Robert Wilton's No Objection on draft-ietf-httpbis-messaging-16: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-httpbis-messaging-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-messaging/



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

Thank you for cleaning up this spec.  I appreciate that the effort it takes to
achieve this, but it is very helpful to the wider community in the long term.

Not surprisingly, I only have minor comments.

   Although HTTP makes use of some protocol elements similar to the
   Multipurpose Internet Mail Extensions (MIME) [RFC2045], see
   Appendix B for the differences between HTTP and MIME messages.

Nit: This doesn't parse easily to me, perhaps drop the Although?

  Various ad hoc limitations on request-line length are found in
  practice.  It is RECOMMENDED that all HTTP senders and recipients
  support, at a minimum, request-line lengths of 8000 octets.

I was wondering how this applies to constrained devices, but I assume that very
constrained devices should probably be using something like CoAP, and otherwise
most device should be able to cope with an 8k buffer.

Nit:
Various fields seem have a arbitrary amount of space before the equals: E.g.,
"method         = token".  I presume that this whitespace is not meaningful,
but wondered if the spec would be clearer if it wasn't there.

   A sender MUST NOT
   apply chunked more than once to a message body

Nit: "apply chunked" doesn't read that well to me ... but I understand what it
means.  If you decide to change this, then I would check the other places where
"chunked" is used.

   A client MUST NOT process, cache, or forward such extra data as a
   separate response, since such behavior would be vulnerable to cache
   poisoning.

The intent in this paragraph seemed somewhat ambiguous.  E.g., is the
requirement that the client must not process/cache the extra data, or that it
must not process/cache the extra data as a separate response?  I assume the
latter.

   All transfer-coding names are case-insensitive and ought to be
   registered within the HTTP Transfer Coding registry

Would a 2119 SHOULD be better than ought?

   A client MUST
   NOT send a request containing Transfer-Encoding unless it knows the
   server will handle HTTP/1.1 requests (or later minor revisions);

   and also

  A client MUST NOT use the chunked transfer encoding
   unless it knows the server will handle HTTP/1.1 (or later) requests;

Given that we are in 2021, and the HTTP/1.1 spec was published a couple of
decades ago, I was wondering whether the MUST NOT is a bit strong?

Thanks,
Rob