Re: [core] content-formats for cbor YANG

[Carsten Bormann <[e-mail]>]

> On Apr 20, 2017, at 18:21, Michel Veillette <[e-mail]> wrote:
> 
> 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?

That is a good question.

We definitely need a different format for the FETCH request body, which is a list of IDs, not a set of ID-value pairs.  (We used to have this argument whether the response should be just a list of values or that set; I think we are now at the set selected, which is strictly speaking a bit different from the representation of the whole resource.)

The body of an (i)PATCH is different in meaning, not in structure, from the representation bearing formats.  It is a bit of a taste thing whether we attach media types to semantics or to structural interoperability.

I didn’t have a problem with Peter’s original proposal:

> 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

Just calling the thing application/cbor just tells us the serialization format, by the way; this is a bit like sending text/html as text/plain because any text also is structurally compatible with the latter.

Andy’s argument that yang-patch is taken for the different yang-patch format used with XML/JSON is a good one.  Note that there is no coap in the comi patch format either, so I don’t like application/coap-patch+cbor.  Right now I’m favoring application/yang-set+cbor.

Grüße, Carsten