Re: Strawman proposal for Representation header

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 

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?


Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Wednesday, 19 November 2003 03:15:13 UTC