Re: [core] content-formats for cbor YANG

Hi Michel,

The semantics of the PUT and GET specify that the payload replaces 
(represents) the whole payload.
Applying PUT semantics to a PATCH payload has as consequence that you 
loose unintentionally large parts of the resource.
A different content-format signals this semantics difference.
The FETCH payload may contain only an array of YANG-CBOR identifiers and 
each identifier represents GET semantics

Not all CBOR documents represent YANG to CBOR mappings, that's why the 
content format
application/yang-data+cbor is proposed equivalent to 
application/yang-data+json.

Does that help?

Peter

Michel Veillette schreef op 2017-04-20 15:40:
> Hi Peter, Hi Carsten
> 
> The following table summarizes the different payload uses by CoMI.
> 'value' is defined in
> https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-4
> 'instance-identifier' is defined in
> https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-5.13.1
> 
> Use Case	                  | Request payload                         |
> Response payload
> ----------------------------------+-----------------------------------------+----------------------------------------
> GET /c/instance-identifier        | na
>      | value
> PUT /c/instance-identifier        | value                               
>     | na
> POST /c/instance-identifier       | value                               
>     | na
> DELETE /c/instance-identifier     | na                                  
>     | na
> GET /c                            | na
>      | CBOR array (instance-identifier, value)
> PUT /c	                          | CBOR array (instance-identifier, 
> value) | na
> POST /c	                          | CBOR array (instance-identifier, 
> value) | na
> FETCH /c                          | CBOR array (instance-identifier)
>      | CBOR array (value)
> iPATCH/c                          | CBOR array (instance-identifier, 
> value) | na
> POST /c/instance-identifier (RPC) | value
>      | value
> GET /s (Notification)             | value or CBOR array (value)         
>     | na
> 
> As you can see, the payload of a iPATCH /c request have the same
> format a PUT /c request, POST /c request and GET /c response.
> What will be the rational to use a different Content-Format for the 
> iPATCH?
> Can we simply use (Content-Format: application/cbor) in all cases?
> 
> Quick note, draft-ietf-core-yang-cbor don't propose any
> Content-Format, this is left to  draft-ietf-core-comi.
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: Thursday, April 20, 2017 4:55 AM
> To: peter van der Stok <consultancy@vanderstok.org>
> Cc: Core <core@ietf.org>
> Subject: Re: [core] content-formats for cbor YANG
> 
> 
>> On Apr 20, 2017, at 10:46, peter van der Stok <stokcons@xs4all.nl> 
>> wrote:
>> 
>> Hi Core,
>> 
>> Following the discussion on CoMI content-formats during ietf98, I want 
>> to propose the following;
>> 
>> Draft-ietf-core-yang-cbor deines the content-format 
>> application/yang+cbor which defines CBOR documents which contain the 
>> results of the mapping of a YANG document to CBOR as specified in the 
>> draft.
>> 
>> Draft-ietf-core-comi defines two additional content-formats:
>> 1) application/yang-fetch+cbor that specifies the contents and 
>> semantics of a FETCH CoMI request payload
>> 2) application/yang-patch+cbor that specifies the contents and 
>> semantics of a PATCH CoMI request payload
>> 
>> Looking forward to alternative proposals or noises of approval.
> 
> Sounds very good to me.
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core