W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2010

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

From: Conrad Parker <conrad@metadecks.org>
Date: Tue, 9 Mar 2010 10:10:03 +0900
Message-ID: <dba6c0831003081710x7736bcbp96e12af64bbfbc03@mail.gmail.com>
To: raphael.troncy@eurecom.fr
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Media Fragment <public-media-fragment@w3.org>
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

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

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

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