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

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

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

Big thanks to editors and contributors of the this document.

I found this document to be very well written with right level of description
which surely makes the developer's life a bit easier, specially having all the
important considerations and recommendations in one place.

I have following observations -

* Server push is mentioned in section 1.2. I was expecting some descriptions in
this document on how the server push is realized specially using the methods
defined in this document.

* Section 4.2.2:  it says-

          "The origin server for an "https" URI is identified by the authority
   component, which includes a host identifier and optional port number
   ([RFC3986], Section 3.2.2).  If the port subcomponent is empty or not
given, TCP port 443 (the reserved port for HTTP over TLS) is the
   default.  "

      how does this default work with HTTP/3 which used UDP port 443?

* It felt like security consideration section missing considerations for the
TRACE method.  The section 9.3.8 says - "A client MUST NOT generate fields in a
TRACE request containing sensitive data" , I am just wondering is that good
enough warning.

* I support Roman's comment about the strength of the recommendation based on
the use of the verb “ought”. This might be a bit more confusing to the readers
with non-native English language background. I would suggest to use more
recommend or should or must in the entire document instead of "ought to".

* Lars provided very good input on editorial fixes/nits, I would skip mine and
hope his will be addressed by the editors.