Re: Use cases and requirements for Media Fragments: Chapter 8

2009/4/8 Raphaël Troncy <Raphael.Troncy@cwi.nl>:
> Dear Conrad,
>
>> I've been thinking about generalizing this mechanism a bit recently to
>> allow caching of non-header data. Here's some notes towards that:
>>
>> http://blog.kfish.org/2009/04/proposal-for-generalizing-byte-range.html
>
> Great post! Thanks!
> However, I'm a bit puzzled with your proposal. From my understanding, the
> 4-ways handshake is meant to resolve a range request, e.g. in seconds into a
> byte range request. As Yves pointed out, we need a resolver that can do
> that, providing what ultimately the codec format allows to do.

yes, that is the situation; where the origin server (that understands
the codec format) translates it into byte ranges of a canonical
resource.

> On the other hand, it seems to me that your proposal aims at solving the
> problem of answering a complex request with multiple by ranges, while I do
> not understand what the UA needs to do with the set of bytes it will receive
> to have a playable resource.
> Therefore, could you explain me what the 'Range-Referral' new header is
> meant to do?

The user agent should concatenate the byte ranges to which it is
referred. The semantics are that the resulting stream is equivalent to
the stream that would otherwise be constructed for the segment
(bytewise-identical, at least for the implementation I have in mind).

>> As for terminology, I really don't think the term "handshake" is
>> appropriate; especially when all that's really happening is that the
>> data retrieval is getting split across multiple HTTP requests.
>> Handshake seems to imply that just negotiation is going on, and that
>> this is delaying the actual data retrieval -- which isn't the case
>> here.
>
> I agree that the term 'handshake' is not necessarily adequate, though I
> cannot find a better one :-( In the Western world, the term handshake
> sometimes suggests that the negotiation is over. So, in our case, we could
> speak off *a* handshake when all the rountrips have been successfully made.
> Can you suggest a better term ?
>
> In the meanwhile, I suggest to add the following editorial note in the WD in
> the section 8.0:
>
> "In the following, we use the terms <emph>two-ways handshake</emph> when
> there is one roundtrip and <emph>four-ways handshake</emph> when there is
> two roundtrips between the UA and the server. We acknowledge that these
> terms are not necessarily adequate and we seek suggestions for having better
> terms for naming these processes."
>
> Can you live with that?

In the more general case, the resulting data could be the
concatenation of a number of HTTP range requests, so the number 4 is
not necessarily relevant; and I still don't think it's a handshake. I
don't have any particular objection to the word "way" however ;-)

Perhaps "byte-range referral" is an accurate description of what's going on?

cheers,

Conrad.

Received on Tuesday, 7 April 2009 21:24:40 UTC