Re: issue 85 - range unit extensions

Yves Lafon wrote:
>> Playing the devil's advocate: is there *any* range unit other than 
>> "bytes" we can think of that is indeed independent of formats? Right 
>> now, I can't think of any.
> 
> The text proposed by Mark uses SHOULD NOT, not MUST NOT. In some case, 
> it might be ok to use a format specific range unit, like 'character' 
> (for text content in multi/variable-bytes encodings), or 'frames' for 
> video content. I am not saying that those are good examples, just that 
> it may happen.

I totally agree this could happen. My point was that in practice most 
extensions may be format specific, thus even a SHOULD NOT would be to 
strong.

> ...
>>> Furthermore, Section 6.2 - the BNF says:
>>>
>>>> Content-Range = "Content-Range" ":" content-range-spec
>>>>
>>>> content-range-spec      = byte-content-range-spec
>>>> byte-content-range-spec = bytes-unit SP
>>>>                           byte-range-resp-spec "/"
>>>>                           ( instance-length | "*" )
>>>>
>>>> byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
>>>>                                | "*"
>>>> instance-length           = 1*DIGIT
>>>
>>> This does not allow other range units to be used. If we keep them, 
>>> this BNF needs to be changed to something like:
> 
> Well, is it forbidden to ask servers to give back byte-ranges that a cache
> can... cache ? What is transported is bytes, so requesting the 10 first 
> characters of an utf-8 document and receiving 12 bytes using a 
> Content-Range in bytes might help caches to DTRT, so I am not sure that 
> the proposed BNF change is desirable (as "exotic" Content-Ranges won't 
> be cached for sure).
 > ...

It would be useful for caches, but not for the client, right? It would 
still need to know what range with respect to the original range unit 
was returned.

I also note that Range (Section 6.4) would need additional work as well.

BR, Julian