Re: Representation header final proposal

That makes sense, except that the majority of URI schemes that are 
dereferencable use a MIME or MIME-like metadata/data packaging; I'd put 
forth that from an infrastructure standpoint, there's no need to 
differentiate between these protocols.

It's true that there are dereferencable URI schemes that return 
representations that aren't MIME-like, but my first guess would be that 
they'll all like file, with a semantic of "bag of bits." That fits into 
a MIME-like model (with no headers).

If we really want to allow non-MIME-like, non-bag-of-bits 
representations, I could see making a "MIME-like protocols" extension.

Cheers,

P.S. What hath the TAG to say about the model (vs. form) of a 
representation? Can we just settle on MIME-like and be done with it?


On Jan 21, 2004, at 5:03 AM, Yves Lafon wrote:

> Well, that was the point of my proposal, however, Jacek's point (as I
> understood it) is more:
> * do a very raw thing
> * extend to add extra information related to different protocols
>
> If we add <h:header> in the "HTTP" namespace, with all the necessary
> information to act as a local cache, then I am happy, as long as we 
> don't
> defer it to another spec.
>
>> If you don't want to send or use such metadata, that's your choice.
>> However, if this mechanism is to be a drop-in replacement for the URI
>> dereference function, I'd expect it to provide equivalent information
>> when I need it. Otherwise, I don't see much point in the effort of
>> standardising this header.
>
> What are the metadata for file: uri? Having a per-protocol extension
> seems to be a good approach (we can even have family of protocol, as 
> some
> share the same metadata schemes).

Received on Wednesday, 21 January 2004 12:03:01 UTC