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: Paul Leach <paulle@windows.microsoft.com>
Date: Tue, 2 Jan 2007 13:46:19 -0800
Message-ID: <76323E9F0A911944A4E9225FACFC55BA03307BE0@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
To: "Travis Snoozy (Volt)" <a-travis@microsoft.com>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>
CC: Mark Nottingham <mnot@mnot.net>, <ietf-http-wg@w3.org>

You're right -- I said "cache" when I was thinking "caching proxy".

-----Original Message-----
From: Travis Snoozy (Volt) 
Sent: Tuesday, January 02, 2007 1:09 PM
To: Paul Leach; William A. Rowe, Jr.
Cc: Mark Nottingham; ietf-http-wg@w3.org
Subject: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

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:46:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:00 GMT