Re: ACTION-112: Digest of Conrad's vs Current's proposal for Media Fragment processing

On Wed, 2 Dec 2009, Raphaël Troncy wrote:

> 2) Case 2: Resolving URI fragments in a proxy cachable manner
> -------------------------------------------------------------
>
> Context: see Section 3.4 [2].
> We have a fully media fragment conformant user agent and wish to make sure 
> fragments will be cached by the network
> User request: 
> http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21
>
> * 2.1: Current proposal:
> The following HTTP request will be generated.
> GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
> Host: www.w3.org
> Accept: video/*
> Range: time:npt=12-21
> X-Accept-Range-Redirect: bytes
>
> --> We introduce the 'X-Accept-Range-Redirect' header
>
> The following HTTP response is returned (200 code)
> HTTP/1.1 200 OK
> Accept-Ranges: bytes
> Content-Type: video/mp4
> X-Accept-TimeURI: npt, smpte-25
> X-Range-Redirect: bytes 1113724-2082711/4500000
> Vary: X-Accept-Range-Redirect
> Location: http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4

First: s/X-//.

Also your reply is a 200 but what is sent back (the empty body Raphael 
refers to)? What would a UA or a cache do with that?
It might be better to send back a 307, redirecting to itself, but I am 
wondering what a cache would do if there is already something cached (in 
bytes, as if it's cached in the time range, it can serve it directly).

Another way would be to do conneg with a mime type 
application/time-range-resolver and send back the info in the body with a 
Vary: accept (but would it trash an already cached entry in the cache?)

> --> We introduce the 'X-Range-Redirect' header to tell the UA to issue 
> another request
> --> I don't like the 'X-Accept-TimeURI' header that could be more generic
> --> Do we have an empty body at this step?
>
> Another HTTP request is issued
> GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
> Host: www.w3.org
> Range: bytes 1113724-2082711
>
> Triggering the following response (206 code)
> HTTP/1.1 206 Partial Content
> Accept-Ranges: bytes
> Content-Type: video/mp4
> Content-Range: bytes 1113724-2082711/4500000
>
> --> I don't understand how the cache can now map the bytes range with the 
> original request in seconds?

Well, in that case the request is in bytes only. However we miss the 
information about the real time range it identifies, most probably not 
exactly the requested "time:npt=12-21", so we need to convey that 
information back in the first reply.

> * 2.2: Conrad's proposal:
>
> Conrad introduced the Range-refer proposal. See [3] for the explanation and 
> [4] for an example.
>
> The following HTTP request will be generated.
> GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
> Host: www.w3.org
> Fragment: time:npt=12-21
> Accept-Range-Refer: npt
>
> The server that supports 'Range-Refer: time' responds with (200 code):
> HTTP 200 OK
> Content-Length: 1000
> Content-Fragment: time:npt=12-21
> Vary: Fragment, Accept-Range-Refer
> Range-Refer: this npt 12-21, 
> http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4 time 12-21
>
> --> Conrad, could you please write somewhere the syntax for 'Range-Refer' 
> since all words see important (e.g. 'this')

Same comment as a previous email wrt Fragment, conneg and resource 
representations.

> The UA then uses the body of this response to decode time 12-21, and issues 
> an HTTP range request to http://www.w3.org for the referred range. Note that 
> this is a normal HTTP/1.1 request using the time range units, and need not be 
> to a server supporting Range-Refer:
> GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
> Host: www.w3.org
> Range: time:npt=12-21
>
> The server responds with:
> HTTP 206 Partial Content
> Content-Length: 3571437
> Vary: Fragment, Accept-Range-Refer
> Content-Range: time:npt 12-21/36
>
> * Summary:
> . 2.1: 2 round-trips are necessary. Two new headers are introduced in the 
> first round-trip ('X-Accept-Range-Redirect' and 'X-Range-Redirect'). The 
> second round-trip is a normal bytes Range request with 206 response code
> . 2.2: 2 round-trips are also necessary. The 'Fragment' and 
> 'Content-Fragment' headers are introduced like for the case 1.2. Two more 
> headers are introduced ('Accept-Range-Refer' and 'Range-Refer')
> . In all cases, the body of the 2nd response contains the binary data of the 
> fragment
>
> Best regards.
>
>  Raphaël
>
>
> [1] 
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-server
> [2] 
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-proxies
> [3] http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Range_Refer
> [4] 
> http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples#Fragment_URI_.2B_Range-Refer:_time
> [5] 
> http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
>
>

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

         ~~Yves

Received on Wednesday, 2 December 2009 16:02:53 UTC