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

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

Thanks to the editors and contributors of this document for a great job.
Specially for the security consideration section, it is very well written and
anyone implementing this document should pay extra attentions to that section.

I have following comment and question -

*  I consider this as editorial fix hence not holding a discuss but I would
like to see this addressed. This document uses terminologies defined in section
3 of
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-16#section-3,
for example - user agent, client. However, it does not refer to the the
semantics doc. I think it must refer to the section 3 of semantic document.

* Section 2.2 :  it says -

          "When a server listening only for HTTP request messages, or processing
   what appears from the start-line to be an HTTP request message,
   receives a sequence of octets that does not match the HTTP-message
   grammar aside from the robustness exceptions listed above, the server
   SHOULD respond with a 400 (Bad Request) response and close the
   connection."
         Is there a reason why it is not a MUST but SHOULD? In my small scale
         implementation experiments I implemented it as a MUST. I believe if a
         400 is send followed by a close connection then it is a "save
         yourself" action for the server and a MUST thing to do.

* from the ID nits : there is an unused reference to RFC7231.

Received on Wednesday, 16 June 2021 10:31:43 UTC