- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 28 Dec 95 13:51:23 PST
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I agree, doing it this way is the best solution. Of course, this
implies that the caching/proxy group stops discussing the caching of
negotiated responses for some time.
While the content negotiation subgroup is working out the negotiation
mechanism, the caching/proxy subgroup can work on the caching model
for non-negotiated responses. There are still plenty of things to
discuss even if negotiation is presumed absent.
If the content-negotiation subgroup is aware of the need to provide
a solution to the caching problem, I think the caching subgroup can
go on our merry way for a while. Ultimately, the content-negotiation
subgroup ought to provide a precise definition of how a cache can
determine if a new request matches the cached response to a previous
request.
The current 1.1 draft contains this paragraph:
Servers that make use of content negotiated resources must include
URI response headers which accurately describe the available
variants, and include the relevant parameters necessary for the
client (user agent or proxy) to evaluate those variants.
I think the key words here are "accurately describe", "relevant
parameters", and "evaluate." We need precise specifications to
replace these somewhat ambiguous phrases.
-Jeff
Received on Thursday, 28 December 1995 14:00:53 UTC