W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2009

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

From: Conrad Parker <conrad@metadecks.org>
Date: Mon, 9 Mar 2009 07:53:07 +0900
Message-ID: <dba6c0830903081553y4f3cd895xeb9a64b17d2f9feb@mail.gmail.com>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>
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.

Received on Sunday, 8 March 2009 22:53:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:42 UTC