Hi Peter
It still unclear to me what is the role of the CoAP method vs. the role of the Content-Format.
The PUT, POST and iPATCH methods all share the same payload (i.e. CBOR array (instance-identifier, value)).
- In the case of the PUT, the existing datastore is deleted and replaced by the provided payload.
- In the case of the POST, a new datastore is created with the provided payload.
- In the case of the iPATCH, the existing datastore is updated based on the provided payload.
For these three use cases, the method defines what to do with the payload, not the Content-Format.
My question is why iPATCH required a different Content-Format when PUT and POST use the same?
Regards,
Michel
-----Original Message-----
From: peter van der Stok [mailto:***@xs4all.nl]
Sent: Thursday, April 20, 2017 10:37 AM
To: Michel Veillette <***@trilliantinc.com>
Cc: Carsten Bormann <***@tzi.org>; peter van der Stok <***@vanderstok.org>; Core <***@ietf.org>
Subject: 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
Post by Michel VeilletteHi 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-----
Sent: Thursday, April 20, 2017 4:55 AM
Subject: Re: [core] content-formats for cbor YANG
Post by peter van der StokHi 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.
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
https://www.ietf.org/mailman/listinfo/core