WGLC: p6 MUSTs

Hello,

    These comments are based on the "latest" snapshot dated Mon 29 Apr
2013 03:13:05 PM MDT at
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html

I hope these comments are editorial in nature.


> senders MUST NOT send delta-seconds with a value greater than 2147483648. 

Please use "MUST NOT generate" instead. The proxies should not be
required to police these values.


> For a presented request, a cache MUST NOT send a stored response

This is awkward because many caches never actually send stored responses
because they add or modify Connection, Transfer-Encoding, and other
hop-by-hop headers to/in a store response. Please consider something
like "a cache MUST NOT generate a reply using a stored response" instead.


> A cache MUST NOT send a stale response

Please use "MUST NOT generate". A cache may still send a stale response
by forwarding it. There is already some text implying that later in the
section (see below) but that text belongs to a Warning-generation
context, so it is better to be explicit here.


> the cache can forward it to the requesting client without adding a new Warning 

Use MAY instead of "can"?


> If an implementation sends a message with one or more Warning header
> fields to a receiver whose version is HTTP/1.0 or lower, then the
> sender MUST include in each warning-value a warn-date that matches
> the Date header field in the message

> If a system receives a message with a warning-value that includes a
> warn-date, and that warn-date is different from the Date value in the
> response, then that warning-value MUST be deleted from the message
> before storing, forwarding, or using it.

Please note that the above MUST requirements can be interpreted to apply
to all intermediaries, even those that do not support caching. We have
received many complaints from non-caching proxy implementors unknowingly
violating these MUSTs and having to implement these complex
manipulations that are seemingly irrelevant to their products.

You may also want to replace "implementation" and "system" with sender
and recipient to use consistent terminology. If these rules are specific
to response messages, then using "server" and "client" would be even better.

If the above requirements are only meant for origin server and user
agents, and not all senders and recipients, please fix the actors
accordingly.


> A system receiving this warning MUST NOT take any automated action,
> besides presenting the warning to the user.

In this case, the "system" is probably the "user agent" since
"presenting the warning to the user" is mentioned. Same for 299
"Miscellaneous Persistent Warning".


Please search the whole text for similar "implementation" and "system"
terminology "sprawl".



And here is a list of requirements that are missing an explicit actor on
which the requirement is placed. Even though it is possible to guess the
actor in most cases, these should be easy to rephrase to place the
requirement on the intended actor explicitly (e.g., "A cache MUST"
instead of "a response MUST"):

> the new response MUST NOT be used to update any stored responses.

> the no-cache request pragma-directive MUST have the same effect on
> caches

> warning-value MUST be deleted from the message before storing,
> forwarding, or using it


Thank you,

Alex.

Received on Wednesday, 1 May 2013 04:57:21 UTC