[core] CoMI error codes

[peter van der Stok <[e-mail]>]

Hi Core,

Michel makes the remark that the production of comi specific error 
messages needs a better specification.
I thought that this warranted a discussion on the ML.

Michel's proposal is:
to create a typical CoMI method parsing pseudo code. This pseudo code is 
useful to identify which CoAP error codes are generated by the underline 
CoAP library and which are generated by the CoMI specific application 
logic.

For those errors generated by the CoAP library, we should not require 
any payload since such requirement will force implementers to make 
changes to the underline CoAP library. In some cases, such changes are 
not even possible, no access to source code or not allowed by the 
software license.

For CoAP errors generated at the CoMI application logic level, my 
recommendation is still to avoid the definition of specific error codes. 
Such error code are really useful only if a client can automatically fix 
the situation by re-issuing an updated request taking into account the 
initial error. However, I don't see such use cases for these errors. One 
example of such approach is error code 4.13 (Request Entity Too Large) 
which allow a client to switch to block transfer.

If the target for this extra information is debugging, a simple text 
message will do the job. This text message can identify for example the 
exact leaf and specific error condition (e.g. "ip-address, pattern 
mismatch").
______________________________________________

My alternative proposal is:
using the RESTCONF approach, where errors are returned within a YANG 
module instance as specified in section 8 of RFC8040 (RESTCONF). The 
returned content format would then be /application/yang+cbor as proposed 
in an earlier message to this list.


Looking forward to some discussion,

Peter