]> arm

thomas.fossati@arm.com

Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

ART CoRE Working Group CoAP, API, Problem Details This document defines a "problem detail" as a way to carry machine-readable details of errors in a REST response to avoid the need to define new error response formats for REST APIs. The format is inspired by, but intended to be more concise than, the Problem Details for HTTP APIs defined in RFC 7807. Discussion Venues Discussion of this document takes place on the CORE Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction REST response status information such as CoAP response codes () is sometimes not sufficient to convey enough information about an error to be helpful. This specification defines a simple and extensible framework to define CBOR data items to suit this purpose. It is designed to be reused by REST APIs, which can identify distinct "problem types" specific to their needs. Thus, API clients can be informed of both the high-level error class (using the response code) and the finer-grained details of the problem (using this vocabulary), as shown in .

Problem Details: Example with CoAP | | | (failure) |<-----------------o | Error Response | | with a CBOR | | data item giving | | Problem Details | | | ]]>

The framework presented is largely inspired by the Problem Details for HTTP APIs defined in . discusses applications where interworking with is required.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Basic Problem Details A Concise Problem Details data item is a CBOR data item with the following structure (notated in CDDL ):

Problem Detail Data Item oltext ? &(detail: -2) => oltext ? &(instance: -3) => ~uri ? &(response-code: -4) => uint .size 1 standard-problem-detail-entries custom-problem-detail-entries }> standard-problem-detail-entries = ( * nint => any ) custom-problem-detail-entries = ( * (uint/~uri) => { + any => any } ) non-empty = (M) .and ({ + any => any }) oltext = text / tag38 ; see Appendix A for tag38 ]]>

A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, see ):

The title (key -1):

A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem.

The detail (key -2):

A human-readable explanation specific to this occurrence of the problem.

The instance (key -3):

A URI reference that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced.

The response-code (key -4)

The CoAP response code () generated by the origin server for this occurrence of the problem.

Note that, unlike , Concise Problem Details data items have no explicit type. Both "title" and "detail" can use either an unadorned CBOR text string (text) or a language-tagged text string (tag38); see for the definition of the latter. The "title" string is advisory and included to give consumers a shorthand for the category of the error encountered. The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information. Consumers SHOULD NOT parse the "detail" member for information; extensions (see ) are more suitable and less error-prone ways to obtain such information. Note that the "instance" URI reference may be relative; this means that it must be resolved relative to the representation's base URI, as per . Note that the "response code" value is a numeric representation of the actual code, so it does not take the usual form that resembles an HTTP status code -- 4.04 Not found is represented by the number 132.

Extending Concise Problem Details This specification defines a generic problem type container with only a minimal set of attributes to make it usable. It is expected that applications will extend the base format by defining new attributes. These new attributes fall into two categories: generic and application specific. Generic attributes will be allocated in the standard-problem-detail-entries slot according to the registration procedure defined in . Application-specific attributes will be allocated in the custom-problem-detail-entries slot according to the procedure described in .

Standard Problem Detail Entries Beyond the Standard Problem Detail keys defined in , additional Standard Problem Detail keys can be registered for use in the standard-problem-detail-entries slot (see ). Standard Problem Detail keys are negative integers, so they never can conflict with Custom Problem Detail keys defined for a specific application domain (which are unsigned integers or URIs.) In summary, the keys for Standard Problem Detail entries are in a global namespace that is not specific to a particular application domain. Consumers of a Concise Problem Details instance MUST ignore any Standard Problem Detail entries that they do not recognize; this allows problem details to evolve.

Custom Problem Detail Entries Applications may extend the Problem Details data item with additional entries to convey additional, application-specific information. Such new entries are allocated in the custom-problem-detail-entries slot, and carry a nested map specific to that application. The map key can either be an (absolute!) URI (controlled by the entity defining this extension), or an unsigned integer. Only the latter needs to be registered (). Within the nested map any number of attributes can be given for a single extension. The semantics of each custom attribute MUST be described in the documentation for the extension; for extension that are registered (i.e., are identified by an unsigned int) that documentation goes along with the registration. The unsigned integer form allows a more compact representation, in exchange, authors are expected to comply with the required registration and documentation process. In comparison, the URI form is less space-efficient but requires no registration. It is therefore useful for experimenting during the development cycle and for applications deployed in environments where producers and consumers of Concise Problem Details are more tightly integrated. (The URI form thus covers the potential need we might otherwise have for a "private use" range for the unsigned integers.) Note that the URI given for the extension is for identification purposes only and, even if dereferenceable in principle, MUST NOT be dereferenced in the normal course of handling problem details (i.e., outside diagnostic/debugging procedures involving humans). An example of a custom extension using a URI as custom-problem-detail-entries key is shown in .

