Re: marking some sections as "ready for implementation"

I guess the only requirement is that the UA doesn't retrieve the full  
resource since that is counter-productive. This normally implies byte  
range requests.

But I made it deliberately informative so what you say applies.

Section 5.2.1 should probably make mote of what you're saying.

Cheers,
Silvia.

Sent from my iPhone

On 03/02/2010, at 11:39 PM, Conrad Parker <conrad@metadecks.org> wrote:

> On 3 February 2010 20:57, Silvia Pfeiffer  
> <silviapfeiffer1@gmail.com> wrote:
>> Hi all,
>>
>> We have both Firefox and Opera waiting for a "go-ahead" from us on
>> what is ready for implementation and I don't really want to make them
>> wait, since I believe we can do with a reality check.
>>
>> For this we should mark sections that we agree on as "ready to
>> implement". But to make that call, we need a group agreement.
>>
>> I'd like us to move towards such a decision on the following  
>> sections:
>>
>> Section 5.2.1, http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped
>> together with the specification part for NPT time:
>> Section 4.2.1.1
>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#npt-time
>> and the general structure of media URI fragments.
>>
>> ...
>> I believe what is required is to say basically:
>> * this is the specification of such temporal URIs using fragments  
>> (normative)
>> * when you get such a URI in a video element or in the URI bar, parse
>> it in this way (normative)
>> * then resolve it through byte range requests if you can (Firefox
>> already is able to do this for Ogg though it takes multiple byte  
>> range
>> requests to get to the right location; with new indexed Ogg files,
>> this will improve) (informative)
>
> for this part (which only relates to how a client acts on a #t=), I
> don't think it's necessary for the Media Fragments spec to say how a
> user agent actually retrieves the data for a given media-type. This is
> really dependent on that media-type; it may involve one or more
> byte-range requests (eg. in the two schemes you mention for Ogg), or
> it may involve loading auxiliary resources which describe where to get
> various bits required for a time offset (eg. for quicktime adaptive
> streaming or MS smooth streaming), and these may then involve requests
> of many different resources that make up the media. Basically my point
> is that the specific mechanism depends on both what the media-type
> specifies and what the client is capable of, and doesn't belong in
> this section of the Media Fragments spec.
>
> It might be simpler to just say that if the client is capable of
> seeking in a resource, then the #t= indicates to the client that it
> should seek to that time -- and perhaps we can even word that
> unambiguously enough to be normative.
>
> Conrad.

Received on Wednesday, 3 February 2010 13:02:45 UTC