Re: #462, was: p5: editorial suggestions

Julian Reschke <julian.reschke@gmx.de> Thu, 20 June 2013 16:44 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 4240521F9E45 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Jun 2013 09:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.313
X-Spam-Level:
X-Spam-Status: No, score=-8.313 tagged_above=-999 required=5 tests=[AWL=2.286, BAYES_00=-2.599, 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 AsYFTBEJKaIL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Jun 2013 09:43:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3321F9E1D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 20 Jun 2013 09:43:47 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uphwk-0007vq-TB for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Jun 2013 16:42:54 +0000
Resent-Date: Thu, 20 Jun 2013 16:42:54 +0000
Resent-Message-Id: <E1Uphwk-0007vq-TB@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1UphwX-0007v7-PS for ietf-http-wg@listhub.w3.org; Thu, 20 Jun 2013 16:42:41 +0000
Received: from mout.gmx.net ([212.227.15.19]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1UphwW-0001X7-Gc for ietf-http-wg@w3.org; Thu, 20 Jun 2013 16:42:41 +0000
Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MXTLc-1Ulsh61oFK-00WYYb for <ietf-http-wg@w3.org>; Thu, 20 Jun 2013 18:42:14 +0200
Received: (qmail invoked by alias); 20 Jun 2013 16:42:14 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 20 Jun 2013 18:42:14 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX188hmcOfaI8rolQ7bRtzz/c2FFurMtXMWN3+m51M6 MPnjM69m0uwsWd
Message-ID: <51C330E3.5020905@gmx.de>
Date: Thu, 20 Jun 2013 18:42:11 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
References: <5CCE9F20-70A3-4AA0-9ACB-733B3809C106@mnot.net> <51C3212B.8000708@gmx.de> <3A1E0833-F39B-4F21-B93F-8A7144935839@mnot.net>
In-Reply-To: <3A1E0833-F39B-4F21-B93F-8A7144935839@mnot.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=212.227.15.19; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.394, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UphwW-0001X7-Gc 47df8a41fd1ccd0c16631d27add01573
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #462, was: p5: editorial suggestions
Archived-At: <http://www.w3.org/mid/51C330E3.5020905@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18321
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 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."

?

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