Change:
global namespace that is not specific to a particular application domain. <ins> 3.1.1. 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 specification of the Standard Problem Detail entry referenced by the above registration template follows: 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. </ins> 3.2. Applications may extend the Problem Details data item with additional

Discussion:
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 added 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 NAME 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.