Example Extension with URI key

Obviously, an SDO like 3GPP can also easily register such a custom problem detail entry to receive a more efficient unsigned integer key; the same example but using a registered unsigned int as custom-problem-detail-entries key is shown in .

Example Extension with unsigned int (registered) key

In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically to the identifier of that Custom Problem Detail entry, the documentation of which defines these internal entries, typically chosen to address a given application domain. Consumers of a Concise Problem Details instance MUST ignore any Custom Problem Detail entries, or keys inside the Custom Problem Detail entries, that they do not recognize; this allows Custom Problem Detail entries to evolve and include additional information in the future.

Security Considerations The security and privacy considerations outlined in Section 5 of apply in full.

IANA Considerations RFC Editor: please replace RFC XXXX with this RFC number and remove this note.

Standard Problem Detail Key registry This specification defines a new sub-registry for Standard Problem Detail Keys in the CoRE Parameters registry , with the policy "specification required" . Each entry in the registry must include:

Key value:

a negative integer to be used as the value of the key

Name:

a name that could be used in implementations for the key

CDDL type:

type of the data associated with the key in CDDL notation

Brief description:

a brief description

reference:

a reference document

Initial entries in this sub-registry are as follows: Initial Entries in Standard Problem Detail Key registry

Key value	Name	CDDL Type	Brief description	Reference
-1	title	text	short, human-readable summary of the problem type	RFCXXXX
-2	detail	text	human-readable explanation specific to this occurrence of the problem	RFCXXXX
-3	instance	~uri	URI reference identifying specific occurrence of the problem	RFCXXXX
-4	response-code	uint .size 1	CoAP response code	RFCXXXX

Custom Problem Detail Key registry This specification defines a new sub-registry for Custom Problem Detail Keys in the CoRE Parameters registry , with the policy "first come first served" . Each entry in the registry must include:

Key value:

an unsigned integer to be used as the value of the key

Name:

a name that could be used in implementations for the key

Brief description:

a brief description

Reference:

a reference document that provides a description of the map, including a CDDL description, that describes all inside keys and values

Initial entries in this sub-registry are as follows: Initial Entries in Custom Problem Detail Key registry

Key value	Name	Brief description	Reference
7807	tunnel-7807	Carry RFC 7807 problem details in a Concise Problem Details data item	RFCXXXX

Media Type IANA is requested to add the following Media-Type to the "Media Types" registry . New Media Type application/concise-problem-details+cbor

Name	Template	Reference
concise-problem-details+cbor	application/concise-problem-details+cbor	RFCXXXX,

Type name:

application

Subtype name:

concise-problem-details+cbor

Required parameters:

none

Optional parameters:

none

Encoding considerations:

binary (CBOR data item)

Security considerations:

of RFC XXXX

Interoperability considerations:

none

Published specification:

of RFC XXXX

Applications that use this media type:

Clients and servers in the Internet of Things

Fragment identifier considerations:

The syntax and semantics of fragment identifiers is as specified for "application/cbor". (At publication of RFC XXXX, there is no fragment identification syntax defined for "application/cbor".)

Person & email address to contact for further information:

