W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: issue 85 - range unit extensions

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 30 Mar 2009 16:46:53 +0200
Message-ID: <49D0DB5D.9020102@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
CC: Mark Nottingham <mnot@mnot.net>
Mark Nottingham wrote:
> 
> Issue 85 <http://tools.ietf.org/wg/httpbis/trac/ticket/85> asks us to 
> clarify what content-range unit extensions (i.e., things other than 
> "bytes") are, or get rid of them.
> 
> Julian has pointed out that there's at least one other one existent 
> today (although not formally specified); see 
> <http://msdn.microsoft.com/en-us/magazine/cc301869.aspx>.
> 
> I think the right thing to do here is to document how they're to be 
> extended (most likely in section 3 of p5).

This has been done in draft 06, but there are a few TODOs left...

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

I think that still needs to be done.

> We'll also need to determine what the requirements for registration are 
> (standards-track?), and set up the registry.

For now we haven't defined a registry (I think the idea was to wait for 
the first use case to come up and then discuss again).

> 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:
> 
> 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*

This has been done.

> 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?

Leftovers:

- We currently do not allow the syntax Microsoft is using for row ranges 
in Exchange 
(<http://msdn.microsoft.com/en-us/library/aa123634(EXCHG.65).aspx>); 
should this be tracked as an open issue, or are we in agreement this 
stays invalid? (feedback from MS would be useful here)

- I found it non-intuitive that multipart/byteranges works for other 
range units as well, and opened a ticket as a reminder 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/150>)

- Finally, in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-06.html#rfc.section.5.4.2>, 
we have:

   Range   = "Range" ":" OWS Range-v
   Range-v = byte-ranges-specifier
           / other-ranges-specifier
   other-ranges-specifier = 1*CHAR

Shouldn't other-ranges-specifier be something like:

   other-ranges-specifier = other-range-unit "=" 1*CHAR

...so that a recipient can parse the unit name out of the header in a 
generic way? (unless I'm missing something obvious, this should be 
tracked as a separate issue)

Best regards, Julian
Received on Monday, 30 March 2009 14:47:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:01 GMT