Queries re P6

Hi all. 

We're currently refactoring our cache module, and have run into a few 
areas where there seems to be inconsistency between RFC2616 and p6, and 
other places where there are possibly ambiguities in p6.

Firstly, if one is to compare RFC 2616 10.3.5 with P6 4.2.1

in RFC2616 10.3.5 we have 

"If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the
conditional."

in P6 4.2.1 

"If none of the stored responses contain the same strong validator,
then this new response corresponds to a new selected
representation and MUST NOT update the existing stored responses."

I don't see anywhere in p6 where it says the response must be 
disregarded completely and the request re-issued. Isn't this therefore 
a semantic change (which I understood was outside the scope of httpbis)?

I don't understand how "Not modified" can be compatible with "new 
selected response".

Am I even comparing apples with apples here?

also I found some other clauses a bit confusing.

in 4.2.1, 

"If the new response does not include any form of validator, there
is only one stored response, and that stored response also lacks a
validator, then that stored response is selected."

Firstly, there should be an "and" in there... e.g. it should read 

"If the new response does not include any form of validator, and there
is only one stored response which also lacks a validator, then that 
stored response is selected."

But how can a server logically reply with 304 without a validator? 

A server can only reply with 304 if the request was conditional. For a 
request to be conditional, there must be a validator supplied with the 
request. But in this case the stored response had no validator. So 
where did the validator come from?

Does this mean that it's compliant behaviour to make a conditional 
request with data that wasn't in the stored response? E.g. have a cache 
invent an If-Modified-Since based on something else (e.g. Date)? 
Presumably a cache can't invent an ETag where there was none. Also, 4.2 
para 2 states the If-Modified-Since comes from Last-Modified and 
doesn't imply it can come from elsewhere.

My initial reaction is to consider a 304 without validator to be a 
server bug.

also:

"use other header fields provided in the 304 (Not Modified)
response to replace all instances of the corresponding header
fields in the stored response."

Should there be some limit on the fields that may be updated? Does it 
make sense for instance to allow updating of Content-Type?

in 4.3 may I clarify meaning of

"If no selected response is available, the cache can forward the
presented request to the origin server in a conditional request; see
Section 4.2."

"in a conditional request" is possibly ambiguous. To me this means the 
cache is entitled to make the request conditional by adding 
If-Modified-Since or If-None-Match etc. The request may have already 
been conditional (e.g. UA cache). So the purpose of the cache checking 
validity of something that failed selection is valid? E.g. the server 
gets the final say but may still choose to serve the same content (e.g. 
same ETag) even though it didn't match selectors?

in 4.2 may I suggest some wording changes.

Para 2 does not indicate that it's not valid to add If-Modified-Since 
unless there was a Last-Modified header in the stored response.

E.g. instead of 

"When sending such a conditional request, a cache adds an If-Modified-
Since header field whose value is that of the Last-Modified header
field from the selected (see Section 4.3) stored response, if
available."

maybe it should read something like

"If the selected stored response contains a Last-Modified header, a 
cache SHOULD add an If-Modified-Since header field whose value is that 
of the Last-Modified header field from the selected stored response."

Likewise Para 3 and If-None-Match. E.g instead of 

"Additionally, a cache can add an If-None-Match header field whose
value is that of the ETag header field(s) from all responses stored
for the requested URI, if present...."

maybe

"Additionally if any stored response contains an ETag header field, a 
cache SHOULD add an If-None-Match header whose value(s) are the ETag 
header field(s) from all stored responses for the requested URI."


Thanks

Adrien