Re: must a partial response range be exact?

Henrik,


I'm confused about what you mean by 'The MAY only applies if the SHOULD 
is fulfilled'. In this case, if the SHOULD is fulfilled the way u 
intended in your original reply, i.e. a multiple-range request SHOULD be 
fulfilled with a multiple-range response, then the MAY clause can never 
be used, since replying to such a request with a single-part response 
violates this SHOULD requirement. In other words, to my understanding, 
if the SHOULD is fulfilled then the MAY can never apply (and may as well 
be dropped from the spec). Hence the confusion :-)


If I misunderstood your interpretation of this SHOULD clause and how 
exactly it might bite if a multiple-range request is fulfilled using a 
single-range response (returning a superset of all requested ranges), 
I'd appreciate a clarification...


Thanks,

Amichai


Henrik Nordstrom wrote:

> On tor, 2008-10-09 at 22:00 +0200, A. Rothman wrote:
>   
>> Thanks for pointing that out!
>>
>> However, if that is so, then given that "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", the spec MAY have this
>> SHOULD clause bite itself as well (in exactly the same sense as
>> returning a single Content-Range response)...
>>     
>
> There is no contradiction. The MAY only applies if the SHOULD is
> fulfilled. A MAY never has higher priority than SHOULD.
>
> The specifications is a sum of MUST and SHOULD requirements, and MAY
> hints on possible alternative ways of doing things as long as the MUST
> and SHOULDs is also fulfilled.
>
> But implementations MAY disregard SHOULD level requirements if they
> insist, provided they understand the implications. Only MUST level
> requirements is strictly required.
>
> It's not possible to expand each clause to express the full conditions,
> as this would result in the specifications being repeated all over, with
> tons of opportunity for contradictions.
>
> Regards
> Henrik
>   

Received on Thursday, 9 October 2008 22:51:25 UTC