Re: Objection to use of Range for non-byte sections (from Conrad)

2010/3/9 Raphaël Troncy <raphael.troncy@cwi.nl>:
>> While I do not quite understand Conrad's use case, I agree partially
>> (and maybe fully) with the objection to that resolution.
>
> There is no resolution, so there is no objection yet from my point of view.
>
>> I think we can continue using "Range" as the request header from the
>> client for all of the dimensions we are talking about (Range on bytes,
>> t, track and id).
>
> I'm not sure Conrad agrees on that. Do you Conrad?

I don't agree with using Range for t, track and id.

>> But, I do not believe we can use "Content-Range" as the reply header
>> for any of the dimensions bar bytes. This is why we introduced
>> "Content-Range-Equivalent".

I think it is clear to keep headers in request/response pairs, eg:
Accept-Language/Content-Language, Range/Content-Range. I don't think
it is wise for us to suddenly introduce new behavior for the Range
header (ie. it sometimes turns into Content-Range, sometimes into
Foo).

Also I think it is useful for a UA to be able to specify "Range:
bytes" and "Foo: t" independently (eg. to download part of a subview),
and it is also useful for proxies to be able to handle the byte Range
transport independently of the Foo representation.

> We had a lot of discussion about that today, and in particular the fact that
> Content-Range-Equivalent will not solve your problem either. I suggest we do
> a summary of this discussion tomorrow morning on the phone.

I would also be interested in seeing that summary (in text :)

Conrad.

Received on Tuesday, 9 March 2010 01:10:36 UTC