MUSTs and other feedback 2

[mnot@…]

The If-Match condition is met if and only if any of the entity-tags listed in the If-Match field value match the entity-tag of the selected representation using the weak comparison function (as per Section 2.3.2), or if "*" is given and any current representation exists for the target resource.

The "if and only if ... or if ..." construction looks funny. It is kind of correct because the first part applies to the non-* condition and the second part applies to the * condition, but still... Please consider dropping either "and only if" or the "if" in "or if".

Can a proxy with an empty cache determine whether "any current representation exists for the target resource" without forwarding the request to the origin server? In other words, does "exists" mean "exists in the proxy cache" or "exists on the origin server"? Perhaps you can add some test to clarify the scope of resource existence here from the caching proxy point of view.

The same two concerns apply to the If-None-Match section.

Here is a list of requirement-like statements that seem to be missing MUST/SHOULD/MAY keywords to make them formal requirements and indicate the level of those requirements:

Preconditions are ignored if the server determines that an error or redirect response applies before they are evaluated.

The conditional request header fields defined by this specification are ignored for request methods that never involve the selection or modification of a selected representation

The general rule of conditional precedence is that exact match conditions are ...

Specifically, the fields defined by this specification are evaluated as follows:

Please consider rephrasing the above using RFC 2119 keywords and, where applicable, giving them explicit actors.

[fielding@…]

From [2361]:

Rephrase conditional header field definitions, again, to remove all untargeted requirements and clarify that only origin servers and recipient caches need to evaluate; make the precedence order a requirement; addresses #479

[julian.reschke@…]

From [2362]:

Note change for [2361], see #479