Re: Review of section 7

On Tue, 14 Apr 2009, Silvia Pfeiffer wrote:

>> I think it meant that, yes, we need to create new range unit, but no new
>> headers in the case of the single-step partial GET.
>
> Some of the headers are actually helpful for both alternatives. But
> ok, if we regard the addition of a header as a protocol extension,
> that's fine. Adding a header is actually very cheap, while adding a
> new range type is rather expensive.

Well, you define a specific processing of that header (and what happens if 
the header is not taken into account?), so it is a protocol extension, now 
if you add a header that interfere with things like conneg, it is far from 
a "cheap" thing, as there are lots of implications there.

>>> Also, I would suggest creating
>>> Accept-TimeURI, Accept-SpaceURI, Accept-TrackURI and Accept-NameURI
>>> headers such that the server can indicate to the client whether it is
>>> indeed capable of returning fragments and which type. (we could
>>> certainly turn this into a singe "Accept-FragmentURI:
>>> time,space,track,name" header, but then we cannot communicate which
>>> types of headers are supported).
>>
>> Thanks for this suggestion: I put it on the agenda for the f2f meeting,
>> first slot hour when we will discuss the single-step and dual-step partial
>> GET (aka, 2-ways, 4-ways handshakes :-)
>
> Cool. I think there is lots to discuss. :)
>
>
>>> Section 7.3, third paragraph (starting "Using HTTP byte ranges...")
>>>
>>> I do not understand this paragraph and I think it is fundamentally
>>> wrong. I think there is a misunderstanding for the 4-way handshake
>>> between how to handle the control section that is non-cachable and
>>> transferred in the first GET action, and how to handle the data
>>> section which is transferred in the second GET action. All the data
>>> that is transferred in the second GET action is simply a byte range
>>> request on the original resource, which means it can be stored in the
>>> exact same way in which existing caching Web proxies store byte range
>>> requests, so there is no extra implementation cost. The control
>>> section is generally small and is returned with the first GET action.
>>> Indeed, there are not an infinite number of resources created in this
>>> way, but exactly only one in the proxies. This is a big advantage of
>>> the 4-way handshake and not a disadvantage.
>>>
>>> Of course the whole idea of caching and reducing bandwidth use falls
>>> down when we need to transcode media resources. Those are never
>>> cachable other than for the exact same fragment URI. For those, the
>>> 2-way handshake is probably more appropriate.
>>
>> Hum, I think the paragraph in the document says the same thing than your
>>  explanation above, or at least, I don't see the contradiction. But I
>> acknowledge as well that the whole story of caching these media fragments
>> and the exact role of the proxies is still heavily discussed within the
>> group. I would suggest to wait for our discussion during the next f2f
>> meeting before doing more changes.
>
> Yeah, I think we need a lot more images and detailed specifications on
> these, maybe even implementations. Looking forward to the f2f sorting
> through some of this!
>
> Cheers,
> Silvia.
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 14 April 2009 14:03:05 UTC