W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2010

Re: ACTION-155: Figures illustrating URI fragment Resolution in HTTP

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 24 Mar 2010 10:51:45 +1100
Message-ID: <2c0e02831003231651p6991e370j2e7a070633288a35@mail.gmail.com>
To: Davy Van Deursen <davy.vandeursen@ugent.be>
Cc: public-media-fragment@w3.org
Hi Davy,

Can you attach the new diagrams?


On Wed, Mar 24, 2010 at 3:09 AM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> Hi Silvia,
>
> On mrt 23, 2010 at 00:16, Silvia Pfeiffer wrote:
>> Cc: public-media-fragment@w3.org
>> Subject: Re: ACTION-155: Figures illustrating URI fragment Resolution
>> in HTTP
>>
>> Hi Davy,
>>
>> 5.2.1-5.2.3 look fine to me in both cases.
>>
>> 5.2.4 is interesting. The replies on 5.2.4 will actually always need
>> to have a multipart message body reply (multipart/byteranges), because
>> there will be setup bytes and data bytes, so it will basically look
>> like 5.2.2 in the multiple byteranges section, but also include the
>> header data.
>
> I now included this in the examples. However, what should we use as content
> type for the header information? For the moment, I used video/setup. If we
> use video/ogg, the client does not know where the header information is
> located in the response or can we assume that this will always be the first
> byte range?

Yeah, I think it still needs to be video/ogg and multipart/byteranges,
which will make sure the UA knows it's getting more than just the
setup info. Also, I do believe it is irrelevant where the setup byte
range is located - the UA needs to understand and parse the file
format anyway, so it will know where to find the setup information -
with Ogg and MPEG it will be at the beginning, with AVI (if it so
chooses to support it), some of it will be at the end.

Cheers,
Silvia.
Received on Tuesday, 23 March 2010 23:59:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:38 GMT