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

Hi Silvia,

On mrt 25, 2010 at 00:44, Silvia Pfeiffer wrote:
> Cc: public-media-fragment@w3.org
> Subject: Re: ACTION-155: Figures illustrating URI fragment Resolution 
> in HTTP
> 
> Hi Davy,
> 
> I think some of the "durations" have gone wrong...
> I believe 50 is the duration of the file in sec and 59000 is the 
> bytes, right?
> I'm making change suggestions based on this:
> 
> Single Byterange:
> 5.2.3:
> Should
>   Content-Range-Mapping: t:npt 10-20/59 be
>   Content-Range-Mapping: t:npt 10-20/50 ?
Correct.

> 5.2.4:
> Should
>   Content-Range: t:npt 10-20/59
> be
>   Content-Range-Mapping: t:npt 10-20/59 ?
> And should
>   Content-Range-Mapping: t:npt 10-20/59 be
>   Content-Range: t:npt 10-20/50 ?
> and should
>   Content-Range-Mapping: bytes 0-2000/32000 be
>   Content-Range: bytes 0-2000/59000 ?
> (Note both the change with -Mapping and the duration)
Correct regarding the duration. The reason that I swapped Content-Range and
Content-Range-Mapping was based on a suggestion by Yves. But honestly, I
currently don't see any reason to write it like that anymore, so agree with
your proposal to make it consistent with 5.2.2. But maybe Yves has a
different view?

> Multiple Byte Ranges:
> 5.2.1:
> I believe it is also possible to pack two byte ranges in one request, 
> i.e. ask for
> Range: bytes=2000-13000
> Range: bytes=24000-28000
> in one request.  Yves? Then the reply is also a multipart/byteranges 
> and one round trip is saved.
Yes, I checked [1] and it is allowed to request multiple byte ranges.

> 
> Should
>   Content-Range: bytes 2000-13000/32000 and
>   Content-Range: bytes 24000-28000/32000 be
>   Content-Range: bytes 2000-13000/59000 and
>   Content-Range: bytes 24000-28000/59000 ?
No, since in the multiple byte range cases, I shortened the example resource
to 32000 bytes in order to restrict the number of byte ranges corresponding
to the requested track (otherwise the example would become too large).

> 
> 5.2.2
> Should
>   Content-Range: bytes 2000-13000/32000 and
>   Content-Range: bytes 24000-28000/32000 be
>   Content-Range: bytes 2000-13000/59000 and
>   Content-Range: bytes 24000-28000/59000 ?
No, same reason as above.

> 
> 5.2.4
> Should it have a
>   Content-Range-Mapping: track video; include-setup instead of
>   Content-Range: track video
> header?
Yes, I agree.

> And should
>   Content-Range-Mapping: bytes 0-2000/32000 and
>   Content-Range-Mapping: bytes 2000-13000/32000 and
>   Content-Range-Mapping: bytes 24000-28000/32000 be
>   Content-Range: bytes 0-2000/59000
> and
>   Content-Range: bytes 2000-13000/59000 and
>   Content-Range: bytes 24000-28000/59000 ?
> (Note both the change with -Mapping and the duration)
I swapped Content-Range and Content-Range-Mapping, as discussed above. The
length, 32000, is correct according to the example resource.

Thanks for your comments, I updated the figures according to your
suggestions.

Best regards,

Davy

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 


-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems - Multimedia Lab
URL: http://multimedialab.elis.ugent.be/dvdeurse

Received on Thursday, 25 March 2010 08:07:37 UTC