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

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

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

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.

> Incidentally, I have a few more questions on that resolution:
> * why are we using comma as a separator for track HTTP headers?

In the URL, we still have to figure out if we use comma or semi-colon.
In the headers, what would you use if not comma?

> * also note that the spatial dimension can be resolved on the client
> as in Davy's demo rather than sending anything to the server.

Yes, we never say the contrary. And actually, what we said today is that 
for the spatial track, it will most likely happen on the client, and if 
it needs to go to the server, it will be better handled by the query 
parameter.
Cheers.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Tuesday, 9 March 2010 00:35:08 UTC