Re: #462, was: p5: editorial suggestions

Mark Nottingham <mnot@mnot.net> Thu, 20 June 2013 16:53 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3421F9E6C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Jun 2013 09:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.751
X-Spam-Level:
X-Spam-Status: No, score=-7.751 tagged_above=-999 required=5 tests=[AWL=1.452, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18qPs7xJ8POL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Jun 2013 09:53:08 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A33BD21F9E37 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 20 Jun 2013 09:53:07 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Upi6L-0006kp-8a for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Jun 2013 16:52:49 +0000
Resent-Date: Thu, 20 Jun 2013 16:52:49 +0000
Resent-Message-Id: <E1Upi6L-0006kp-8a@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1Upi67-0006ji-R5 for ietf-http-wg@listhub.w3.org; Thu, 20 Jun 2013 16:52:35 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1Upi66-0001vm-8t for ietf-http-wg@w3.org; Thu, 20 Jun 2013 16:52:35 +0000
Received: from [10.71.3.191] (unknown [63.239.94.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0EB0550A84; Thu, 20 Jun 2013 12:52:12 -0400 (EDT)
References: <5CCE9F20-70A3-4AA0-9ACB-733B3809C106@mnot.net> <51C3212B.8000708@gmx.de> <3A1E0833-F39B-4F21-B93F-8A7144935839@mnot.net> <51C330E3.5020905@gmx.de>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51C330E3.5020905@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <0525D6F0-9728-486A-A5AC-0CB800651D16@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
X-Mailer: iPad Mail (10B329)
From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 20 Jun 2013 09:52:12 -0700
To: Julian Reschke <julian.reschke@gmx.de>
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-0.0
X-W3C-Hub-Spam-Report: MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Upi66-0001vm-8t 413f3fa0bc78ed59a8baa13e3ae89f02
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #462, was: p5: editorial suggestions
Archived-At: <http://www.w3.org/mid/0525D6F0-9728-486A-A5AC-0CB800651D16@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18323
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 20/06/2013, at 9:42 AM, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2013-06-20 17:58, Mark Nottingham wrote:
>> 
>> On 20/06/2013, at 8:35 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> 
>>> On 2013-04-23 05:47, Mark Nottingham wrote:
>>>> 
>>>> * 2.1 "A byte range operation MAY specify..."   This is the only place "operation" is used in the document; it should either be defined, or replaced by another term.
>>> 
>>> Done in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2296>.
>>> 
>>>> * 3.1 "...and only if the result of their evaluation is leading toward a 200 (OK) response."  This is a bit informal...
>>> 
>>> Any suggestions?
>> 
>> "would result in"?
> 
> I wasn't sure whether the current text is supposed to leave some wiggle room, but maybe that's not needed.
> 
> So maybe change
> 
> "The Range header field is evaluated after evaluating the preconditions of [Part4] and only if the result of their evaluation is leading toward a 200 (OK) response. In other words, Range is ignored when a conditional GET would result in a 304 (Not Modified) response."
> 
> to
> 
> "The Range header field is evaluated after evaluating the preconditions of [Part4] and only if the result in absence of the Range header field would be a 200 (OK) response. In other words, Range is ignored when a conditional GET would result in a 304 (Not Modified) response."
> 
> ?

Think so.


> 
>>>> * 3.1 "If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable) response."
>>>> 
>>>> Yet 4.4 says: "because servers are free to ignore Range, many implementations will simply respond with 200 (OK) if the requested ranges
>>>> are invalid or not satisfiable."
>>> 
>>> Actually, they'd return 200 even *if* the range is both valid and satisfiable, right? Should we clarify that?
>> 
>> Yes; I think just drop the "if the requested…" clause.
> 
> Yes (<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2297>)
> 
>>>> I think sometimes responding with 200 is the right thing to do here sometimes, and so we shouldn't put a requirement against it. We could either remove the SHOULD, or qualify it with something that allows the server to make a judgement call.
>>> 
>>> 4.4 mentions as a possible reason to prevent clients from resubmitting invalid requests; is this what we should mention here?
>> 
>> Perhaps. Looking at this again, I'm less concerned than I was, but adding that text might be helpful.
> 
> Ok.
> 
>>>> * 4.3 first paragraph re-defines what validator strength is; this should just be a reference to p4.
>>> 
>>> But then it doesn't seem to say exactly the same thing.
>> 
>> Well, that's not good, is it?
> 
> It wouldn't be good, but it probably also wouldn't be something we can change right now.
> 
>>>> * 4.3 last paragraph places a requirement on clients to "record" sets of ranges; how exactly do they meet this requirement? Terminology seems strange.
>>> 
>>> Maybe "process"?
>> 
>> 
>> WFM.
> 
> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2297>
> 
> Best regards, Julian
>