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

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 25 Sep 2009 16:44:38 +1000
Message-ID: <2c0e02830909242344n75e54ef5j1931db5786413e4b@mail.gmail.com>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Cc: Conrad Parker <conrad@metadecks.org>, Media Fragment <public-media-fragment@w3.org>, Jack Jansen <Jack.Jansen@cwi.nl>, Yves Lafon <ylafon@w3.org>
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
. 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

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!


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

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