Re: minutes of 2009-09-17 F2F meeting, Day 1

Hi all,

I have worked over my ACTION-110,
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/110 and made
all the changes to the specification document to include the
discussion that we had about fragments and queries.

You can see the results at
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-query
. Feel free to give me feedback where you disagree. Otherwise we can
close ACTION-110.

Note that I added an editorial note that says "We should at the end of
the document set up a table with all the different addressing types
and http headers and say what we deem is conformant and how to find
out whether a server or user agent is conformant or not.". This is in
reply to the concerns what Michael had about what we call a
"conformant" implementation and I do think this indeed needs to be
clarified.

I would suggest this work also closes ISSUE-6,
http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/6 .

Now, I think the specification is fairly complete until section 5,
which relies on the summary that Raphael has promised in ACTION 112.
Looking forward to that!

Cheers,
Silvia.



2009/9/18 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
> 2009/9/18 Raphaël Troncy <Raphael.Troncy@cwi.nl>:
>> Hi Silvia,
>>
>>>>  - UA send a media fragment request with a hash (e.g. spatial dimension),
>>>> the server would need to transcode to serve it. We _might_ mandate that
>>>> in
>>>> this case, it does not serve a fragment but the whole resource and let
>>>> the
>>>> UA decides what to do with the fragment part
>>>
>>> I don't think we have much of a choice here since this request means
>>> that the server cannot satisfy the content-range request header, will
>>> therefore ignore it, and will therefore serve the full resource.
>>> That's how http works, FAIK. I don't think we need to mandate anything
>>> here - the HTTP spec already takes care of this - it's one of the
>>> error cases we are looking at in the testing case.
>>
>> Hum, I agree with what you say in principle except that I don't think it is
>> an error case! It will not generate a 4xx response for example, but rather a
>> 200. But I think we agree on what should happen, just not yet on how to
>> phrase it in our document :-)
>
> Yes, for HTTP it is not an error. :-)
>
>
>>> That was my understanding of the outcome of yesterday. And probably a
>>> good start at the paragraphs I promised to add to the specification.
>>> :-)
>>
>> OK. I don't see strong disagreement with what I have written, but you expand
>> the explanations :-)
>
> Excellent. Anyone else any disagreements?
>
> Cheers,
> Silvia.
>

Received on Friday, 25 September 2009 06:45:39 UTC