W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

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

From: Travis Snoozy (Volt) <a-travis@microsoft.com>
Date: Tue, 2 Jan 2007 13:08:55 -0800
To: Paul Leach <paulle@windows.microsoft.com>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>
CC: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <86EDC3963F04D546BED8996F77D290F6049D117E5B@NA-EXMSG-C138.redmond.corp.microsoft.com>

Paul Leach said:
> If a client implements a cache, then it's a cache,

... but that does not stop it from being a client, and clients and caches have conflicting requirements (see previous messages in this thread) ...

> and it's the server side of the cache that adds the warn-code to the
> response.

Close, but no cigar. See section 1.3 (definitions of "cache," "proxy," and
"client") and my prior messages in this thread. There is no "server side" to
a cache, nor is there a "client side" to it -- at least, not defined by the
spec (implementation-wise there might be). A client that implements a cache
is not automatically a server, and a server that implements a cache is not
necessarily a client (though at first glance it might appear to have to be).
Note that it has to be this way, because if a cache had a "server" bit and a
"client" bit, there would be a circular reference (both the server and
client bits could implement a cache, which in turn would have their own
client/server bits, and so on down).

FWIW, your wording is more or less the terminology I used in my annotation
on how to interpret this clause; however, it's not a real solution to the
direct problem this clause is posing (i.e., bad phrasing and not saying what
it really means).



-- Travis
Received on Tuesday, 2 January 2007 21:09:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:41 UTC