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

We're talking about

 1xx  Warnings that describe the freshness or revalidation status of
   the response, and so MUST be deleted after a successful
   revalidation. 1XX warn-codes MAY be generated by a cache only when
   validating a cached entry. It MUST NOT be generated by clients.

------------------------------------
First, a few guidelines, as I remember them:

* The roles of 'client', 'proxy' and 'server' were not intended to
be exhaustive; HTTP is used in many contexts with hybrid roles
and complex relationships. In some cases, it's necessary to
specify requirements specifically for clients vs. proxies,
or proxies vs. servers, but in general, it's better to couch
things in terms of request messages and their responses.

* In general, it's better to avoid MUST and MUST NOT rules except
for those cases where it is necessary to ensure interoperability
or operational stability. (There are a few additional cases,
but generally not.)  It's especially troublesome to add
"MUST" or "MUST NOT" requirements to HTTP at this time.
We do better when we describe how things work
and what protocol elements _mean_ and let implementors
use them as appropriate.

* More specifically, it's better to avoid specifying
implementation advice rather than observable network
behavior. (Again, some exceptions.)


The introduction of MUST/MAY/SHOULD keywords happened by
taking English text without them and introducing them
in an editing pass, but (in my opinion) there are too many
of them in the HTTP spec. It's better to avoid introducing
any more. 

-----------------
So, I can't see what the interoperability problems would
be, for allowing responses to contain warnings when
responses are stale generally. 

My proposed rewrite:

 1xx  Warnings that describe the freshness or revalidation status of
    a response. For example, a cache might include a warning
    if it is unable to revalidate the freshness of a cached value,
    but would not include a warning after a successful revalidation.
    These warnings only apply to responses, and SHOULD NOT
    appear in request messages.

I.e., avoid a too narrow (and unnecessary) MUST NOT,
or really specifying anything other than what the
warning means, and letting implementors decide
when to use them.

> "A cache MUST NOT generate 1xx warn-codes for any messages 
> except cache entries

Let's suppose I have a web site where I generate  pages
from a database, and I cache the database values but
not the HTML  pages. If the database cache is stale,
I might still want to include a 1xx warning, even though
the response didn't correspond to a 'cache entry'.
Why would you disallow this? 

> and MUST NOT generate 1xx warn-codes for a cache 
> entry except in
> response to a validation attempt for that entry. 

I don't understand what a 'validation attempt'
might be that isn't implicit in a 'request'.
Is there a reason why some stale results shouldn't
include warnings?                

Larry
-- 
http://larry.masinter.net

Received on Friday, 29 December 2006 04:16:15 UTC