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

S Moonesamy <> Wed, 30 October 2013 08:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA7CB21E80F0; Wed, 30 Oct 2013 01:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.15
X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5gsuwYCShZLy; Wed, 30 Oct 2013 01:43:58 -0700 (PDT)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id CBAD021E8096; Wed, 30 Oct 2013 01:43:27 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r9U8gxk0013206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 01:43:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail2010; t=1383122603; bh=03b49fo2DAGdas52zHjPMR9PGo8yGdLB30mQ8JleKew=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sY4aJJIf8GHC1saeqv0076NyQy4FVVCdt8ff2IiJzDgOnDpQgwOAlDhfX/TWC9ARM doyso6nFH7fJey8nxLf0I5pyHddNEBIn4XNAmDPcsjDY4/aLe5xnBnGqTi2owk6hry inbzSU420J1b612ikw6W2Lxdvf/L/Cdpso5GGNeU=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1383122603;; bh=03b49fo2DAGdas52zHjPMR9PGo8yGdLB30mQ8JleKew=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cB2fGEHMKtv37Dvbl3Y7ZDXJlLCxnW5pfAuQM29EJdiwbei6BRskWhEB3NMOEvrtT 2z+0OHdcQQrRNwYNkQungXVv0iQqRuNXNuEnogrigh2p7hTbFV1m6Ju4ewaj+WBcmV QRu3KmwF6hYSv6jHSGjzPmM+DHuMbjoAryrQ4IKU=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 30 Oct 2013 00:46:51 -0700
To: Julian Reschke <>,,
From: S Moonesamy <>
Subject: Re: #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2013 08:44:01 -0000

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.


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


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.


>>    "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
>>same Content-Type header field in each header area if the selected
>>representation would have a Content-Type header field for a 200 (OK)
>That's what the above says, no?


>Such as?

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

>Right. Fixed in <>.


>It is supposed to be interpreted per RFC 2119.

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

S. Moonesamy