Re: Issue 133, was: multipart/byteranges minimum number of parts

Ok,

so the choices seem to be:

(1) in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-04.html#rfc.section.6.2>, 
  change

"A response to a request for a single range MUST NOT be sent using the 
multipart/byteranges media type. A response to a request for multiple 
ranges, whose result is a single range, MAY be sent as a 
multipart/byteranges media type with one part. ...

to

"A response to a request for a single range MUST NOT be sent using the 
multipart/byteranges media type. Furthermore, a response to a request 
for multiple ranges, whose result is a single range, MUST NOT be sent 
using the multipart/byteranges media type. ..."

or

(2) in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-04.html#rfc.section.A>, 
change

"The multipart/byteranges media type includes two or more parts, each 
with its own Content-Type and Content-Range fields."

to

"The multipart/byteranges media type includes one or more parts, each 
with its own Content-Type and Content-Range fields."


Note that RFC 2046 says 
(<http://tools.ietf.org/html/rfc2046#section-5.1.1>):

"The use of the "multipart" media type with only a single body part may 
be useful in certain contexts, and is explicitly permitted."


Observation: this is an edge case a client can easily avoid, by not 
construction a request with overlapping ranges. Therefore my 
recommendation would be to make the minimal change that fixes, the 
inconsistency, which IMHO is the second option.

BR, Julian



Julian Reschke wrote:
> 
> A. Rothman wrote:
>> Hi!
>>
>> The spec contradicts itself regarding the minimum number of parts in a 
>> multipart/byteranges response: On the one hand, "A response to a 
>> request for multiple ranges, whose result is a single range, MAY be 
>> sent as a multipart/byteranges media type with one part", while on the 
>> other hand, "The multipart/byteranges media type includes two or more 
>> parts". If a multipart/byteranges media type indeed must include two 
>> or more parts, the first statement makes for an illegal response. And 
>> if a one-part response is valid, then the second statement is incorrect.
>>
>> Since the spec also mandates that a client requesting a single range 
>> must never receive a multipart/byteranges response, it seems like the 
>> intention was to make it possible for a client to support partial 
>> retrieval without having to implement multipart support at all, in 
>> which case it would have been more straightforward if the spec simply 
>> required all single-range responses to use Content-Range and not 
>> multipart/byteranges. For backwards compatibility,  it can 
>> encourage/require multipart/byteranges recipients to properly handle 
>> single-part messages as well, which is very likely the case in 
>> existing implementations.
>>
>> In any case, this contradiction should be fixed and the use cases 
>> clarified.
>> ...
> 
> Hi Amichai,
> 
> I believe your analysis is correct, and I have opened issue 
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/133> accordingly.
> 
> BR, Julian
> 
>

Received on Monday, 6 October 2008 14:17:48 UTC