A proposal for generalizing the byte-range referral HTTP Response header

Re: the Media Fragments WD. Here I am using the term "byte-range referral" for multiple concatenated HTTP requests, for the purpose of improving cacheability; this is called a "4-way handshake" in the current working draft.

Shortcomings of the existing byte-range referral scheme

The above WD, and the current Annodex scheme, are specified to allow sharing of non-header data between different temporal views of media resources. They limit the positioning of custom data to the media headers. different segments to have different headers, which is useful for Ogg but not necessarily so for other formats.

Even for Ogg, it could be useful to refer to the codebooks separately from the Skeleton for more finely-grained data re-use. Then a client can locally cache the codebooks and know not to bother retrieving them over and over; but to get the updated skeleton and keyframe data for temporal segment requests.

Hence, I am proposing that we should specify an ordered list of tuples of (URI, byte range) which the concatenation of is byte-wise identical to the byte contents of the requested URI

This response can also contain data, so if you want to refer to this response you can include a tuple of (this, range) where this is the literal string "this", and refers to the body of the current response.

This syntax then allows the server to include parts from many different URLs. The custom data is then centralized in this response, and can be used for any parts of construction of the response so that it can be used for tail data (such as ID3 tags, divx seek tables etc.)

List and tuple separator characters

The list separator should be commas, as this then allows the list to be separated over HTTP response lines (without re-ordering).

Hence the tuple separator should not be commas; it can simply be whitespace:

Range-Referral: http://www.example.com/video.ogv?headers 0-1280
Range-Referral: http://content1.example.com/video.ogv 5380-48204
Range-Referral: this 0-950
Range-Referral: http://content1.example.com/video.ogv 60880-238382

By comma replacement, this set of headers is equivalent to the single header:

Range-Referral: http://www.example.com/video.ogv?headers 0-1280, http://content1.example.com/video.ogv
5380-48204, this 0-950, http://content1.example.com/video.ogv 60880-238382

Interpretation of other response headers

The body of this request is simply all the custom parts for this view, concatenated bytewise. The Range-Referral header explains how to use this data.

Content-Length: is the length of the body.

A Range request is made relative to the body. So for example a client could just do a HEAD request to get the Range-Referral headers, and then do multiple Range requests to retrieve the reqired parts in sequence (rather than locally caching all the data for tailers etc.). Coherence of the concatenated responses can be assured by the use of existing HTTP/1.1 caching identifiers.

So, this constructed response is only special in that a user agent knows how to use it in conjuction with other URI response data to display a media segment. Otherwise it is standard HTTP, and can have caching headers/tags attached, be cached by intermediate proxies, and itself be the subject of range requests.

Generalization to other segment types

This mechanism allows a complex sequence of byte-ranges to be specified. It explicitly marks data ranges which are re-usable, allowing them to be cached. It generalizes so that any complex data subview can be served, where re-usable data is keyed canonically and can be cached on the network.

For example, it may be useful for specifying the data for a spatial subrange of video.