Re: Representation header final proposal

On Tue, 20 Jan 2004, Mark Nottingham wrote:

> > Because it makes it formally possible to produce an implementation that
> > doesn't send the headers and ignores them when they arrive. A simple
> > implementation. In order to allow this without the headers being an
> > extension (i.e. optional) we would have to specify levels of compliance
> > or we would have to use SHOULDs and MAYs etc. the right way.
> > Extensibility is a simpler way to achieve the same result.
>
> Such an implementation is not precluded if a means of carrying headers
> is specified.
>
> To be clear; I'm not saying that we should specify how, when or if
> particular headers are serialized or interpreted; rather, I only think
> it's necessary to define a structure somewhat like this:
>    <header name="...">...</header>
> This will allow applications that want to use representation metadata
> to do so, and to make it available through infrastructure like HTTP
> APIs.

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).

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."