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

Re: updated server-parsed fragment wiki page

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 19 Sep 2009 15:44:53 +1000
Message-ID: <2c0e02830909182244y264e1179k7c813fe6776ace00@mail.gmail.com>
To: Conrad Parker <conrad@metadecks.org>
Cc: Media Fragment <public-media-fragment@w3.org>
On Fri, Sep 18, 2009 at 7:37 PM, Conrad Parker <conrad@metadecks.org> wrote:
> Hi,
> yesterday we were discussing about which HTTP request header to use to
> request a specific track etc. I think we agreed that Range should only
> be used for continuous indexes (that can have a duration/length/size),
> such as time or xywh.

I don't think the outcome of the discussion was conclusive, but we did
indeed mention this as another option.

> I'm suggesting to use something like Fragment for things like track=,
> id=. I've updated this wiki page to include a line about how Fragment
> should interact with time Range requests, and a link to relevant
> examples:
> http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments

After having read all that, I am wondering why we would need to invent
a "Fragment" protocol parameter that does essentially the same as the
"Range" protocol parameter? Is there a reason "Range" doesn't work for
"track"? What is different between "Range:" and "Fragment:" other than
leaving out the <total duration> part on the "Fragment:"?

I sympathise with the idea, but I cannot justify it without having
these questions answered.

Received on Saturday, 19 September 2009 05:45:53 UTC

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