Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
 with ESMTP id 5D34A3A68DD; Sat, 28 Nov 2009 12:27:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYVmRDdrg84j;
 Sat, 28 Nov 2009 12:27:52 -0800 (PST)
Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com
 [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 22FA43A679F;
 Sat, 28 Nov 2009 12:27:52 -0800 (PST)
Received: by gxk4 with SMTP id 4so755752gxk.8 for <multiple recipients>;
 Sat, 28 Nov 2009 12:27:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
 h=domainkey-signature:received:received:message-id:date:from
 :organization:user-agent:mime-version:to:cc:subject:references
 :in-reply-to:content-type:content-transfer-encoding;
 bh=/bWG4eWDhzMQunKlVzLCN0ItC93ElGFqkvwfbagJuQc=;
 b=faH5YIHDimPlZxsAfP9qTmIpbJUWes9jrLhuQgTpmQqWcxaSi5ut85lSwjmMZHu6rw
 +LPb52i5TN9+52jro2B8goswnbTg5lEvVmFmAWVwVAUVg1XJVfBXcj1MqE7741bCPBSU
 Gs7nL0gwuFdOWihrnwldxXAWAgXN2VJD3OM2w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=message-id:date:from:organization:user-agent:mime-version:to:cc
 :subject:references:in-reply-to:content-type :content-transfer-encoding;
 b=GZDHcHreOhb/4AP/x9jFlrZNuffOrJhjvaqWKm6ajv9/4hEFVYOaHC3QU/MN9cL941
 1Qwi7Yb2UaGYGptVwpE7teimjHmcwZueHjh2EN0Mnu1m2vYOxzVvr2Ec2k2uhz0hutKD
 JE7thsmERBfH8lAhCgCXwncNb/rBJNmmbkU0w=
Received: by 10.150.90.17 with SMTP id n17mr2708077ybb.71.1259440060804;
 Sat, 28 Nov 2009 12:27:40 -0800 (PST)
Received: from ?10.1.1.5? ([121.98.142.15]) by mx.google.com with ESMTPS id
 9sm1031142ywf.20.2009.11.28.12.27.37 (version=SSLv3 cipher=RC4-MD5);
 Sat, 28 Nov 2009 12:27:39 -0800 (PST)
Message-ID: <4B1187B5.7080404@gmail.com>
Date: Sun, 29 Nov 2009 09:27:33 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Subject: Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
References: <4AFB6035.2080706@gmail.com>	<4AFD0898.70406@gmx.de>	<4AFD204A.1030609@gmail.com>	<4AFD368E.408@gmx.de>	<4AFDDD24.7030207@gmail.com>	<8349A058-B2B5-4579-8C85-4132BFAE6F07@gbiv.com>	<4AFDF6CF.9030909@gmail.com>	<CE185D2B66641B496FB99442@PST.JCK.COM>	<807563C9-E390-45F2-9F2D-92408274B7A9@gbiv.com>	<BD3924D0500DD38A39440B10@PST.JCK.COM>	<4B02B2B9.9030505@gmx.de>	<DB126835413719B0F184798E@PST.JCK.COM>	<4B02C93E.1020708@gmx.de>
 <4B02FF56.1010805@gmail.com> <8B1F994C-0B0E-4C24-851F-F195BA0FA95D@gbiv.com>
 <4B0E7893.2040405@gmx.de>
In-Reply-To: <4B0E7893.2040405@gmx.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: John C Klensin <john-ietf@jck.com>, "Roy T. Fielding" <fielding@gbiv.com>,
 draft-dusseault-http-patch@tools.ietf.org,
 General Area Review Team <gen-art@ietf.org>,
 IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
 <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
 <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Nov 2009 20:27:53 -0000

I'm quite happy for the subject matter experts to decide between
these two approaches.

Thanks
   Brian

On 2009-11-27 01:46, Julian Reschke wrote:
> Roy T. Fielding wrote:
>> On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote:
>>
>>> These are the sort of changes that would, I believe, give
>>> sufficient indication to a would-be user of PATCH of how
>>> to make it somewhat safe. Personally I'd prefer to see it
>>> made more prominent by starting with something like:
>>>
>>> Clients requiring to verify the consistent application of a
>>> patch document to a known entity SHOULD first acquire an ETag...
>>>
>>> Rationale: the use of a normative keyword will draw the
>>> attention of implementors who might otherwise not think
>>> about this issue.
>>
>> It would also be wrong, because it is neither a requirement
>> for interoperation nor a potential for causing harm (RFC 2119).
>> Aside from which, it makes the original purpose of PATCH
>> non-compliant with its own specification.
>>
>> The purpose of PATCH is to request that the server apply a
>> set of changes to the current state of the target resource.
>> The assumption that these changes will be dependent on a
>> specific prior representation of that resource is false.
>> The server is fully capable of detecting and reporting
>> conflicts when they occur with the current state, as only
>> truly known by the server.
>>
>> In other words ...
>>
>>  If the client wants to prevent the PATCH method from being
>>  applied to a resource for which the state has changed since
>>  the last state known by the client, then it SHOULD use one
>>  or more of the conditional request mechanisms of HTTP
>>  (If-Match and If-Unmodified-Since request headers [RFC2616])
>>  or WebDAV (If request header [RFC4918]) with the
>>  associated metadata from that prior resource state.
>>  However, if the patch media type contains its own mechanism
>>  for detecting conflicts, such as embedded context or metadata
>>  designed to allow non-overlapping changes to be safely applied,
>>  then the conditional request mechanisms SHOULD NOT
>>  be used with PATCH because they would interfere with
>>  collaborative applications, such as shared editors and
>>  whiteboards.
>>
>> FTR, the prior sentence, that PATCH is somehow more likely
>> to result in corrupted state than a PUT, is simply false for
>> any patch format that contains context or post-application
>> integrity checks.  The only reason it was in the spec is
>> because earlier versions assumed a patch format that contains
>> nothing but byte-vector manipulations.  It should be removed,
>> or at least altered to be factual.
>>
>> ....Roy
> 
> In the meantime, a new draft was published, see
> <http://tools.ietf.org/html/draft-dusseault-http-patch-16> and
> <http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-16.txt>
> for the diffs.
> 
> The new text is:
> 
>    A PATCH request can be issued in such a way as to be idempotent,
>    which also helps prevent bad outcomes from collisions between two
>    PATCH requests on the same resource in a similar timeframe.
>    Collisions from multiple PATCH requests may be more dangerous than
>    PUT collisions, because some patch formats need to operate from a
>    known base point or else corrupt the resource.  Clients using this
>    kind of patch application SHOULD acquire a strong ETag [RFC2616] for
>    the resource to be modified, and use that ETag in the If-Match header
>    on the PATCH request to verify that the resource is still unchanged.
>    If a strong ETag is not available for a given resource, the client
>    can use If-Unmodified-Since as a less-reliable safeguard.
> 
> This text is still problematic, in that
> 
> 1) It suggests that the client is in control of the etag ("...acquiere a
> strong etag..."); however, the client has no control over this at all;
> it's the server who decides, and also it's the server who's in charge in
> deciding what type of etags it accepts in which operations.
> 
> 2) It doesn't mention that WebDAV defines another conditional header
> which doesn't have the limitations of If-Match (per RFC2616, not HTTPbis).
> 
> I found Roy's proposal both easy to understand and correct, and like to
> see it (or something more similar to it than the current text) being used.
> 
> Best regards, Julian
>