Re: #461, was: p4: editorial suggestions

Mark Nottingham <mnot@mnot.net> Mon, 06 May 2013 02:31 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 8CC0121F854E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 5 May 2013 19:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, 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 jTc2iF8yzTST for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 5 May 2013 19:31:32 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 94FF121F86B2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 5 May 2013 19:31:32 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UZBBF-0001cR-VY for ietf-http-wg-dist@listhub.w3.org; Mon, 06 May 2013 02:29:33 +0000
Resent-Date: Mon, 06 May 2013 02:29:33 +0000
Resent-Message-Id: <E1UZBBF-0001cR-VY@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 1UZBAx-0001bZ-Lj for ietf-http-wg@listhub.w3.org; Mon, 06 May 2013 02:29:15 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UZBAx-0001QO-0y for ietf-http-wg@w3.org; Mon, 06 May 2013 02:29:15 +0000
Received: from [192.168.1.80] (unknown [118.209.105.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 338F722E255; Sun, 5 May 2013 22:28:51 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <5182102B.2080200@gmx.de>
Date: Mon, 6 May 2013 12:28:49 +1000
Cc: Ken Murchison <murch@andrew.cmu.edu>, ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FED5920-BC5D-409B-98E1-CF15CFF7EFE4@mnot.net>
References: <517FC225.4020609@gmx.de> <517FD961.5020108@andrew.cmu.edu> <1A0A9A80-3552-43F0-8A30-4235660ABBC3@mnot.net> <5182102B.2080200@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.442, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UZBAx-0001QO-0y 5bc101b06ca6922dcb8c67a2cf3fbeab
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #461, was: p4: editorial suggestions
Archived-At: <http://www.w3.org/mid/5FED5920-BC5D-409B-98E1-CF15CFF7EFE4@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17842
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 02/05/2013, at 5:05 PM, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2013-05-01 01:26, Mark Nottingham wrote:
>> 
>> On 01/05/2013, at 12:46 AM, Ken Murchison <murch@andrew.cmu.edu> wrote:
>> 
>>> On Tue, 30 Apr 2013 15:07:49 +0200, Julian Reschke wrote:
>>>> On 2013-04-23 05:47, Mark Nottingham wrote:
>>>> 
>>>>> * 3.1 "...instead they MUST respond with the 412 (Precondition Failed) status code."  This is too strong; e.g., what if authentication is needed? Suggest an "unless..." clause allowing other error status codes.
>>> 
>>> The first paragraph of Section 5 seems to address the case of 401 and any other errors:
>>> 
>>> "For each conditional request, a server must evaluate the request preconditions after it has successfully performed its normal request checks (i.e., just before it would perform the action associated with the request method). Preconditions are ignored if the server determines that an error or redirect response applies before they are evaluated. Otherwise, the evaluation depends on both the method semantics and the choice of conditional."
>>> 
>>> The second sentence in Section 3 references Section 5 as far as when preconditions are applied.  This seems sufficient to me, but perhaps that is because I have read the document several times and know what it says in its entirety.
>> 
>> Unfortunately, some (many) people will read the MUST and just stop.
> 
> Not convinced. We could move the text into each status code description, but I don't think it makes things much clearer.
> 
>> Also, everywhere else we suggest the most sensible status code to use in a situation, barring exceptions (which is essentially what we're doing here), it's SHOULD; the MUST here seems sorely out of place.
> 
> Why?


Here's a small sample of similar requirements in p2 (there are many, many more):

* When a request method is received that is unrecognized or not implemented by an origin server, the origin server SHOULD respond with the 501 (Not Implemented) status code.

* When a request method is received that is known by an origin server but not allowed for the target resource, the origin server SHOULD respond with the 405 (Method Not Allowed) status code.

* If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created (Section 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).

* 4.3.4 "If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) or 204 (No Content) response SHOULD be sent to indicate successful completion of the request."

What makes this one a MUST but the rest SHOULDs? Or are we just using these terms completely arbitrarily?



--
Mark Nottingham   http://www.mnot.net/