Re: [core] content-formats for cbor YANG


peter van der Stok schreef op 2017-04-20 16:36:
> Hi Michel,
> 
> The semantics of the PUT and GET specify that the payload replaces
> (represents) the whole payload.
resource (oversight, apologies)
> 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