W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Re: byte-range redirection

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 29 Nov 2008 12:06:17 +1100
Message-ID: <2c0e02830811281706i3ab38077n2f76668d913f504e@mail.gmail.com>
To: "Conrad Parker" <conrad@metadecks.org>
Cc: "Media Fragment" <public-media-fragment@w3.org>

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
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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:41 UTC