- 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>
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). <snip> Thanks, -- Travis
Received on Tuesday, 2 January 2007 21:09:15 UTC