- From: Raphaël Troncy <Raphael.Troncy@cwi.nl>
- Date: Wed, 02 Dec 2009 10:58:27 +0100
- To: Yves Lafon <ylafon@w3.org>
- CC: Media Fragment <public-media-fragment@w3.org>
Hi Yves, >> --> We took a resolution regarding the syntax of the Range and >> Content-Range headers, see [5], but we haven't take any regarding the >> syntax of Accept-Ranges. Should we put here 'seconds'? Or rather >> 'time'? Or 'time:npt'? > > We should reuse the exact same unit, in that case time:npt. OK, thanks for the clarification. I have modified the RESOLUTION page accordingly: http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers >> * Summary: >> . 1.1: NO new headers are necessary / normal use of Range request with >> 206 response code >> . 1.2.a: This is fully similar to 1.1 >> . 1.2.b: The 'Fragment' and 'Content-Fragment' headers are introduced >> / 200 response code >> . In all cases, the body of the response contains the binary data of >> the fragment > > Issue is that you get multiple value for the same URI (which is OK), but > with no way to differentiate between them. There should be at least a > Content-Location with the explicit URI of this fragment as a complete > reource representation. I don't understand this. Could you explain? In which situation (1.1 / 1.2) we end up with multiple values for the same URI? What are these values? Could you write down the example with the Content-Location header in the response? >> 2) Case 2: Resolving URI fragments in a proxy cachable manner >> ------------------------------------------------------------- > > time ranges _are_ cacheable ! What is the main trigger then for going for 2 round-trips? 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 Wednesday, 2 December 2009 09:59:17 UTC