- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Wed, 19 Nov 2003 00:13:14 -0800
- To: Yves Lafon <ylafon@w3.org>
- Cc: Martin Gudgin <mgudgin@microsoft.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
On Nov 18, 2003, at 6:13 PM, Yves Lafon wrote: >> Hmm. Vary is part of a protocol sequence (Accept-* on the request, >> Vary >> on the response; Mogul calls it a "variant-header", RFC2616 calls it a >> "response header", but neither classification seems vary satisfying in >> this context), so it's difficult to specify how to use it. > > My view of Vary is a bit different, as I always considered URIs > subject to > negotiation to be first class object with the semantic of dispatching > to > the most relevant resource, so Vary just means "I can forward the > processing of your HTTP verb to other ones that may be more suited" I agree that that's one way to view resources that vary according to request headers, but it isn't the only one. Strictly speaking, a resource that varies over request headers can be thought of in the same way as one that varies over time; that is, as a resource with a number of representations that vary over some axis. >> In other words, understanding Vary presumes that the client (whether >> the original requester or a subsequent client hitting a cache) has >> expressed its preferences to the server; in a standalone SOAP message, >> these aren't known at time of its creation. The relevant portion of >> 2616 is in section 13.6: > > Well, if we have to embed a representation in the message, then the > originator of the SOAP message has to access the resource with its own > preferences Is there an assumption here about the MEP? E.g., how would this happen in a one-way MEP? > Well it depends if we think of the carried representation as a > convenient > way to send data without caring much about integrity or we we consider > it > as a first class URI resolver that should then follow the HTTP rules > for > caches. > You can have the case where many representation are understood but a > lower > quality one is carried with the SOAP message, like sending a picture > as a > low quality gif for small devices while a SVG version can be fectched > on > the network by network-connected projectors. I think that describing this format as a fully offline portable cache (both more fully-featured and more respectful of HTTP than MHTML) is INTENSELY interesting, and would find it quite easy to be happily diverted by it for quite a while (as you probably know, Yves!) but I wonder if our fellow WG members share these feelings... there could be a considerable amount of work, because I don't think that this part of HTTP was ever very fully specified, and conneg has its own failings as well. Is it possible to accommodate both of these use cases (dumb data carriage vs. 1st class URI resolver) with the same format, and without going down this path too far right now? Cheers, -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Received on Wednesday, 19 November 2003 03:15:13 UTC