Re: updated server-parsed fragment wiki page

On Wed, Sep 23, 2009 at 8:09 PM, Conrad Parker <conrad@metadecks.org> wrote:
> 2009/9/23 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
>> On Sat, Sep 19, 2009 at 4:58 PM, Conrad Parker <conrad@metadecks.org> wrote:
>>> 2009/9/19 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
>>>> 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.
>>>
>>> Ranges and tracks are orthogonal concepts. A track gives you some kind
>>> of semantic view across the whole file. A range is a way of addressing
>>> the whole file, or of addressing a track view.
>>>
>>> In terms of caching, you may be able to store and recombine ranges
>>> from the same view. For this reason Fragment is declared in the Vary
>>> header; this allows ranges of a track to be cached, even by an
>>> intermediary that does not understand what the track is all about (ie.
>>> just using generic Range mechanisms). This would not be possible if
>>> both track and range were supplied in the same header.
>>>
>>> Specifically, it ensures that our track etc. selection schemes do not
>>> interfere with existing HTTP/1.1 caches that do byte range handling.
>>> The same may apply to future intermediaries that support time range
>>> caching.
>>
>> So, if a current cache receives a range request that includes both,
>> byte ranges and a track request, it will not be able to resolve that?
>
> Right, so a current current proxy that sees:
>
>    Content-Range: bytes 1234-5678/9999
>    Content-Range: track audio/*
>
> just going to forget about range recombining. Whereas one that sees:
>
>    Content-Range: bytes 1234-5678/9999
>    Fragment: track=audio
>    Vary: Fragment
>
> is going to be able to do correct byte-range caching for the track.
>
>> What happens in the case of byte ranges and time ranges?
>
> For time ranges there is no opportunity to try to make things work
> with existing installations, so it is less of an issue which way it
> is implemented.
>
> Nevertheless, I think the expected behaviour is clearer if it is simply
> spelled out:
>
>    Content-Range: time:npt 00:10-00:20/00:30
>    Fragment: track=audio
>    Vary: Fragment
>
> ie. the track handling is already taken care of by the Vary header.
>
> This way the only additions we impose on a proxy are for time range
> handling, where a proxy may be able to recombine or take subranges of
> existing cached responses.

OK, that makes sense to me.

Would we need to do a similar thing for id addressing?

Silvia.

Received on Wednesday, 23 September 2009 11:42:39 UTC