Arm Limited

thomas.fossati@arm.com

Universität Bremen TZI

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

art core CoAP API Problem Details CBOR Tag Language Tag Bidi This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Terminology and Requirements Language
• .  Basic Problem Details
• .  Extending Concise Problem Details
  • .  Standard Problem Detail Entries
    • .  Standard Problem Detail Entry: Unprocessed CoAP Option
  • .  Custom Problem Detail Entries
• .  Privacy Considerations
• .  Security Considerations
• .  IANA Considerations
  • .  Standard Problem Detail Keys Registry
  • .  Custom Problem Detail Keys Registry
  • .  Media Type
  • .  Content-Format
  • .  CBOR Tag 38
• .  References
  • .  Normative References
  • .  Informative References
• .  Language-Tagged Strings
  • .  Introduction
  • .  Detailed Semantics
  • .  Examples
• .  Interworking with RFC 7807
• Acknowledgments
• Contributors
• Authors' Addresses

Introduction REST response status information such as Constrained Application Protocol (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 Concise Binary Object Representation (CBOR) data items to suit this purpose. This framework is designed to be reused by REST APIs, which can identify distinct "shapes" of these data items 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 the vocabulary defined here). This pattern of communication is illustrated in .

Problem Details: Example with CoAP .--------. .--------. | CoAP | | CoAP | | Client | | Server | '----+---' '---+----' | | | Request | o----------------->| | | (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.

Terminology and Requirements Language The terminology from , , and applies; in particular, CBOR diagnostic notation is defined in Section of RFC 8949 and . Readers are also expected to be familiar with the terminology from . In this document, the structure of data is specified in Concise Data Definition Language (CDDL) . 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 (rules named starting with tag38 are defined in ):

Structure of Concise Problem Details Data Item problem-details = non-empty<{ ? &(title: -1) => oltext ? &(detail: -2) => oltext ? &(instance: -3) => ~uri ? &(response-code: -4) => uint .size 1 ? &(base-uri: -5) => ~uri ? &(base-lang: -6) => tag38-ltag ? &(base-rtl: -7) => tag38-direction 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> = (M) .and ({ + any => any }) oltext = text / tag38

(Examples of elaborated Concise Problem Details data items can be found later in the document, e.g., .) A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, see ). Note that, unlike , Concise Problem Details data items have no explicit "problem type". Instead, the category (or, one could say, Gestalt) of the problem can be understood from the shape of the problem details offered. We talk of a "problem shape" for short.

The title (key -1):

A short, human-readable summary of the problem shape. Beyond the shape of the problem, it is not intended to summarize all the specific information given with the problem details. For instance, the summary might include that an account does not have enough money for a transaction to succeed but not the detailed information such as the account number, how much money that account has, and how much would be needed.

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 (Sections and of ) generated by the origin server for this occurrence of the problem.

The base-uri (key -5):

The base URI (see Section of RFC 3986 ) that should be used to resolve relative URI references embedded in this Concise Problem Details data item.

The base-lang (key -6):

The language-tag (tag38-ltag) that applies to the presentation of unadorned text strings (not using tag 38) in this Concise Problem Details data item; see .

The base-rtl (key -7):

The writing-direction (tag38-direction) that applies to the presentation of unadorned text strings (not using tag 38) in this Concise Problem Details data item; see .

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. Language tag and writing direction information for unadorned text strings is intended to be obtained from context; if that context needs to be saved or forwarded with a Concise Problem Details data item, "base-lang" and "base-rtl" can be used. If no such (explicitly saved or implicit) context information is available, unadorned text is interpreted with language-tag "en" and writing-direction "false" (ltr). The "title" string is advisory and included to give consumers a shorthand for the category (problem shape) of the error encountered. The "detail" member, if present, ought to focus on helping the client correct the problem rather than giving extensive server-side 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 Section of RFC 3986 . The "response-code" member, if present, is only advisory; it conveys the CoAP response code used for the convenience of the consumer. Generators MUST use the same response code here as in the actual CoAP response; the latter is needed to assure that generic CoAP software that does not understand the problem-details format still behaves correctly. Consumers can use the "response-code" member to determine what the original response code used by the generator was, in cases where it has been changed (e.g., by an intermediary or cache), and when message bodies persist without CoAP information (e.g., in an events log or analytics database). Generic CoAP software will still use the CoAP response code. To support the use case of message-body persistence without support by the problem-details generator, the entity that persists the Concise Problem Details data item can copy over the CoAP response code that it received on the CoAP level. Note that the "response-code" value is a numeric representation of the actual code (see ), so it does not take the usual presentation form that resembles an HTTP status code: 4.04 Not Found is represented by the number 132. The "base-uri" member is usually not present in the initial request-response communication as it can be inferred as per Section of RFC 3986 . An entity that stores a Concise Problem Details data item or otherwise makes it available for consumers without this context might add in a "base-uri" member to allow those consumers to perform resolution of any relative URI references embedded in the data item.

Extending Concise Problem Details This specification defines a generic problem-details 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 . Consumers of a Concise Problem Details data item MUST ignore any Standard Problem Detail entries or Custom Problem Detail entries, or keys inside the Custom Problem Detail entries, that they do not recognize ("ignore-unknown rule"); this allows problem details to evolve. When storing the data item for future use or forwarding it to other consumers, it is strongly RECOMMENDED to retain the unrecognized entries; exceptions might be when storage or forwarding occurs in a different format/protocol that cannot accommodate them or when the storage or forwarding function needs to filter out privacy-sensitive information and for that needs to assume unrecognized entries might be privacy-sensitive.

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 can never 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.

Standard Problem Detail Entry: Unprocessed CoAP Option 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.

Key value:

-8

Name:

unprocessed-coap-option

CDDL type:

one-or-more<uint>, where one-or-more<T> = T / [ 2* T ]

Brief description:

Option number(s) of CoAP option(s) that were not understood

Specification reference:

of RFC 9290

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 or numbers of any CoAP options 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 . 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 to see options in the list that 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. For a few special values of unprocessed CoAP options (such as Accept or Proxy-Uri), note that there are special response codes (4.06 Not Acceptable, 5.05 Proxying Not Supported, respectively) to be sent instead of 4.02 Bad Option.

Custom Problem Detail Entries Applications may extend the Concise 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 be either an (absolute!) URI (under control of 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 extensions 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. Therefore, it is 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. (Thus, the URI form 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, it MUST NOT be dereferenced in the normal course of handling problem details (i.e., outside diagnostic or debugging procedures involving humans). shows an example (in CBOR diagnostic notation) of a custom extension using a (made-up) URI as the custom-problem-detail-entries key.

Example Extension with URI Key { / title / -1: "title of the error", / detail / -2: "detailed information about the error", / instance / -3: "coaps://pd.example/FA317434", / response-code / -4: 128, / 4.00 / "tag:3gpp.org,2022-03:TS29112": { / cause / 0: "machine-readable error cause", / invalidParams / 1: [ [ / param / "first parameter name", / reason / "must be a positive integer" ], [ / param / "second parameter name" ] ], / supportedFeatures / 2: "d34db33f" } }

Obviously, a Standards Development Organization (SDO) like 3GPP can also easily register such a Custom Problem Detail entry to receive a more efficient unsigned integer key; shows how the same example would look using a (made-up) registered unsigned int as the custom-problem-detail-entries key:

Example Extension with Unsigned Int (Registered) Key { / title / -1: "title of the error", / detail / -2: "detailed information about the error", / instance / -3: "coaps://pd.example/FA317434", / response-code / -4: 128, / 4.00 / /4711 is made-up example key that is not actually registered:/ 4711: { / cause / 0: "machine-readable error cause", / invalidParams / 1: [ [ / param / "first parameter name", / reason / "must be a positive integer" ], [ / param / "second parameter name" ] ], / supportedFeatures / 2: "d34db33f" } }

In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically for use with the identifier of that Custom Problem Detail entry, the documentation of which defines these internal entries, typically chosen to address a given application domain. When there is a need to evolve a Custom Problem Detail entry definition, the "ignore-unknown rule" discussed in provides an easy way to include additional information. The assumption is that this is done in a backward- and forward-compatible way. Sometimes, Custom Problem Detail entries may need to evolve in a way where forward compatibility by applying the "ignore-unknown rule" would not be appropriate: for example, when adding a "must-understand" member, which can only be ignored at the peril of misunderstanding the Concise Problem Details data item ("false interoperability"). In this case, a new Custom Problem Detail key can simply be registered for this case, keeping the old key backward and forward compatible.

Privacy Considerations Problem details may unintentionally disclose information. This can lead to both privacy and security problems. See for more details that apply to both domains; particular attention needs to be given to unintentionally disclosing Personally Identifiable Information (PII).

Security Considerations Concise Problem Details can contain URIs that are not intended to be dereferenced (). One reason is that dereferencing these can lead to information disclosure (tracking). Information disclosure can also be caused by URIs in problem details that are intended for dereferencing, e.g., the "instance" URI. Implementations need to consider which component of a client should perform the dereferencing and which servers are trusted with serving them. In any case, the security considerations of Section of RFC 3986 apply. The security and privacy considerations outlined in apply in full. While these are phrased in terms of security considerations for new RFC 7807 problem types, they equally apply to the problem detail entry definitions used here (). In summary, both when defining new detail entries and when actually using them to generate a Concise Problem Details data item, care needs to be taken that they do not leak sensitive information. Entities storing or forwarding Concise Problem Details data items need to consider whether this leads to information being transferred out of the context within which access to sensitive information was acceptable. See also (the last paragraph of the introduction to that section). Privacy-sensitive information in the problem details SHOULD NOT be obscured in ways that might lead to misclassification as non-sensitive (e.g., by base64-encoding).

IANA Considerations

Standard Problem Detail Keys Registry This specification defines a new subregistry titled "Standard Problem Detail Keys" in the "Constrained RESTful Environments (CoRE) Parameters" registry , with "Specification Required" as the Registration Procedure (). 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

Change Controller:

(see )

The designated expert is requested to assign the shortest key values (1+0 and 1+1 encoding) to registrations that are likely to enjoy wide use and can benefit from short encodings. To be immediately useful in CDDL and programming-language contexts, a name consists of a lowercase ASCII letter (a-z) and zero or more additional ASCII characters that are either lowercase letters, digits, or a hyphen-minus, i.e., it matches [a-z][-a-z0-9]*. As with the key values, names need to be unique. The specification in the reference document needs to provide a description of the Standard Problem Detail entry, replicating the CDDL description in "CDDL Type", and describing the semantics of the presence of this entry and the semantics of the value given with it. Initial entries in this subregistry are as follows: Initial Entries in the Standard Problem Detail Keys Registry

Key Value	Name	CDDL Type	Brief Description	Reference	Change Controller
-1	title	text / tag38	Short, human-readable summary of the problem shape	RFC 9290	IETF
-2	detail	text / tag38	Human-readable explanation specific to this occurrence of the problem	RFC 9290	IETF
-3	instance	~uri	URI reference identifying specific occurrence of the problem	RFC 9290	IETF
-4	response-code	uint .size 1	CoAP response code	RFC 9290	IETF
-5	base-uri	~uri	Base URI	RFC 9290	IETF
-6	base-lang	tag38-ltag	Base language tag (see )	RFC 9290	IETF
-7	base-rtl	tag38-direction	Base writing direction (see )	RFC 9290	IETF
-8	unprocessed-coap-option	one-or-more<uint>	Option number(s) of CoAP option(s) that were not understood	RFC 9290,	IETF

Custom Problem Detail Keys Registry This specification defines a new subregistry titled "Custom Problem Detail Keys" in the "Constrained RESTful Environments (CoRE) Parameters" registry , with as "Expert Review" as the Registration Procedure (). The designated expert is instructed to attempt making the registration experience as close to First Come First Served as reasonably achievable, but checking that the reference document does provide a description as set out below. (This requirement is a relaxed version of "Specification Required" as defined in .) 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

Change Controller

(see )

The designated expert is requested to assign the shortest key values (1+0 and 1+1 encoding) to registrations that are likely to enjoy wide use and can benefit from short encodings. To be immediately useful in CDDL and programming-language contexts, a name consists of a lowercase ASCII letter (a-z) and zero or more additional ASCII characters that are either lowercase letters, digits, or a hyphen-minus, i.e., it matches [a-z][-a-z0-9]*. As with the key values, names need to be unique. Initial entries in this subregistry are as follows: Initial Entries in the Custom Problem Detail Key Registry

Key Value	Name	Brief Description	Reference	Change Controller
7807	tunnel-7807	Carry RFC 7807 problem details in a Concise Problem Details data item	RFC 9290,	IETF

Media Type IANA has added 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	RFC 9290,

Type name:

application

Subtype name:

concise-problem-details+cbor

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary (CBOR data item)

Security considerations:

of RFC 9290

Interoperability considerations:

none

Published specification:

of RFC 9290

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 9290, there is no fragment identification syntax defined for "application/cbor".)

Additional information:

Deprecated alias names for this type:

N/A

Magic number(s):

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

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 has registered a Content-Format number in the subregistry, within the "Constrained RESTful Environments (CoRE) Parameters" registry , as follows: Content-Format Registration

Media Type	Encoding	ID	Reference
application/concise-problem-details+cbor	-	257	RFC 9290

CBOR Tag 38 In the registry "" , IANA has registered CBOR tag 38. IANA has updated the reference for CBOR tag 38 to point to RFC 9290, .

References Normative References Internet Assigned Numbers Authority Internet Assigned Numbers Authority Internet Assigned Numbers Authority 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. 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. 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. 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. 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. 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. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: , , and for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance. 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 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. Informative References This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content and/or fields to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RF7807. 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. Work in Progress W3C Recommendation 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] RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages. This document is not an Internet Standards Track specification; it is published for informational purposes. The Unicode Consortium Mountain View: The Unicode Consortium 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. As with any IANA-registered item, a specification that further updates this registration needs to update the reference column of the IANA registry (see ). Future specifications may update this appendix, other parts of this document, or both. (When updating this appendix, keep in mind that applications beyond Concise Problem Details data items may adopt the tag defined here.) Users of this tag are advised to consult the registry to obtain the most recent update for this appendix.

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 text 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 described in BCP 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, represents a ternary value that indicates a direction, as follows:

• false: left-to-right direction ("ltr"). The text is expected to be displayed with left-to-right base direction if standalone and isolated with left-to-right direction (as if enclosed in LRI ... PDI or equivalent, see ) in the context of a longer string or text.
• true: right-to-left direction ("rtl"). The text is expected to be displayed with right-to-left base direction if standalone and isolated with right-to-left direction (as if enclosed in RLI ... PDI or equivalent, see ) in the context of a longer string or text.
• null: indicates that no indication is made about the direction ("auto"), enabling an internationalization library to make an auto-detection decision such as treating the string as if enclosed in FSI ... PDI or equivalent, see .

If the third element is absent, directionality context may be applied (e.g., base-directionality information for an entire CBOR message or part thereof). If there is no directionality context applied, the default interpretation is the same as for null ("auto"). In CDDL: tag38 = #6.38([tag38-ltag, text, ?tag38-direction]) tag38-ltag = text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*" tag38-direction = &(ltr: false, rtl: true, auto: null) NOTE: Language tags of any combination of case are allowed. But , part of BCP 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 not valid (see Section of RFC 8949 ). 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 as well as . NOTE: while this document references a version of Unicode that was recent at the time of writing, the statements made based on this version are expected to remain valid for future versions.

Examples Examples in this section are given in CBOR diagnostic notation first and then as a pretty-printed hexadecimal representation of the encoded item. The following example shows how the English-language string "Hello" is represented. 38(["en", "Hello"]) D8 26 # tag(38) 82 # array(2) 62 # text(2) 656E # "en" 65 # text(5) 48656C6C6F # "Hello" The following example shows how the French-language string "Bonjour" is represented. 38(["fr", "Bonjour"]) D8 26 # tag(38) 82 # array(2) 62 # text(2) 6672 # "fr" 67 # text(7) 426F6E6A6F7572 # "Bonjour" The following example uses right-to-left (RTL) script, which in the context of this specification may be rendered differently by different document presentation environments. The descriptive text may be more reliable to follow than the necessarily device- and application-specific rendering. The example shows how the Hebrew-language string שלום is represented, where in direction of reading, the sequence of characters is: ש, ל, ו, ם. Note the rtl direction expressed by setting the third element in the array to "true". 38(["he", "שלום", true]) D8 26 # tag(38) 83 # array(3) 62 # text(2) 6865 # "he" 68 # text(8) D7A9D79CD795D79D # "שלום" F5 # primitive(21)

Interworking with RFC 7807 On certain occasions, it will be necessary to carry ("tunnel") problem details in a Concise Problem Details data item. This appendix defines a Custom Problem Detail entry for that purpose. This is assigned Custom Problem Detail key 7807 in . Its structure is: tunnel-7807 = { ? &(type: 0) => ~uri ? &(status: 1) => 0..999 * text => any } To carry an problem details JSON object in a Concise Problem Details data item, first convert the JSON object to CBOR as per Section of RFC 8949 . 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 Detail map unchanged. The inverse direction, carrying Concise Problem Details in an RFC 7807 problem details JSON object requires the additional support provided by , which is planned to create the HTTP Problem Types Registry. An HTTP Problem Type can then be registered that extracts top-level items from the Concise Problem Details data item in a similar way to the conversion described above and that carries the rest of the Concise Problem Details data 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 The authors would like to thank and , the authors of RFC 7807; and , the coauthors of an earlier draft version of this specification; , , , and for review and comments on this document. for her review (and support) as responsible AD, and for his OPSDIR review, both of which brought significant additional considerations to this document. For , and are also to be acknowledged. The content of an earlier draft version of this appendix was also discussed in the "apps-discuss@ietf.org" and "ltru@ietf.org" mailing lists. More recently, the authors initiated a discussion about the handling of writing direction information in conjunction with language tags. That led to discussions within the W3C Internationalization Core Working Group. The authors would like to acknowledge that cross-organization cooperation and particular contributions from and and specific text proposals by .

Contributors

poccil14@gmail.com http://peteroupc.github.io/CBOR/

Peter defined CBOR tag 38, basis of .

christian@amsuess.com

Christian contributed what became .

Authors' Addresses Arm Limited

thomas.fossati@arm.com

Universität Bremen TZI

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