Re: Linked Media: Weaving non-textual content into the semantic web

2009/3/9 Raphaël Troncy <Raphael.Troncy@cwi.nl>:
> Dear Michael,
>
>> Could you please detail out that one? Seems like an interesting question,
>> but without further details hard to answer. What is a smart UA? What sort
>> of
>> clever processing? Which custom HTTP headers?
>
> Sure, sorry, there was indeed a lot of implicit in these few lines. When
> designing the Media Fragment URI specification, the WG has already wondered
> how the old-fashioned and the new UA (e.g. a web browser) will react facing
> a Media Fragment URI.
>
> A old-fashioned UA (e.g. a current web browser) will behave as currently:
> strip the hash and send the request to the server.
> What I called a smart UA (e.g. the next release of your browser, or your
> current browser with an appropriate plugin) will strip the hash, but encode
> (part of) the fragment into custom http headers while sending the request to
> the server. This is what I called "clever processing".
>
> The old-fashioned server might not understand these new headers, and will
> therefore send the whole resource to the UA, while the new media server will
> handle it and behave as we expect.
>
> Regarding the "which custom HTTP headers" question: these are for example
> the ones described in the 2-way and 4-way handshakes. Actually, we imagine
> currently new unit(s) for the range http header, and possible a new http
> header.

that's a good way of explaining the discoverability problem.

The use of fragments introduces a new protocol layer above HTTP. I
think it's a major issue, and as such #fragment offsets should only be
mandated in situations where it is not possible to use ?queries.

Conrad.