Subject: [core] Patch idempotent?

From: peter van der Stok <[email-masked]>
Date: Tue, 28 Jul 2015 11:42:27 +0200

Hi all,

During the CoRE meeting on friday, the suggestion was done that an 
idem-potent patch in CoAP should be called iPatch and that Patch itself 
is not necessarily idempotent.

I can identify 2 reasons why patch should not be idempotent:

1) the patch adds new sections to a resource and is not idem-potent when 
for example new sections are identified by invocation date and time.
2) the patch changes the content of the resource as function of the 
resource state e.g. incrementing its values

Other possibilities, not identified by me, may exist.

3) An idempotent Patch can be restricted to replacing a subset of the 
variables in the resource to the same subset with possibly different 
values.

RF6902 restricts its operations to add, remove, move, copy, replace.
The way the operations add, remove, replace are specified in 6902 
implies their idem-potency; copy and move are not because dependent on 
the resource state.

RFC7396 supports only the operations add, remove and replace, and is 
consequently an idem-potent format.

My proposal is to specify Patch for CoAP to be non-idempotent conforming 
to the http interpretation.
This being said, we can add a new method to CoAP, called "iPatch", which 
is idem-potent and probably fulfils what most applications want Patch to 
do (RFC7396 semantics).

The Patch command could then also include RPC semantics like toggle, or 
INC(x), or actuator settings, currently excluded by an idem-potent PUT 
in CoAP.

Looking forward to other opinions,

peter

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jul 2015 10:36:31 +0200

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

---

From: "weigengyu" <[email-masked]>
Date: Wed, 29 Jul 2015 17:22:38 +0800

HI Peter,

It seems not to be a critical issue to be idempotent.
Probably, conditional request can handle this issue.

In RFC5789,
"PATCH is neither safe nor idempotent as defined by [RFC2616], Section 9.1."
"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 time frame.
  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 they will corrupt the resource.  Clients
  using this kind of patch application SHOULD use a conditional request
  such that the request will fail if the resource has been updated
  since the client last accessed the resource.  For example, the client
  can use a strong ETag [RFC2616] in an If-Match header on the PATCH 
request."

In RFC 6902, it is not mention to be idempotent.
"JavaScript Object Notation (JSON) [RFC4627] is a common format for
  the exchange and storage of structured data.  HTTP PATCH [RFC5789]
  extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a
  method to perform partial modifications to resources."
"JSON Patch is a format (identified by the media type "application/
   json-patch+json") for expressing a sequence of operations to apply to
   a target JSON document; it is suitable for use with the HTTP PATCH 
method."

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: peter van der Stok
Sent: Tuesday, July 28, 2015 5:42 PM
To: Core
Subject: [core] Patch idempotent?

Hi all,

peter

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Michel Veillette <[email-masked]>
Date: Wed, 29 Jul 2015 18:56:06 +0000

Hi Carsten, Hi Peter

Assuming:
- YANG is used as modeling language
- keys is always defined for lists
- All key(s) are provided during a POST or DELETE operations
- Only global operations are allowed on leaf-lists

Are we not dealing with just idempotent patch operations?
If not, which use cases are not idempotent?

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]
www.trilliantinc.com   

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: 29 juillet 2015 04:37
To: [email-masked]
Cc: Core
Subject: Re: [core] Patch idempotent?

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:

See

Similar with "remove":

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

---

From: peter van der Stok <[email-masked]>
Date: Thu, 30 Jul 2015 09:28:29 +0200

Hi Michel,

> - YANG is used as modeling language
Is not valid for other applications that (may) use Patch in CoAP.

For example the use of move, add and copy suggested by RFC 6902 are not 
idempotent.

Peter

Michel Veillette schreef op 2015-07-29 20:56:
> 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:
> 
> one in its place -- this requires a way to express what is meant by
> "the item").
> 
> Grüße, Carsten
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 30 Jul 2015 09:27:27 +0100

I tend to agree - why does PATCH need to be idempotent? Only two of its
applications (replace, delete) seem obviously idempotent. The partial
operation of PATCH also implies its operation in a sequence. Then the
idempotency of the whole sequence needs to be considered.

Robert

On 29 July 2015 at 10:22, weigengyu <[email-masked]> wrote:

> -----原始邮件----- From: peter van der Stok