Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt

Hi Peter

You seem to agree that the replace operation uses in the two examples is idempotent.
"showing that the replace op is idem-potent"
" Do you think a non-idempotent example would help?"

In this case, why these examples use PATCH instead of iPATCH?

I'm still confuse about this notion of PATCH vs. iPATCH.
Regards,

Michel

-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl] 
Sent: March-09-16 3:03 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: consultancy@vanderstok.org; Core <core@ietf.org>
Subject: RE: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt

Hi Michel,

see below

Michel Veillette schreef op 2016-03-08 20:38:
> Hi Peter.
> 
> About "don't think so, why?"
> 
> An update operation is not always idempotent.
> For both  examples, don't we have the following behaviour?
>   f(f("x-coord": 256) = f("x-coord": 256) = "x-coord": 45

and if I understand your notation:
f(f("x-coord": 45) = f("x-coord": 45) = "x-coord": 45

showing that the replace op is idem-potent. Independent of the number of times that you execute it, the results is the same.
> 
> First example:
>   PATCH CoAP://www.example.com/object Content-Type: 
> application/json-patch+json
>   [ { "op":"replace","path":"x-coord","value":45} ]
> 
> Second example:
>   PATCH CoAP://www.example.com/object Content-Type: 
> application/merge-patch+json
>   {  "x-coord" : 45 }
> 
> So, should we replace the PATCH by an iPATCH?
> I just trying to understand how this work.

PATCH invocation do not need to be idem-potent but are allowed to be idem-potent.
So both iPATCH and PATCH would be correct here.

Do you have suggestions for clarifications?
Do you think a non-idempotent example would help?

> 
> Michel
> 
> -----Original Message-----
> From: peter van der Stok [mailto:stokcons@xs4all.nl]
> Sent: March-08-16 3:17 AM
> To: Michel Veillette <Michel.Veillette@trilliantinc.com>
> Cc: consultancy@vanderstok.org; Core <core@ietf.org>
> Subject: RE: [core] Fwd: New Version Notification for 
> draft-vanderstok-core-comi-09.txt
> 
> Hi Michel
> 
> see below.
> 
> Michel Veillette schreef op 2016-03-07 15:42:
>> Hi Peter
>> 
>> We are correctly in final review process of the mapping draft prior 
>> publishing.
>> The current version is available at:
>> https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-ma
>> p
>> ping-latest.html
> 
>> pvds> will try </pvds>
>> 
>> If possible, send me your comments before Wednesday to give us some 
>> time to apply them.
>> 
>> About "draft-vanderstok-core-patch-02", in the examples:
>> - should "Content-Type" be replaced by "Content-Format" since it's a 
>> CoAP request?
> 
> <pvds>
> good remark, In the coap RFC content-Type is used a few times, and 
> content-format mostly.
> I will change
> </pvds>
>> - should PATCH be replaced by "iPATCH"
> <pvds>
> don't think so, why?
> </pvds>
>> 
>> More globally, do we really need two methods "PATCH" and "iPATCH"?
> <pvds>
> people like idem-potent as explained in earlier e_mail by Carsten 
> other people prefer more freedom by removing idem-potency restriction.
> Both camps have valid arguments.
> </pvds>
> 
>> If both methods are supported, should the client select to proper 
>> method per request or just on the potential for a method to sometime 
>> create non-idempotent requests?
>> For example, should the client use iPATCH for a "replace" and PATCH 
>> for a "insert-after"?
>> 
>>   iPATCH CoAP://www.example.com/object
>>         Content-Type: application/json-patch+json
>>   [
>>     { "op":"replace","path":"/x-coord","value":45}
>>   ]
>> 
>>   PATCH CoAP://www.example.com/object
>>         Content-Type: application/json-patch+json
>>   [
>>     { "op":"insert-after", "insertion-point" : "/y-coord", 
>> "path":"/z-coord","value":45}
>>   ]
> <pvds>
> My opinion:
> Both iPATCH and Patch can be invoked.
> When the content suggests a non-idem-potent update (like add an item 
> to an array)
> - the Patch should execute the update
> - and iPatch should return an error and do nothing (atomicity) </pvds>
>> 
>> Regards,
>> Michel Veillette
>> 
>> -----Original Message-----
>> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der 
>> Stok
>> Sent: March-07-16 3:37 AM
>> To: Core <core@ietf.org>
>> Subject: [core] Fwd: New Version Notification for 
>> draft-vanderstok-core-comi-09.txt
>> 
>> Dear all,
>> 
>> a New version of the comi draft has been submitted.
>> 
>> - All yang hash text has been removed and the draft refers to 
>> bierman-core-yang-hash draft. draft refers to managed numbering.
>> - All YANG to CBOR mapping has been removed, the draft waits for the 
>> publication of the yang-cbor draft
>> - the draft lists all differences with restconf
>> - rpc has been added.
>> - and several other editorials.
>> 
>> Peter
>> 
>> -------- Oorspronkelijke bericht --------
>> Onderwerp: New Version Notification for 
>> draft-vanderstok-core-comi-09.txt
>> Datum: 2016-03-07 09:30
>> Afzender: internet-drafts@ietf.org
>> Ontvanger: "Peter van der Stok" <consultancy@vanderstok.org>, "Peter 
>> Van der Stok" <consultancy@vanderstok.org>, "Andy Bierman"
>> <andy@yumaworks.com>
>> 
>> A new version of I-D, draft-vanderstok-core-comi-09.txt has been 
>> successfully submitted by Peter van der Stok and posted to the IETF 
>> repository.
>> 
>> Name:		draft-vanderstok-core-comi
>> Revision:	09
>> Title:		CoAP Management Interface
>> Document date:	2016-03-07
>> Group:		Individual Submission
>> Pages:		48
>> URL:
>> https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-09.tx
>> t
>> Status:
>> https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/
>> Htmlized:
>> https://tools.ietf.org/html/draft-vanderstok-core-comi-09
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-09
>> 
>> Abstract:
>>     This document describes a network management interface for
>>     constrained devices, called CoMI.  CoMI is an adaptation of the
>>     RESTCONF protocol for use in constrained devices and networks.  
>> The
>>     Constrained Application Protocol (CoAP) is used to access 
>> management
>>     data resources specified in YANG, or SMIv2 converted to YANG.  
>> CoMI
>>     use the YANG to CBOR mapping and encodes YANG names to reduce 
>> payload
>>     size.
>> 
>> Note
>> 
>>     Discussion and suggestions for improvement are requested, and 
>> should
>>     be sent to core@ietf.org.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core