Re: byte-range redirection

On Sat, Nov 29, 2008 at 11:15 AM, Conrad Parker <conrad@metadecks.org> wrote:
>
> Hi,
>
> Regarding the method of retrieving media data in two parts over HTTP,
> I think the term "4-way handshake" is a bit of a misnomer. The word
> "handshake" implies protocol setup, whereas what we're really talking
> about is a two-part request, where the first typically retrieves a
> small but not insignificant amount of data (~10-100kB) which is
> particular to the subview being requested -- media headers, keyframes
> etc. As that data is necessary and immediately useful, I think it
> would be incorrect to say that this method adds any appreciable
> latency to the media request.
>
> Further, use of this method is optional, such that if the user agent
> does not specify to do so in the HTTP request headers then it simply
> receives all the data immediately as a normal GET request.
>
> Perhaps it would be more accurate to talk about an (optional)
> byte-range redirection than a handshake.

I agree. I have been thinking myself that the name choice was not a
very good one.

I am currently waiting for Raphael to return from his holidays and
work on the HTTP implementation part of the working draft in the wiki
http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation.
Both, Yves and I will want to give input to that page, but Raphael has
requested to write the page in order to give himself a chance to think
through the options in all detail.

Raphael: when you start on that page, you could use "optional
byte-range redirection" rather than "2-way handshake" to describe that
option.

Cheers,
Silvia.

Received on Saturday, 29 November 2008 01:06:56 UTC