Re: [core] Patch idempotent?

Carsten Bormann <cabo@tzi.org> Wed, 29 July 2015 08:36 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E59B1B34C4 for <core@ietfa.amsl.com>; Wed, 29 Jul 2015 01:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.15
X-Spam-Level: *
X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRrHILt7Tnl4 for <core@ietfa.amsl.com>; Wed, 29 Jul 2015 01:36:38 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35511B34AA for <core@ietf.org>; Wed, 29 Jul 2015 01:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t6T8aXDI005564; Wed, 29 Jul 2015 10:36:33 +0200 (CEST)
Received: from alma.local (p5DC7F6B9.dip0.t-ipconnect.de [93.199.246.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mh7Wj3k30zDGnd; Wed, 29 Jul 2015 10:36:33 +0200 (CEST)
Message-ID: <55B8908F.8020808@tzi.org>
Date: Wed, 29 Jul 2015 10:36:31 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.1 (Macintosh/20150514)
MIME-Version: 1.0
To: consultancy@vanderstok.org
References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl>
In-Reply-To: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/0xpkITI15ov8h7Gq3LtAuGaS4pI>
Cc: Core <core@ietf.org>
Subject: Re: [core] Patch idempotent?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2015 08:36:39 -0000

Hi Peter,

I also believe that, if we are going down the idempotent alley, we'll
need to distinguish PATCH (not necessarily idempotent, like HTTP PATCH)
from iPATCH (idempotent, something new).  Whether, in the end, we want
to add both to CoAP: I don't have an opinion on that yet.

A few more data points:

RFC 6902 "add" is not necessarily idempotent.

See
http://tools.ietf.org/html/rfc6902#appendix-A.2
for an illustration.

(Doing the patch again leads to
   { "foo": [ "bar", "qux", "qux", "baz" ] })

Similar with "remove":

http://tools.ietf.org/html/rfc6902#appendix-A.4

In contrast, RFC 7396 operations always appear to be idempotent, but
then, there are no array operations in RFC 7396 at all.  Positional
array operations are harder to get idempotent because positions change
because of the operation.  Getting idempotency for array operations
would require some content searching (i.e., if "the item" is already
there, don't add it again; if it is already gone, don't remove another
one in its place -- this requires a way to express what is meant by "the
item").

Grüße, Carsten