Re: issue 85 - range unit extensions

On Tue, 5 Aug 2008, Julian Reschke wrote:

> Mark Nottingham wrote:
>> ...
>> Straw-man proposal (not exact text):
>> 
>> Range-unit extensions SHOULD NOT be specific to any format. This is because 
>> caches are allowed to combine ranges from multiple responses, and to serve 
>> range requests out of cache; format-specific range units make it less 
>> likely that implementations will be able to do this (although there may be 
>> exceptions, hence the SHOULD NOT). An informational reference to p6 to 
>> highlight this to potential extenders would be a good idea.
>> ...
>
> 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.

>> We'll also need to determine what the requirements for registration are 
>> (standards-track?), and set up the registry.
>> ...
>
> That's quite some effort for something where we're not sure whether it's 
> going to be used. Should we consider delaying the registry until later?

Yes, it can probably wait, but if it's a low hanging fruit to add another 
small registry...

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

>> Content-Range = "Content-Range" ":" content-range-spec
>> 
>> content-range-spec      = byte-content-range-spec / ext-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
>> ext-content-range-spec = other-range-unit SP CHAR*
>
> +1
>
> I'm not totally sure we need to fix this for Microsoft's use case (which uses 
> "=" instead of SP). It seems to use SEARCH (can somebody contact the author 
> of that spec ... ;-), while "Content-Range" seems to apply only to GET. Or 
> doesn't it?
>
>
>> Note that section 6.2 places several requirements on the use of the 
>> Content-Range header which assume that byte-ranges are in use; we'd need to 
>> adjust the language appropriately.
>> 
>> Beyond that, I can't see what else we'd need to specify; everything else is 
>> unit-specific.
>> 
>> 
>> Thoughts?
>
> My proposal would be to just fix the grammar in 6.2, and restructure 6.2 so 
> that the "bytes" specific stuff ends up in a subsection 6.2.1, and we add a 
> 6.2.2 talking about extensions.
>
> BR, Julian
>
>

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

         ~~Yves

Received on Tuesday, 5 August 2008 17:28:24 UTC