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

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

Apologies but I have not been able to fully review the entire draft!

However, I would like to thank the authors and WG on the time and effort they
have put into updating the HTTP specs which will make it much easier for HTTP
implementers to check that they are up to date with the spec.

In my light reading of the doc, I did notice a few minor nits, which I will
leave to the authors/WG to decide whether they wish to address:

   2.5.  Protocol Version

   HTTP's major version number is incremented when an incompatible
   message syntax is introduced.  The minor number is incremented when
   changes made to the protocol have the effect of adding to the message
   semantics or implying additional capabilities of the sender.

It is perhaps fairly obvious, but do you want to say that
the minor version number is reset to 0 when the major version number is
incremented?

4.2.3.  http(s) Normalization and Comparison

   Two HTTP URIs that are equivalent after normalization (using any
   method) can be assumed to identify the same resource, and any HTTP
   component MAY perform normalization.  As a result, distinct resources
   SHOULD NOT be identified by HTTP URIs that are equivalent after
   normalization (using any method defined in Section 6.2 of [RFC3986]).

With the text in this section (4.2.3), I found it a bit unclear as to whether
this normative text included the additional rules that were listed after it. 
My assumption is that they must, but I wasn't sure that the text was that clear
on this point.

9.2.1.  Safe Methods

    "crash the server"

Flagging in case you want to express this differently (e.g., cause the server
to fail)

9.2.3.  Methods and Caching

   This specification defines caching semantics for GET, HEAD, and POST,
   although the overwhelming majority of cache implementations only
   support GET and HEAD.

It is somewhat ambiguous as to which specification is being referred to by
"This".  Is it the semantics draft of the caching draft?

Received on Thursday, 17 June 2021 10:19:27 UTC