Martin Duke's Yes on draft-ietf-httpbis-semantics-16: (with COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-httpbis-semantics-16: Yes

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

As someone who has learned HTTP via osmosis, it was very helpful to finally
read it all collected in one place. Thank you. I especially appreciate the
effort to document legacy undesirable behaviors, which implementers need to
account for in their work.

(7.6.3) Via

"If a port is not provided, a recipient MAY interpret that as meaning it was
received on the default TCP port, if any, for the received-protocol."

So if received-protocol is "3", it's a UDP port.

If received-protocol is "1" or "1.1", is the default port 80 or 443? IIUC the
scheme isn't included to determine this.

(7.7) Message Transformations

"A proxy that transforms the content of a 200 (OK) response can inform
downstream recipients that a transformation has been applied by changing the
response status code to 203 (Non-Authoritative Information)"

Why not an normative word, instead of "can"?

(12.5.3) Is it correct that "identity" and having no field value for
Accept-Encoding are synonymous?

"Servers that fail a request due to an unsupported content coding ought to
respond with a 415 (Unsupported Media Type) status"

Why not s/ought to/SHOULD ?

(14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not
intermediaries?

(15.3.7) "A sender that generates a 206 response with an If-Range header
field"... (13.1.5) leads me to believe that only clients can send If-Range. So
how can there be a response with If-Range?

(15.3.7.2) The last instance of THIS_STRING_SEPARATES has a trailing '--'. If
this is intentional, it ought to be explained.

(16.3.1) says field names SHOULD begin with a letter, but (16.3.2.1) says they
SHOULD begin with "an alphanumeric character". More broadly, the "Field name:"
description in (16.3.1) should probably refer to (16.3.2.1) unless I'm
misunderstanding the scope of these sections.

(17.13) s/TCP behavior/TCP or QUIC behavior

(B) It would be good to mention here that accept-ext has been removed in
(12.5.1), and accept-charset is deprecated in (12.5.2), if that is new to this
spec.