Draft: draft-ietf-core-problem-details

Commentary: Add an example for an SPDe registration based on , also fulfilling the request in . 
 Just having run into a a Bad Option response that was hard to debug without attaching a literal debugger to the program under test ( because for some reason all the communication on the net is nowadays encrypted ) , I 'd like to suggest one option for inclusion in the original problem details set : Name : Unprocessed CoAP option CDDL type : uint | [ + uint ] Brief description : CoAP option number that was not understood Longer description : A CoAP option number present in the request that could not be processed by the server . It may be a critical option that the server is unaware of , or an option the server is aware of but could not process ( and chose not to , or was not allowed to , ignore it ) . Several options may be given in a list ( in no particular order ) , without any guarantee that the list is complete ( as the server might have stopped processing already at the first problematic option ) . If an option with the given number was repeated , there is no indication which of the values caused the fault . Clients need to expect seeing options in there they did not send in the request ; this can happen if the request traversed a proxy that the option but did not act on the problem details response . Note that for a few special values of unprocessed CoAP options ( such as Accept or Proxy - Uri ) , there are special response codes ( 4.06 Not Acceptable , 5.05 Proxying Not Supported , respectively ) to be sent instead . For future compatibility , receivers should ignore values not matching the current CDDL type , as these might be used to indicate an option more precisely if the demand arises . A typical error response with this can be rather short -- just 4.02 , 1 + 2 byte content format , and 3 bytes of CBOR data for option numbers up to 23 . 
 CDDL type probably more like , where Should we throw this in now or add this registration later ? 
 This case appears to be the only one where RFC 7252 explicitly recommends a diagnostic payload . The policy is specification required , so we could simply write this up as a document in this repo and register from there . Of course , including it in the RFC provides more visibility . 
 Comment by It would be nice with an example in as well . 
 I ’m not sure we actually need one ( there are 5 predefined now ) . Inventing one always has this problem that people start using it from the example , so there is a threshold of usefulness before one includes an example that is not actually registered . 
 Actually , is an attempt to provide an example that is actually useful to register .
basic provides a number of generally applicable Standard Problem
Detail Entries.  The present section both registers another useful
Standard Problem Detail entry and serves as an example of a Standard
Problem Detail Entry registration, in the registration template
format that would be ready for registration.
The Standard Problem Detail entry "unprocessed-coap-option" provides
the option number(s) of CoAP option(s) present in the request that
could not be processed by the server.
This may be a critical option that the server is unaware of, or an
option the server is aware of but could not process (and chose not
to, or was not allowed to, ignore it).
The Concise Problem Details data item including this Standard Problem
Detail Entry can be used in fulfillment of the "SHOULD" requirement
in RFC7252.
Several option numbers may be given in a list (in no particular
order), without any guarantee that the list is a complete
representation of all the problems in the request (as the server
might have stopped processing already at one of the problematic
options).  If an option with the given number was repeated, there is
no indication which of the values caused the error.
Clients need to expect seeing options in the list they did not send
in the request; this can happen if the request traversed a proxy that
added the option but did not act on the problem details response
being returned by the origin server.
Note that for a few special values of unprocessed CoAP options (such
as Accept or Proxy-Uri), there are special response codes (4.06 Not
Acceptable, 5.05 Proxying Not Supported, respectively) to be sent
instead of 4.02 Bad Option.