CoRE WG mailing list (core@ietf.org), or IETF Applications and Real-Time Area (art@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

Content-Format IANA is requested to register a Content-Format number in the sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry , as follows: New Content-Format

Content-Type	Content Coding	ID	Reference
application/concise-problem-details+cbor	-	TBD1	RFC XXXX

TBD1 is to be assigned from the space 256..999. In the registry as defined by at the time of writing, the column "Content-Type" is called "Media type" and the column "Content Coding" is called "Encoding". This paragraph to be removed by RFC editor.

CBOR Tag 38 In the registry "" , IANA has registered CBOR Tag 38. IANA is requested to replace the reference for this registration with , RFC XXXX.

References Normative References The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. IANA This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. IANA Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. IANA Informative References This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines a "problem detail" to carry machine-readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-httpapi/rfc7807bis. W3C Recommendation The Unicode Consortium Note that while this document references a version that was recent at the time of writing, the statements made based on this version are expected to remain valid for future versions. Mountain View: The Unicode Consortium

Language-Tagged Strings This appendix serves as the archival documentation for CBOR Tag 38, a tag for serializing language-tagged text strings in CBOR. The text of this appendix is adapted from the specification text supplied for its initial registration. It has been extended to allow supplementing the language tag by a direction indication.

Introduction In some cases it is useful to specify the natural language of a text string. This specification defines a tag that does just that. One technology that supports language-tagged strings is the Resource Description Framework (RDF) .

Detailed Semantics A language-tagged string in CBOR has the tag 38 and consists of an array with a length of 2 or 3. The first element is a well-formed language tag under Best Current Practice 47 ( and ), represented as a UTF-8 text string (major type 3). The second element is an arbitrary UTF-8 text string (major type 3). Both the language tag and the arbitrary string can optionally be annotated with CBOR tags; this is not shown in the CDDL below. The optional third element, if present, is a Boolean value that indicates a direction: false for "ltr" direction, true for "rtl" direction. If the third element is absent, no indication is made about the direction. In CDDL: NOTE: Language tags of any combination of case are allowed. But section 2.1.1 of , part of Best Current Practice 47, recommends a case combination for language tags, that encoders that support tag 38 may wish to follow when generating language tags. Data items with tag 38 that do not meet the criteria above are invalid (see ). NOTE: The Unicode Standard includes a set of characters designed for tagging text (including language tagging), in the range U+E0000 to U+E007F. Although many applications, including RDF, do not disallow these characters in text strings, the Unicode Consortium has deprecated these characters and recommends annotating language via a higher-level protocol instead. See the section "Deprecated Tag Characters" in Section 23.9 of .

Examples Examples in this section are given in CBOR diagnostic mode, and then as a pretty-printed hexadecimal representation of the encoded item. The following example shows how the English-language string "Hello" is represented. The following example shows how the French-language string "Bonjour" is represented. The following example shows how the Hebrew-language string שלום is represented. Note the rtl direction expressed by setting the third element in the array to "true".

Interworking with RFC 7807 On certain occasions, it will be necessary to carry ("tunnel") problem details in a Concise Problem Details item. This appendix defines a Custom Problem Details entry for that purpose. This is assigned Custom Problem Detail key 7807 in . Its structure is: ~uri ? &(status: 1) => 0..999 * text => any } ]]> To carry an problem details JSON object in a Concise Problem Details item, first convert the JSON object to CBOR as per . Create an empty Concise Problem Details data item. Move the values for "title", "detail", and "instance", if present, from the problem details to the equivalent Standard Problem Detail entries. Create a Custom Problem Detail entry with key 7807. Move the values for "type" and "status", if present, to the equivalent keys 0 and 1 of the Custom Problem Detail entry. Move all remaining key/value pairs (additional members as per ) in the converted problem details object to the Custom Problem Details map unchanged. The inverse direction, carrying Concise Problem Details in a Problem Details JSON object requires the additional support provided by , which is planned to create the HTTP Problem Types Registry. A Problem Type can then be registered that extracts top-level items from the Concise Problem Details item in a similar way to the conversion described above, and which carries the rest of the Concise Problem Details item in an additional member via base64url encoding without padding (). Details can be defined in a separate document when the work on is completed.

Acknowledgments and , authors of RFC 7807. and , co-authors of an earlier generation of this specification. and for review and comments on this document. For , John Cowan and Doug Ewell are also to be acknowledged. The content of an earlier version of this appendix was also discussed in the "apps-discuss at ietf.org" and "ltru at ietf.org" mailing lists.

Contributors

poccil14 at gmail dot com http://peteroupc.github.io/CBOR/

Peter defined CBOR tag 38, basis of .