Re: #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24

[S Moonesamy <[e-mail]>]

Hi Julian,
At 08:27 29-10-2013, Julian Reschke wrote:
>thanks a lot for the incoming reviews! I'm tracking them in the WG's 
>trac instance.

Ok.  As you understand how things work I'll defer to you on the 
issues instead of tracking down what has been addressed.

>Well, it's optional, and we didn't want to make it a SHOULD. It adds 
>overhead to GET responses, even though only few clients will make 
>range requests.

Ok.

>Yes. Do you think this is a problem? Why?

It's the kind of text which generates long threads outside the 
IETF.  Some people can argue that it is a "may" written in uppercase 
while other people will argue that the plain English says something 
else.  My preference is for the intent of the text to be clear unless 
there is a good reason not to be clear.

><http://trac.tools.ietf.org/wg/httpbis/trac/ticket/505>

That's applicable to several drafts in the set.

>"A server that supports range requests MAY ignore or reject a Range 
>header field that consists of more than two overlapping ranges, or a 
>set of many small ranges that are not listed in ascending order, 
>since both are indications of either a broken client or a deliberate 
>denial of service attack (Section 6.1). A client SHOULD NOT request 
>multiple ranges that are inherently less efficient to process and 
>transfer than a single range that encompasses the same data."
>
>..or it can serve the response as multipart/byteranges as requested.

Ok.

>>    "If the selected representation would have had a Content-Type
>>     header field in a 200 (OK) response, the server SHOULD generate
>>     that same Content-Type field in the header area of each body part."
>>
>>I don't understand why the RFC 2119 "should" is used in the above.  When
>>can the "should" be ignored?  Is the server supposed to generate the
>
>Dunno.
>
>>same Content-Type header field in each header area if the selected
>>representation would have a Content-Type header field for a 200 (OK)
>>response?
>
>That's what the above says, no?

Ok.

>Such as?

What I mean is that what happens is undefined when both sides do not 
follow the RFC 2119 "should".

>Right. Fixed in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2441>.

Ok.

>It is supposed to be interpreted per RFC 2119.

It is better to use the uppercase words after the RFC 2119 boilerplate.

Regards,
S. Moonesamy