RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

>-----Original Message-----
>From: ietf-http-wg-request@w3.org 
>[mailto:ietf-http-wg-request@w3.org] On Behalf Of Travis Snoozy (Volt)
>Sent: vrijdag 22 december 2006 22:55
>To: ietf-http-wg@w3.org
>Subject: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes
>

Assumption: RFC2616...

>(Supporting references at the end of the message)
>
>The offending part of section 13.1.2 (Warnings, page 77) reads:
>
>   [...]
>
>   1xx  Warnings that describe the freshness or revalidation status of
>     the response, and so MUST be deleted after a successful
>     revalidation. 1XX [sic] warn-codes MAY be generated by a 
>cache only
>     when validating a cached entry. It MUST NOT be generated 
>by clients.
>
>   [...]
>
>
>The problems, in order from simplest to the most complex:
>
>1. 1XX should be 1xx (or vice-versa) everywhere.
>
>Proposed fix: pick one, and use it everywhere. I'm partial to 
>1xx myself :).
>

Valid. Slight typo, should not impair understanding of the spec.



>>2. The use of MAY in the offending part of 13.1.2 conflicts 
>with the MUST
>   requirements in section 14.46 and the definition of MAY in BCP14.
>

Invalid.
Your interpretation is clearly wrong, read it in another way. It is
consistent. I will comment on the fix.

>Proposed fix: "1xx warn-codes MUST NOT be added to any 
>messages except cache entries

Invalid:
Warnings, including 1xx warn-codes, have multiple purposes and are not
limited to HTTP caches only (see section 14.46).
Furthermore its perfectly legal for a server to include a 1xx warn-code
on, perhaps my database refuses and I used the cached information
instead. A warning could be appropiate in some cases.

>, and MUST NOT be added to cache 
>entries except in response to a validation attempt." (As a 
>side note, a definition of a cache entry would be
>nice.)

Valid, but the spec already says this (in the positive sence).

But your proposed fix forgets that 1xx warn-codes must be deleted on
successful validation.
(Side note: Tricky is that section 14.46 does mention that warnings from
the validated response must be used instead. So remove the old 1xx
warnings, as these do not apply any more and add the new warnings
instead. Of course these new warnings may include 1xx warn-codes again,
but for this case.)

I do not suggest any corrections to this paragraph for this reason.

>3. One would think that proxies could include caches (though I 
>have yet to
>   find where this is permitted with a true BCP14 MAY). 

Read the defitions:
Client is a program.
Server is a program.
Proxy is a program.
Cache is a program's local store and ....
Thus a cache may be a proxies local store and ....

Funny you say it correctly below.

>However, the wording
>   in the offending part of 13.1.2 makes it impossible to satisfy the
>   requirements of a cache and the requirements of a client (and, by
>   extension, proxy) simultaneously. A cache is not an 
>independent program;
>   it is part of a program (as per the 1.3 definition). A client is a
>   program, and it can contain a cache (again, from 1.3), but 
>this limits
>   the cache's behavior to the set intersection of allowed 
>behaviors for
>   caches and clients (due to how "client" is defined). This leads to a
>   conflict where the cache MUST generate a 1xx code, but a 

...cache "MAY" generate..., not MUST.
You mentioned that in the above items.

>client MUST NOT
>   generate a 1xx code. Thus, we're left having to conclude 
>that caches can
>   exist only as part of independent servers (which have their content
>   pushed to them, or delivered through some out-of-band method).

Thus, invalid.
Your claim fails on wrong copying of the MUST and MAY clauses in the
spec.



Only a slight typo correction might be in place.



- Joris Dobbelsteen

Received on Wednesday, 27 December 2006 10:11:07 UTC