rfc9290.original		rfc9290.txt
	CoRE Working Group T. Fossati		Internet Engineering Task Force (IETF) T. Fossati
	Internet-Draft arm		Request for Comments: 9290 Arm Limited
	Intended status: Standards Track C. Bormann		Category: Standards Track C. Bormann
	Expires: 7 January 2023 Universität Bremen TZI		ISSN: 2070-1721 Universität Bremen TZI
	6 July 2022		October 2022
	Concise Problem Details For CoAP APIs		Concise Problem Details for Constrained Application Protocol (CoAP) APIs
	draft-ietf-core-problem-details-08
	Abstract		Abstract
	This document defines a concise "problem detail" as a way to carry		This document defines a concise "problem detail" as a way to carry
	machine-readable details of errors in a REST response to avoid the		machine-readable details of errors in a Representational State
	need to define new error response formats for REST APIs for		Transfer (REST) response to avoid the need to define new error
	constrained environments. The format is inspired by, but intended to		response formats for REST APIs for constrained environments. The
	be more concise than, the Problem Details for HTTP APIs defined in		format is inspired by, but intended to be more concise than, the
	RFC 7807.		problem details for HTTP APIs defined in RFC 7807.
	About This Document
	This note is to be removed before publishing as an RFC.
	Status information for this document may be found at
	https://datatracker.ietf.org/doc/draft-ietf-core-problem-details/.
	Discussion of this document takes place on the Constrained RESTful
	Environments Working Group mailing list (mailto:core@ietf.org), which
	is archived at https://mailarchive.ietf.org/arch/browse/core/.
	Source for this draft and an issue tracker can be found at
	https://github.com/core-wg/core-problem-details.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is a product of the Internet Engineering Task Force
	Task Force (IETF). Note that other groups may also distribute		(IETF). It represents the consensus of the IETF community. It has
	working documents as Internet-Drafts. The list of current Internet-		received public review and has been approved for publication by the
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	Internet-Drafts are draft documents valid for a maximum of six months		Information about the current status of this document, any errata,
	and may be updated, replaced, or obsoleted by other documents at any		and how to provide feedback on it may be obtained at
	time. It is inappropriate to use Internet-Drafts as reference		https://www.rfc-editor.org/info/rfc9290.
	material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 7 January 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	1.1. Terminology and Requirements Language . . . . . . . . . . 3		1.1. Terminology and Requirements Language
	2. Basic Problem Details . . . . . . . . . . . . . . . . . . . . 4		2. Basic Problem Details
	3. Extending Concise Problem Details . . . . . . . . . . . . . . 6		3. Extending Concise Problem Details
	3.1. Standard Problem Detail Entries . . . . . . . . . . . . . 7		3.1. Standard Problem Detail Entries
	3.1.1. Standard Problem Detail Entry: Unprocessed CoAP		3.1.1. Standard Problem Detail Entry: Unprocessed CoAP Option
	Option . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Custom Problem Detail Entries
	3.2. Custom Problem Detail Entries . . . . . . . . . . . . . . 9		4. Privacy Considerations
	4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6.1. Standard Problem Detail Keys Registry
	6.1. Standard Problem Detail Key registry . . . . . . . . . . 12		6.2. Custom Problem Detail Keys Registry
	6.2. Custom Problem Detail Key registry . . . . . . . . . . . 14		6.3. Media Type
	6.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 16		6.4. Content-Format
	6.4. Content-Format . . . . . . . . . . . . . . . . . . . . . 16		6.5. CBOR Tag 38
	6.5. CBOR Tag 38 . . . . . . . . . . . . . . . . . . . . . . . 17		7. References
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		7.1. Normative References
	7.1. Normative References . . . . . . . . . . . . . . . . . . 17		7.2. Informative References
	7.2. Informative References . . . . . . . . . . . . . . . . . 18		Appendix A. Language-Tagged Strings
	Appendix A. Language-Tagged Strings . . . . . . . . . . . . . . 19		A.1. Introduction
	A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20		A.2. Detailed Semantics
	A.2. Detailed Semantics . . . . . . . . . . . . . . . . . . . 20		A.3. Examples
	A.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 21		Appendix B. Interworking with RFC 7807
	Appendix B. Interworking with RFC 7807 . . . . . . . . . . . . . 22		Acknowledgments
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23		Contributors
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	REST response status information such as CoAP response codes		REST response status information such as Constrained Application
	(Section 5.9 of [RFC7252]) is sometimes not sufficient to convey		Protocol (CoAP) response codes (Section 5.9 of [RFC7252]) is
	enough information about an error to be helpful. This specification		sometimes not sufficient to convey enough information about an error
	defines a simple and extensible framework to define CBOR [STD94] data		to be helpful. This specification defines a simple and extensible
	items to suit this purpose. It is designed to be reused by REST		framework to define Concise Binary Object Representation (CBOR)
	APIs, which can identify distinct "shapes" of these data items		[STD94] data items to suit this purpose. This framework is designed
	specific to their needs. Thus, API clients can be informed of both		to be reused by REST APIs, which can identify distinct "shapes" of
	the high-level error class (using the response code) and the finer-		these data items specific to their needs. Thus, API clients can be
	grained details of the problem (using the vocabulary defined here).		informed of both the high-level error class (using the response code)
	This pattern of communication is illustrated in Figure 1.		and the finer-grained details of the problem (using the vocabulary
			defined here). This pattern of communication is illustrated in
			Figure 1.
	.--------. .--------.		.--------. .--------.
	| CoAP | | CoAP |		| CoAP | | CoAP |
	| Client | | Server |		| Client | | Server |
	'----+---' '---+----'		'----+---' '---+----'
	| |		| |
	| Request |		| Request |
	o----------------->|		o----------------->|
	| | (failure)		| | (failure)
	|<-----------------o		|<-----------------o
	| Error Response |		| Error Response |
	| with a CBOR |		| with a CBOR |
	| data item giving |		| data item giving |
	| Problem Details |		| Problem Details |
	| |		| |
	Figure 1: Problem Details: Example with CoAP		Figure 1: Problem Details: Example with CoAP
	The framework presented is largely inspired by the Problem Details		The framework presented is largely inspired by the problem details
	for HTTP APIs defined in [RFC7807]. Appendix B discusses		for HTTP APIs defined in [RFC7807]. Appendix B discusses
	applications where interworking with [RFC7807] is required.		applications where interworking with [RFC7807] is required.
	1.1. Terminology and Requirements Language		1.1. Terminology and Requirements Language
	The terminology from [RFC7252], [STD94], and [RFC8610] applies; in		The terminology from [RFC7252], [STD94], and [RFC8610] applies; in
	particular CBOR diagnostic notation is defined in Section 8 of		particular, CBOR diagnostic notation is defined in Section 8 of RFC
	[STD94] and Appendix G of [RFC8610]. Readers are also expected to be		8949 [STD94] and Appendix G of [RFC8610]. Readers are also expected
	familiar with the terminology from [RFC7807].		to be familiar with the terminology from [RFC7807].
	In this document, the structure of data is specified in CDDL		In this document, the structure of data is specified in Concise Data
	[RFC8610] [RFC9165].		Definition Language (CDDL) [RFC8610] [RFC9165].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Basic Problem Details		2. Basic Problem Details
	A Concise Problem Details data item is a CBOR data item with the		A Concise Problem Details data item is a CBOR data item with the
	skipping to change at page 5, line 15 ¶		skipping to change at line 178 ¶
	Note that, unlike [RFC7807], Concise Problem Details data items have		Note that, unlike [RFC7807], Concise Problem Details data items have
	no explicit "problem type". Instead, the category (or, one could		no explicit "problem type". Instead, the category (or, one could
	say, Gestalt) of the problem can be understood from the shape of the		say, Gestalt) of the problem can be understood from the shape of the
	problem details offered. We talk of a "problem shape" for short.		problem details offered. We talk of a "problem shape" for short.
	The title (key -1):		The title (key -1):
	A short, human-readable summary of the problem shape. Beyond the		A short, human-readable summary of the problem shape. Beyond the
	shape of the problem, it is not intended to summarize all the		shape of the problem, it is not intended to summarize all the
	specific information given with the problem details. For		specific information given with the problem details. For
	instance, the summary might include that an account does not have		instance, the summary might include that an account does not have
	enough money for a transaction to succeed, but not the detail		enough money for a transaction to succeed but not the detailed
	information such as the account number, how much money that		information such as the account number, how much money that
	account has, and how much would be needed.		account has, and how much would be needed.
	The detail (key -2):		The detail (key -2):
	A human-readable explanation specific to this occurrence of the		A human-readable explanation specific to this occurrence of the
	problem.		problem.
	The instance (key -3):		The instance (key -3):
	A URI reference that identifies the specific occurrence of the		A URI reference that identifies the specific occurrence of the
	problem. It may or may not yield further information if		problem. It may or may not yield further information if
	dereferenced.		dereferenced.
	The response-code (key -4):		The response-code (key -4):
	The CoAP response code (Sections 5.9 and 12.1.2 of [RFC7252])		The CoAP response code (Sections 5.9 and 12.1.2 of [RFC7252])
	generated by the origin server for this occurrence of the problem.		generated by the origin server for this occurrence of the problem.
	The base-uri (key -5):		The base-uri (key -5):
	The base URI (Section 5.1 of [STD66]) that should be used to		The base URI (see Section 5.1 of RFC 3986 [STD66]) that should be
	resolve relative URI references embedded in this Concise Problem		used to resolve relative URI references embedded in this Concise
	Details data item.		Problem Details data item.
	The base-lang (key -6):		The base-lang (key -6):
	The language-tag (tag38-ltag) that applies to the presentation of		The language-tag (tag38-ltag) that applies to the presentation of
	unadorned text strings (not using tag 38) in this Concise Problem		unadorned text strings (not using tag 38) in this Concise Problem
	Details data item, see Appendix A.		Details data item; see Appendix A.
	The base-rtl (key -7):		The base-rtl (key -7):
	The writing-direction (tag38-direction) that applies to the		The writing-direction (tag38-direction) that applies to the
	presentation of unadorned text strings (not using tag 38) in this		presentation of unadorned text strings (not using tag 38) in this
	Concise Problem Details data item, see Appendix A.		Concise Problem Details data item; see Appendix A.
	Both "title" and "detail" can use either an unadorned CBOR text		Both "title" and "detail" can use either an unadorned CBOR text
	string (text) or a language-tagged text string (tag38); see		string (text) or a language-tagged text string (tag38); see
	Appendix A for the definition of the latter. Language tag and		Appendix A for the definition of the latter. Language tag and
	writing direction information for unadorned text strings are intended		writing direction information for unadorned text strings is intended
	to be obtained from context; if that context needs to be saved or		to be obtained from context; if that context needs to be saved or
	forwarded with a Concise Problem Details data item, "base-lang" and		forwarded with a Concise Problem Details data item, "base-lang" and
	"base-rtl" can be used for that. If no such (explicitly saved or		"base-rtl" can be used. If no such (explicitly saved or implicit)
	implicit) context information is available, unadorned text is		context information is available, unadorned text is interpreted with
	interpreted with language-tag "en" and writing-direction "false"		language-tag "en" and writing-direction "false" (ltr).
	(ltr).
	The "title" string is advisory and included to give consumers a		The "title" string is advisory and included to give consumers a
	shorthand for the category (problem shape) of the error encountered.		shorthand for the category (problem shape) of the error encountered.
	The "detail" member, if present, ought to focus on helping the client		The "detail" member, if present, ought to focus on helping the client
	correct the problem, rather than giving extensive server-side		correct the problem rather than giving extensive server-side
	debugging information. Consumers SHOULD NOT parse the "detail"		debugging information. Consumers SHOULD NOT parse the "detail"
	member for information; extensions (see Section 3) are more suitable		member for information; extensions (see Section 3) are more suitable
	and less error-prone ways to obtain such information. Note that the		and less error-prone ways to obtain such information. Note that the
	"instance" URI reference may be relative; this means that it must be		"instance" URI reference may be relative; this means that it must be
	resolved relative to the representation's base URI, as per Section 5		resolved relative to the representation's base URI, as per Section 5
	of [STD66].		of RFC 3986 [STD66].
	The "response-code" member, if present, is only advisory; it conveys		The "response-code" member, if present, is only advisory; it conveys
	the CoAP response code used for the convenience of the consumer.		the CoAP response code used for the convenience of the consumer.
	Generators MUST use the same response code here as in the actual CoAP		Generators MUST use the same response code here as in the actual CoAP
	response; the latter is needed to assure that generic CoAP software		response; the latter is needed to assure that generic CoAP software
	that does not understand the problem-details format still behaves		that does not understand the problem-details format still behaves
	correctly. Consumers can use the response-code member to determine		correctly. Consumers can use the "response-code" member to determine
	what the original response code used by the generator was, in cases		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		where it has been changed (e.g., by an intermediary or cache), and
	when message bodies persist without CoAP information (e.g., in an		when message bodies persist without CoAP information (e.g., in an
	events log or analytics database). Generic CoAP software will still		events log or analytics database). Generic CoAP software will still
	use the CoAP response code. To support the use case of message body		use the CoAP response code. To support the use case of message-body
	persistence without support by the problem-details generator, the		persistence without support by the problem-details generator, the
	entity that persists the Concise Problem Details data item can copy		entity that persists the Concise Problem Details data item can copy
	over the CoAP response code that it received on the CoAP level. Note		over the CoAP response code that it received on the CoAP level. Note
	that the "response-code" value is a numeric representation of the		that the "response-code" value is a numeric representation of the
	actual code (see Section 3 of [RFC7252]), so it does not take the		actual code (see Section 3 of [RFC7252]), so it does not take the
	usual presentation form that resembles an HTTP status code -- 4.04		usual presentation form that resembles an HTTP status code: 4.04 Not
	Not found is represented by the number 132.		Found is represented by the number 132.
	The "base-uri" member is usually not present in the initial request-		The "base-uri" member is usually not present in the initial request-
	response communication as it can be inferred as per Section 5.1.3 of		response communication as it can be inferred as per Section 5.1.3 of
	[STD66]. An entity that stores a Concise Problem Details data item		RFC 3986 [STD66]. An entity that stores a Concise Problem Details
	or otherwise makes it available for consumers without this context		data item or otherwise makes it available for consumers without this
	might add in a base-uri member to allow those consumers to perform		context might add in a "base-uri" member to allow those consumers to
	resolution of any relative URI references embedded in the data item.		perform resolution of any relative URI references embedded in the
			data item.
	3. Extending Concise Problem Details		3. Extending Concise Problem Details
	This specification defines a generic problem details container with		This specification defines a generic problem-details container with
	only a minimal set of attributes to make it usable.		only a minimal set of attributes to make it usable.
	It is expected that applications will extend the base format by		It is expected that applications will extend the base format by
	defining new attributes.		defining new attributes.
	These new attributes fall into two categories: generic and		These new attributes fall into two categories: generic and
	application specific.		application specific.
	Generic attributes will be allocated in the standard-problem-detail-		Generic attributes will be allocated in the standard-problem-detail-
	entries slot according to the registration procedure defined in		entries slot according to the registration procedure defined in
	Section 3.1.		Section 3.1.
	Application-specific attributes will be allocated in the custom-		Application-specific attributes will be allocated in the custom-
	problem-detail-entries slot according to the procedure described in		problem-detail-entries slot according to the procedure described in
	Section 3.2.		Section 3.2.
	Consumers of a Concise Problem Details data item MUST ignore any		Consumers of a Concise Problem Details data item MUST ignore any
	Standard or Custom Problem Detail entries, or keys inside the Custom		Standard Problem Detail entries or Custom Problem Detail entries, or
	Problem Detail entries, that they do not recognize ("ignore-unknown		keys inside the Custom Problem Detail entries, that they do not
	rule"); this allows problem details to evolve. When storing the data		recognize ("ignore-unknown rule"); this allows problem details to
	item for future use or forwarding it to other consumers, it is		evolve. When storing the data item for future use or forwarding it
	strongly RECOMMENDED to retain the unrecognized entries; exceptions		to other consumers, it is strongly RECOMMENDED to retain the
	might be when storage/forwarding occurs in a different format/		unrecognized entries; exceptions might be when storage or forwarding
	protocol that cannot accommodate them, or when the storage/forwarding		occurs in a different format/protocol that cannot accommodate them or
	function needs to filter out privacy-sensitive information and for		when the storage or forwarding function needs to filter out privacy-
	that needs to assume unrecognized entries might be privacy-sensitive.		sensitive information and for that needs to assume unrecognized
			entries might be privacy-sensitive.
	3.1. Standard Problem Detail Entries		3.1. Standard Problem Detail Entries
	Beyond the Standard Problem Detail keys defined in Figure 2,		Beyond the Standard Problem Detail keys defined in Figure 2,
	additional Standard Problem Detail keys can be registered for use in		additional Standard Problem Detail keys can be registered for use in
	the standard-problem-detail-entries slot (see Section 6.1).		the standard-problem-detail-entries slot (see Section 6.1).
	Standard Problem Detail keys are negative integers, so they can never		Standard Problem Detail keys are negative integers, so they can never
	conflict with Custom Problem Detail keys defined for a specific		conflict with Custom Problem Detail keys defined for a specific
	application domain (which are unsigned integers or URIs.)		application domain (which are unsigned integers or URIs.)
	In summary, the keys for Standard Problem Detail entries are in a		In summary, the keys for Standard Problem Detail entries are in a
	global namespace that is not specific to a particular application		global namespace that is not specific to a particular application
	domain.		domain.
	3.1.1. Standard Problem Detail Entry: Unprocessed CoAP Option		3.1.1. Standard Problem Detail Entry: Unprocessed CoAP Option
	Section 2 provides a number of generally applicable Standard Problem		Section 2 provides a number of generally applicable Standard Problem
	Detail Entries. The present section both registers another useful		Detail entries. The present section both registers another useful
	Standard Problem Detail entry and serves as an example of a Standard		Standard Problem Detail entry and serves as an example of a Standard
	Problem Detail Entry registration, in the registration template		Problem Detail Entry registration, in the registration template
	format that would be ready for registration.		format that would be ready for registration.
	| Key Value: TBD (assigned at registration)		Key value:
	|		-8
	| Name: unprocessed-coap-option		Name:
	|		unprocessed-coap-option
	| CDDL type: one-or-more<uint>, where		CDDL type:
	|		one-or-more<uint>, where
	| one-or-more<T> = T / [ 2* T ]		one-or-more<T> = T / [ 2* T ]
	|		Brief description:
	| Brief description: Option number(s) of CoAP option(s) that were		Option number(s) of CoAP option(s) that were not understood
	| not understood		Specification reference:
	|		Section 3.1.1 of RFC 9290
	| Specification reference: Section 3.1.1 of RFC XXXX
	// RFC Editor: please replace RFC XXXX with the RFC number of this
	// RFC and remove this note.
	The specification of the Standard Problem Detail entry referenced by		The specification of the Standard Problem Detail entry referenced by
	the above registration template follows:		the above registration template follows:
	The Standard Problem Detail entry unprocessed-coap-option provides		The Standard Problem Detail entry unprocessed-coap-option provides
	the option number(s) of CoAP option(s) present in the request that		the option number or numbers of any CoAP options present in the
	could not be processed by the server.		request that could not be processed by the server.
	This may be a critical option that the server is unaware of, or an		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		option the server is aware of but could not process (and chose not
	to, or was not allowed to, ignore it).		to, or was not allowed to, ignore it).
	The Concise Problem Details data item including this Standard Problem		The Concise Problem Details data item including this Standard Problem
	Detail Entry can be used in fulfillment of the "SHOULD" requirement		Detail Entry can be used in fulfillment of the "SHOULD" requirement
	in Section 5.4.1 of [RFC7252].		in Section 5.4.1 of [RFC7252].
	Several option numbers may be given in a list (in no particular		Several option numbers may be given in a list (in no particular
	order), without any guarantee that the list is a complete		order), without any guarantee that the list is a complete
	representation of all the problems in the request (as the server		representation of all the problems in the request (as the server
	might have stopped processing already at one of the problematic		might have stopped processing already at one of the problematic
	options). If an option with the given number was repeated, there is		options). If an option with the given number was repeated, there is
	no indication which of the values caused the error.		no indication which of the values caused the error.
	Clients need to expect seeing options in the list they did not send		Clients need to expect to see options in the list that they did not
	in the request; this can happen if the request traversed a proxy that		send in the request; this can happen if the request traversed a proxy
	added the option but did not act on the problem details response		that added the option but did not act on the problem-details response
	being returned by the origin server.		being returned by the origin server.
	Note that for a few special values of unprocessed CoAP options (such		For a few special values of unprocessed CoAP options (such as Accept
	as Accept or Proxy-Uri), there are special response codes (4.06 Not		or Proxy-Uri), note that there are special response codes (4.06 Not
	Acceptable, 5.05 Proxying Not Supported, respectively) to be sent		Acceptable, 5.05 Proxying Not Supported, respectively) to be sent
	instead of 4.02 Bad Option.		instead of 4.02 Bad Option.
	3.2. Custom Problem Detail Entries		3.2. Custom Problem Detail Entries
	Applications may extend the Problem Details data item with additional		Applications may extend the Concise Problem Details data item with
	entries to convey additional, application-specific information.		additional entries to convey additional, application-specific
			information.
	Such new entries are allocated in the custom-problem-detail-entries		Such new entries are allocated in the custom-problem-detail-entries
	slot, and carry a nested map specific to that application. The map		slot and carry a nested map specific to that application. The map
	key can either be an (absolute!) URI (under control of the entity		key can be either an (absolute!) URI (under control of the entity
	defining this extension), or an unsigned integer. Only the latter		defining this extension) or an unsigned integer. Only the latter
	needs to be registered (Section 6.2).		needs to be registered (Section 6.2).
	Within the nested map, any number of attributes can be given for a		Within the nested map, any number of attributes can be given for a
	single extension. The semantics of each custom attribute MUST be		single extension. The semantics of each custom attribute MUST be
	described in the documentation for the extension; for extensions that		described in the documentation for the extension; for extensions that
	are registered (i.e., are identified by an unsigned int) that		are registered (i.e., are identified by an unsigned int), that
	documentation goes along with the registration.		documentation goes along with the registration.
	The unsigned integer form allows a more compact representation. In		The unsigned integer form allows a more compact representation. In
	exchange, authors are expected to comply with the required		exchange, authors are expected to comply with the required
	registration and documentation process. In comparison, the URI form		registration and documentation process. In comparison, the URI form
	is less space-efficient but requires no registration. It is		is less space efficient but requires no registration. Therefore, it
	therefore useful for experimenting during the development cycle and		is useful for experimenting during the development cycle and for
	for applications deployed in environments where producers and		applications deployed in environments where producers and consumers
	consumers of Concise Problem Details are more tightly integrated.		of Concise Problem Details are more tightly integrated. (Thus, the
	(The URI form thus covers the potential need we might otherwise have		URI form covers the potential need we might otherwise have for a
	for a "private use" range for the unsigned integers.)		"Private Use" range for the unsigned integers.)
	Note that the URI given for the extension is for identification		Note that the URI given for the extension is for identification
	purposes only and, even if dereferenceable in principle, it MUST NOT		purposes only and, even if dereferenceable in principle, it MUST NOT
	be dereferenced in the normal course of handling problem details		be dereferenced in the normal course of handling problem details
	(i.e., outside diagnostic/debugging procedures involving humans).		(i.e., outside diagnostic or debugging procedures involving humans).
	Figure 3 shows an example (in CBOR diagnostic notation) of a custom		Figure 3 shows an example (in CBOR diagnostic notation) of a custom
	extension using a (made-up) URI as custom-problem-detail-entries key.		extension using a (made-up) URI as the custom-problem-detail-entries
			key.
	{		{
	/ title / -1: "title of the error",		/ title / -1: "title of the error",
	/ detail / -2: "detailed information about the error",		/ detail / -2: "detailed information about the error",
	/ instance / -3: "coaps://pd.example/FA317434",		/ instance / -3: "coaps://pd.example/FA317434",
	/ response-code / -4: 128, / 4.00 /		/ response-code / -4: 128, / 4.00 /
	"tag:3gpp.org,2022-03:TS29112": {		"tag:3gpp.org,2022-03:TS29112": {
	/ cause / 0: "machine-readable error cause",		/ cause / 0: "machine-readable error cause",
	/ invalidParams / 1: [		/ invalidParams / 1: [
	[		[
	/ param / "first parameter name",		/ param / "first parameter name",
	/ reason / "must be a positive integer"		/ reason / "must be a positive integer"
	],		],
	[		[
	/ param / "second parameter name"		/ param / "second parameter name"
	]		]
	],		],
	/ supportedFeatures / 2: "d34db33f"		/ supportedFeatures / 2: "d34db33f"
	}		}
	}		}
	Figure 3: Example Extension with URI key		Figure 3: Example Extension with URI Key
	Obviously, an SDO like 3GPP can also easily register such a custom		Obviously, a Standards Development Organization (SDO) like 3GPP can
	problem detail entry to receive a more efficient unsigned integer		also easily register such a Custom Problem Detail entry to receive a
	key; Figure 4 shows how the same example would look like using a		more efficient unsigned integer key; Figure 4 shows how the same
	(made-up) registered unsigned int as custom-problem-detail-entries		example would look using a (made-up) registered unsigned int as the
	key:		custom-problem-detail-entries key:
	{		{
	/ title / -1: "title of the error",		/ title / -1: "title of the error",
	/ detail / -2: "detailed information about the error",		/ detail / -2: "detailed information about the error",
	/ instance / -3: "coaps://pd.example/FA317434",		/ instance / -3: "coaps://pd.example/FA317434",
	/ response-code / -4: 128, / 4.00 /		/ response-code / -4: 128, / 4.00 /
	/4711 is made-up example key that is not actually registered:/		/4711 is made-up example key that is not actually registered:/
	4711: {		4711: {
	/ cause / 0: "machine-readable error cause",		/ cause / 0: "machine-readable error cause",
	/ invalidParams / 1: [		/ invalidParams / 1: [
	[		[
	/ param / "first parameter name",		/ param / "first parameter name",
	/ reason / "must be a positive integer"		/ reason / "must be a positive integer"
	],
	[
	/ param / "second parameter name"
	]
	],		],
	/ supportedFeatures / 2: "d34db33f"		[
	}		/ param / "second parameter name"
			]
			],
			/ supportedFeatures / 2: "d34db33f"
	}		}
			}
	Figure 4: Example Extension with unsigned int (registered) key		Figure 4: Example Extension with Unsigned Int (Registered) Key
	In summary, the keys for the maps used inside Custom Problem Detail		In summary, the keys for the maps used inside Custom Problem Detail
	entries are defined specifically to the identifier of that Custom		entries are defined specifically for use with the identifier of that
	Problem Detail entry, the documentation of which defines these		Custom Problem Detail entry, the documentation of which defines these
	internal entries, typically chosen to address a given application		internal entries, typically chosen to address a given application
	domain.		domain.
	When there is a need to evolve a Custom Problem Detail entry		When there is a need to evolve a Custom Problem Detail entry
	definition, the "ignore-unknown rule" discussed in the introduction		definition, the "ignore-unknown rule" discussed in Section 3 provides
	to Section 3 provides an easy way to include additional information.		an easy way to include additional information. The assumption is
	The assumption is that this is done in a backward and forward		that this is done in a backward- and forward-compatible way.
	compatible way. Sometimes, Custom Problem Detail entries may need to		Sometimes, Custom Problem Detail entries may need to evolve in a way
	evolve in a way where forward compatibility by applying the "ignore-		where forward compatibility by applying the "ignore-unknown rule"
	unknown rule" would not be appropriate: e.g., when adding a "must-		would not be appropriate: for example, when adding a "must-
	understand" member, which can only be ignored at the peril of		understand" member, which can only be ignored at the peril of
	misunderstanding the Concise Problem Details data item ("false		misunderstanding the Concise Problem Details data item ("false
	interoperability"). In this case, a new Custom Problem Detail key		interoperability"). In this case, a new Custom Problem Detail key
	can simply be registered for this case, keeping the old key backward		can simply be registered for this case, keeping the old key backward
	and forward compatible.		and forward compatible.
	4. Privacy Considerations		4. Privacy Considerations
	Problem details may unintentionally disclose information. This can		Problem details may unintentionally disclose information. This can
	lead to both privacy and security problems. See Section 5 for more		lead to both privacy and security problems. See Section 5 for more
	skipping to change at page 12, line 21 ¶		skipping to change at line 481 ¶
	Information (PII).		Information (PII).
	5. Security Considerations		5. Security Considerations
	Concise Problem Details can contain URIs that are not intended to be		Concise Problem Details can contain URIs that are not intended to be
	dereferenced (Section 3.2, Paragraph 5). One reason is that		dereferenced (Section 3.2, Paragraph 5). One reason is that
	dereferencing these can lead to information disclosure (tracking).		dereferencing these can lead to information disclosure (tracking).
	Information disclosure can also be caused by URIs in problem details		Information disclosure can also be caused by URIs in problem details
	that _are_ intended for dereferencing, e.g., the "instance" URI.		that _are_ intended for dereferencing, e.g., the "instance" URI.
	Implementations need to consider which component of a client should		Implementations need to consider which component of a client should
	perform the dereferencing, and which servers are trusted with serving		perform the dereferencing and which servers are trusted with serving
	them. In any case, the security considerations of Section 7 of		them. In any case, the security considerations of Section 7 of RFC
	[STD66] apply.		3986 [STD66] apply.
	The security and privacy considerations outlined in Section 5 of		The security and privacy considerations outlined in Section 5 of
	[RFC7807] apply in full. While these are phrased in terms of		[RFC7807] apply in full. While these are phrased in terms of
	security considerations for new RFC 7807 problem types, they equally		security considerations for new RFC 7807 problem types, they equally
	apply to the problem detail entry definitions used here Section 3; in		apply to the problem detail entry definitions used here (Section 3).
	summary: both when defining new detail entries, and when actually		In summary, both when defining new detail entries and when actually
	generating a Concise Problem Details data item, care needs to be		using them to generate a Concise Problem Details data item, care
	taken that they do not leak sensitive information. Entities storing		needs to be taken that they do not leak sensitive information.
	or forwarding Concise Problem Details data items need to consider		Entities storing or forwarding Concise Problem Details data items
	whether this leads to information being transferred out of the		need to consider whether this leads to information being transferred
	context within which access to sensitive information was acceptable.		out of the context within which access to sensitive information was
	See also Section 3, Paragraph 6 (the last paragraph of the		acceptable. See also Section 3, Paragraph 6 (the last paragraph of
	introduction to that section). Privacy-sensitive information in the		the introduction to that section). Privacy-sensitive information in
	problem details SHOULD NOT be obscured in ways that might lead to		the problem details SHOULD NOT be obscured in ways that might lead to
	misclassification as non-sensitive (e.g., by base64-encoding).		misclassification as non-sensitive (e.g., by base64-encoding).
	6. IANA Considerations		6. IANA Considerations
	// RFC Editor: please replace RFC XXXX with the RFC number of this		6.1. Standard Problem Detail Keys Registry
	// RFC and remove this note.
	6.1. Standard Problem Detail Key registry
	This specification defines a new sub-registry for Standard Problem		This specification defines a new subregistry titled "Standard Problem
	Detail Keys in the CoRE Parameters registry [IANA.core-parameters],		Detail Keys" in the "Constrained RESTful Environments (CoRE)
	with the policy "specification required" (Section 4.6 of [RFC8126]).		Parameters" registry [IANA.core-parameters], with "Specification
			Required" as the Registration Procedure (Section 4.6 of [RFC8126]).
	Each entry in the registry must include:		Each entry in the registry must include:
	Key value:		Key Value:
	a negative integer to be used as the value of the key		a negative integer to be used as the value of the key
	Name:		Name:
	a name that could be used in implementations for the key		a name that could be used in implementations for the key
	CDDL type:		CDDL Type:
	type of the data associated with the key in CDDL notation		type of the data associated with the key in CDDL notation
	Brief description:		Brief Description:
	a brief description		a brief description
	Change Controller:
	(see Section 2.3 of [RFC8126])
	Reference:		Reference:
	a reference document		a reference document
	The expert is requested to assign the shortest key values (1+0 and		Change Controller:
	1+1 encoding) to registrations that are likely to enjoy wide use and		(see Section 2.3 of [RFC8126])
	can benefit from short encodings.
	To be immediately useful in CDDL and programming language contexts, a		The designated expert is requested to assign the shortest key values
	name consists of a lower-case ASCII letter (a-z) and zero or more		(1+0 and 1+1 encoding) to registrations that are likely to enjoy wide
	additional ASCII characters that are either lower-case letters,		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		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 key values, names need to be unique.
	The specification in the reference document needs to provide a		The specification in the reference document needs to provide a
	description of the Standard Problem Detail entry, replicating the		description of the Standard Problem Detail entry, replicating the
	CDDL description in "CDDL type", and describing the semantics of 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.		presence of this entry and the semantics of the value given with it.
	Initial entries in this sub-registry are as follows:		Initial entries in this subregistry are as follows:
	+=======+==============+=================+=============+===========+		+=====+============+===============+===========+=========+==========+
	| Key | Name | CDDL Type | Brief | Reference |		|Key |Name |CDDL Type |Brief |Reference|Change |
	| value | | | description | |		|Value| | |Description| |Controller|
	+=======+==============+=================+=============+===========+		+=====+============+===============+===========+=========+==========+
	| -1 | title | text / tag38 | short, | RFC XXXX |		|-1 |title |text / tag38 |Short, |RFC 9290 |IETF |
	| | | | human- | |		| | | |human- | | |
	| | | | readable | |		| | | |readable | | |
	| | | | summary of | |		| | | |summary of | | |
	| | | | the problem | |		| | | |the problem| | |
	| | | | shape | |		| | | |shape | | |
	+-------+--------------+-----------------+-------------+-----------+		+-----+------------+---------------+-----------+---------+----------+
	| -2 | detail | text / tag38 | human- | RFC XXXX |		|-2 |detail |text / tag38 |Human- |RFC 9290 |IETF |
	| | | | readable | |		| | | |readable | | |
	| | | | explanation | |		| | | |explanation| | |
	| | | | specific to | |		| | | |specific to| | |
	| | | | this | |		| | | |this | | |
	| | | | occurrence | |		| | | |occurrence | | |
	| | | | of the | |		| | | |of the | | |
	| | | | problem | |		| | | |problem | | |
	+-------+--------------+-----------------+-------------+-----------+		+-----+------------+---------------+-----------+---------+----------+
	| -3 | instance | ~uri | URI | RFC XXXX |		|-3 |instance |~uri |URI |RFC 9290 |IETF |
	| | | | reference | |		| | | |reference | | |
	| | | | identifying | |		| | | |identifying| | |
	| | | | specific | |		| | | |specific | | |
	| | | | occurrence | |		| | | |occurrence | | |
	| | | | of the | |		| | | |of the | | |
	| | | | problem | |		| | | |problem | | |
	+-------+--------------+-----------------+-------------+-----------+		+-----+------------+---------------+-----------+---------+----------+
	| -4 | response- | uint .size 1 | CoAP | RFC XXXX |		|-4 |response- |uint .size 1 |CoAP |RFC 9290 |IETF |
	| | code | | response | |		| |code | |response | | |
	| | | | code | |		| | | |code | | |
	+-------+--------------+-----------------+-------------+-----------+		+-----+------------+---------------+-----------+---------+----------+
	| -5 | base-uri | ~uri | Base URI | RFC XXXX |		|-5 |base-uri |~uri |Base URI |RFC 9290 |IETF |
	+-------+--------------+-----------------+-------------+-----------+		+-----+------------+---------------+-----------+---------+----------+
	| -6 | base-lang | tag38-ltag | Base | RFC XXXX |		|-6 |base-lang |tag38-ltag |Base |RFC 9290 |IETF |
	| | | | language | |		| | | |language | | |
	| | | | tag (see | |		| | | |tag (see | | |
	| | | | Appendix A) | |		| | | |Appendix A)| | |
	+-------+--------------+-----------------+-------------+-----------+		+-----+------------+---------------+-----------+---------+----------+
	| -7 | base-rtl | tag38-direction | Base | RFC XXXX |		|-7 |base-rtl |tag38-direction|Base |RFC 9290 |IETF |
	| | | | writing | |		| | | |writing | | |
	| | | | direction | |		| | | |direction | | |
	| | | | (see | |		| | | |(see | | |
	| | | | Appendix A) | |		| | | |Appendix A)| | |
	+-------+--------------+-----------------+-------------+-----------+		+-----+------------+---------------+-----------+---------+----------+
	| TBD | unprocessed- | one-or- | Option | RFC XXXX, |		|-8 |unprocessed-|one-or- |Option |RFC 9290,|IETF |
	| | coap-option | more<uint> | number(s) | Section |		| |coap-option |more<uint> |number(s) |Section | |
	| | | | of CoAP | 3.1.1 |		| | | |of CoAP |3.1.1 | |
	| | | | option(s) | |		| | | |option(s) | | |
	| | | | that were | |		| | | |that were | | |
	| | | | not | |		| | | |not | | |
	| | | | understood | |		| | | |understood | | |
	+-------+--------------+-----------------+-------------+-----------+		+-----+------------+---------------+-----------+---------+----------+
	Table 1: Initial Entries in the Standard Problem Detail Key registry		Table 1: Initial Entries in the Standard Problem Detail Keys Registry
	6.2. Custom Problem Detail Key registry		6.2. Custom Problem Detail Keys Registry
	This specification defines a new sub-registry for Custom Problem		This specification defines a new subregistry titled "Custom Problem
	Detail Keys in the CoRE Parameters registry [IANA.core-parameters],		Detail Keys" in the "Constrained RESTful Environments (CoRE)
	with the policy "expert review" (Section 4.5 of [RFC8126]).		Parameters" registry [IANA.core-parameters], with as "Expert Review"
			as the Registration Procedure (Section 4.5 of [RFC8126]).
	The expert is instructed to attempt making the registration		The designated expert is instructed to attempt making the
	experience as close to first-come-first-served as reasonably		registration experience as close to First Come First Served as
	achievable, but checking that the reference document does provide a		reasonably achievable, but checking that the reference document does
	description as set out below. (This requirement is a relaxed version		provide a description as set out below. (This requirement is a
	of "specification required" as defined in Section 4.6 of [RFC8126].)		relaxed version of "Specification Required" as defined in Section 4.6
			of [RFC8126].)
	Each entry in the registry must include:		Each entry in the registry must include:
	Key value:		Key Value:
	an unsigned integer to be used as the value of the key		an unsigned integer to be used as the value of the key
	Name:		Name:
	a name that could be used in implementations for the key		a name that could be used in implementations for the key
	Brief description:		Brief Description:
	a brief description		a brief description
	Change Controller:
	(see Section 2.3 of [RFC8126])
	Reference:		Reference:
	a reference document that provides a description of the map,		a reference document that provides a description of the map,
	including a CDDL description, that describes all inside keys and		including a CDDL description, that describes all inside keys and
	values		values
	The expert is requested to assign the shortest key values (1+0 and		Change Controller
	1+1 encoding) to registrations that are likely to enjoy wide use and		(see Section 2.3 of [RFC8126])
	can benefit from short encodings.
	To be immediately useful in CDDL and programming language contexts, a		The designated expert is requested to assign the shortest key values
	name consists of a lower-case ASCII letter (a-z) and zero or more		(1+0 and 1+1 encoding) to registrations that are likely to enjoy wide
	additional ASCII characters that are either lower-case letters,		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		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 key values, names need to be unique.
	Initial entries in this sub-registry are as follows:		Initial entries in this subregistry are as follows:
	+=======+=============+===========================+===========+		+=======+=============+====================+===========+============+
	| Key | Name | Brief description | Reference |		| Key | Name | Brief | Reference | Change |
	| value | | | |		| Value | | Description | | Controller |
	+=======+=============+===========================+===========+		+=======+=============+====================+===========+============+
	| 7807 | tunnel-7807 | Carry RFC 7807 problem | RFC XXXX, |		| 7807 | tunnel-7807 | Carry RFC 7807 | RFC 9290, | IETF |
	| | | details in a Concise | Appendix |		| | | problem details | Appendix | |
	| | | Problem Details data item | B |		| | | in a Concise | B | |
	+-------+-------------+---------------------------+-----------+		| | | Problem Details | | |
			| | | data item | | |
			+-------+-------------+--------------------+-----------+------------+
	Table 2: Initial Entries in the Custom Problem Detail Key		Table 2: Initial Entries in the Custom Problem Detail Key Registry
	registry
	6.3. Media Type		6.3. Media Type
	IANA is requested to add the following Media-Type to the "Media		IANA has added the following media type to the "Media Types" registry
	Types" registry [IANA.media-types].		[IANA.media-types].
	+============================+============================+=========+		+============================+============================+=========+
	|Name |Template |Reference|		|Name |Template |Reference|
	+============================+============================+=========+		+============================+============================+=========+
	|concise-problem-details+cbor|application/concise-problem-|RFC XXXX,|		|concise-problem-details+cbor|application/concise-problem-|RFC 9290,|
	| |details+cbor |Section |		| |details+cbor |Section |
	| | |6.3 |		| | |6.3 |
	+----------------------------+----------------------------+---------+		+----------------------------+----------------------------+---------+
	Table 3: New Media Type application/concise-problem-details+cbor		Table 3: New Media Type 'application/concise-problem-details+cbor'
	Type name: application		Type name: application
	Subtype name: concise-problem-details+cbor		Subtype name: concise-problem-details+cbor
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: N/A		Optional parameters: N/A
	Encoding considerations: binary (CBOR data item)		Encoding considerations: binary (CBOR data item)
	Security considerations: Section 5 of RFC XXXX
			Security considerations: Section 5 of RFC 9290
	Interoperability considerations: none		Interoperability considerations: none
	Published specification: Section 6.3 of RFC XXXX
			Published specification: Section 6.3 of RFC 9290
	Applications that use this media type: Clients and servers in the		Applications that use this media type: Clients and servers in the
	Internet of Things		Internet of Things
	Fragment identifier considerations: The syntax and semantics of		Fragment identifier considerations: The syntax and semantics of
	fragment identifiers is as specified for "application/cbor". (At		fragment identifiers is as specified for "application/cbor". (At
	publication of RFC XXXX, there is no fragment identification		publication of RFC 9290, there is no fragment identification
	syntax defined for "application/cbor".)		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		Person & email address to contact for further information: CoRE WG
	mailing list (core@ietf.org), or IETF Applications and Real-Time		mailing list (core@ietf.org) or IETF Applications and Real-Time
	Area (art@ietf.org)		Area (art@ietf.org)
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author/Change controller: IETF		Author/Change controller: IETF
	Provisional registration: no		Provisional registration: no
	6.4. Content-Format		6.4. Content-Format
	IANA is requested to register a Content-Format number in the "CoAP		IANA has registered a Content-Format number in the "CoAP
	Content-Formats" sub-registry, within the "Constrained RESTful		Content-Formats" subregistry, within the "Constrained RESTful
	Environments (CoRE) Parameters" Registry [IANA.core-parameters], as		Environments (CoRE) Parameters" registry [IANA.core-parameters], as
	follows:		follows:
	+==============================+================+======+===========+		+==============================+==========+=====+===========+
	| Content-Type | Content Coding | ID | Reference |		| Media Type | Encoding | ID | Reference |
	+==============================+================+======+===========+		+==============================+==========+=====+===========+
	| application/concise-problem- | - | TBD1 | RFC XXXX |		| application/concise-problem- | - | 257 | RFC 9290 |
	| details+cbor | | | |		| details+cbor | | | |
	+------------------------------+----------------+------+-----------+		+------------------------------+----------+-----+-----------+
	Table 4: New Content-Format
	TBD1 is to be assigned from the space 256..999.
	In the registry as defined by Section 12.3 of [RFC7252] at the time		Table 4: Content-Format Registration
	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.
	6.5. CBOR Tag 38		6.5. CBOR Tag 38
	In the registry "CBOR Tags" [IANA.cbor-tags], IANA has registered		In the registry "CBOR Tags" [IANA.cbor-tags], IANA has registered
	CBOR Tag 38. IANA is requested to replace the reference for this		CBOR tag 38. IANA has updated the reference for CBOR tag 38 to point
	registration with Appendix A, RFC XXXX.		to RFC 9290, Appendix A.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[IANA.cbor-tags]		[IANA.cbor-tags]
	IANA, "Concise Binary Object Representation (CBOR) Tags",		IANA, "Concise Binary Object Representation (CBOR) Tags",
	19 September 2013,
	<https://www.iana.org/assignments/cbor-tags>.		<https://www.iana.org/assignments/cbor-tags>.
	[IANA.core-parameters]		[IANA.core-parameters]
	IANA, "Constrained RESTful Environments (CoRE)		IANA, "Constrained RESTful Environments (CoRE)
	Parameters", 8 June 2012,		Parameters",
	<https://www.iana.org/assignments/core-parameters>.		<https://www.iana.org/assignments/core-parameters>.
	[IANA.media-types]		[IANA.media-types]
	IANA, "Provisional Standard Media Type Registry", 20 July		IANA, "Provisional Standard Media Type Registry",
	2012, <https://www.iana.org/assignments/provisional-		<https://www.iana.org/assignments/provisional-standard-
	standard-media-types>.		media-types>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language		[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
	Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September		Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
	2006, <https://www.rfc-editor.org/info/rfc4647>.		2006, <https://www.rfc-editor.org/info/rfc4647>.
	skipping to change at page 18, line 44 ¶		skipping to change at line 802 ¶
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	[RFC9165] Bormann, C., "Additional Control Operators for the Concise		[RFC9165] Bormann, C., "Additional Control Operators for the Concise
	Data Definition Language (CDDL)", RFC 9165,		Data Definition Language (CDDL)", RFC 9165,
	DOI 10.17487/RFC9165, December 2021,		DOI 10.17487/RFC9165, December 2021,
	<https://www.rfc-editor.org/info/rfc9165>.		<https://www.rfc-editor.org/info/rfc9165>.
	[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, January 2005.
	<https://www.rfc-editor.org/info/rfc3986>.
			<https://www.rfc-editor.org/info/std66>
	[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object		[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,		Representation (CBOR)", STD 94, RFC 8949, December 2020.
	DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/std94>
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-httpapi-rfc7807bis]		[HTTPAPI] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
	Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
	for HTTP APIs", Work in Progress, Internet-Draft, draft-		for HTTP APIs", Work in Progress, Internet-Draft, draft-
	ietf-httpapi-rfc7807bis-03, 25 May 2022,		ietf-httpapi-rfc7807bis-04, 5 September 2022,
	<https://www.ietf.org/archive/id/draft-ietf-httpapi-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
	rfc7807bis-03.txt>.		rfc7807bis-04>.
	[RDF] Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1		[RDF] Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1
	Concepts and Abstract Syntax", W3C Recommendation, 25		Concepts and Abstract Syntax", W3C Recommendation, 25
	February 2014,		February 2014,
	<http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/>.		<http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC6082] Whistler, K., Adams, G., Duerst, M., Presuhn, R., Ed., and		[RFC6082] Whistler, K., Adams, G., Duerst, M., Presuhn, R., Ed., and
	J. Klensin, "Deprecating Unicode Language Tag Characters:		J. Klensin, "Deprecating Unicode Language Tag Characters:
	RFC 2482 is Historic", RFC 6082, DOI 10.17487/RFC6082,		RFC 2482 is Historic", RFC 6082, DOI 10.17487/RFC6082,
	November 2010, <https://www.rfc-editor.org/info/rfc6082>.		November 2010, <https://www.rfc-editor.org/info/rfc6082>.
	[Unicode-14.0.0]		[Unicode-14.0.0]
	The Unicode Consortium, "The Unicode Standard, Version		The Unicode Consortium, "The Unicode Standard, Version
	14.0.0", Mountain View: The Unicode Consortium,		14.0.0", Mountain View: The Unicode Consortium,
	ISBN 978-1-936213-29-0, September 2021,		ISBN 978-1-936213-29-0, September 2021,
	<https://www.unicode.org/versions/Unicode14.0.0/>. Note		<https://www.unicode.org/versions/Unicode14.0.0/>.
	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.
	[Unicode-14.0.0-bidi]		[Unicode-14.0.0-bidi]
	The Unicode Consortium, "Unicode® Standard Annex #9 ---		The Unicode Consortium, "Unicode Standard Annex #9 ---
	Unicode Bidirectional Algorithm", 27 August 2021,		Unicode Bidirectional Algorithm", 27 August 2021,
	<https://www.unicode.org/reports/		<https://www.unicode.org/reports/
	tr9/#Markup_And_Formatting>. Note that while this		tr9/#Markup_And_Formatting>.
	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.
	Appendix A. Language-Tagged Strings		Appendix A. Language-Tagged Strings
	This appendix serves as the archival documentation for CBOR Tag 38, a		This appendix serves as the archival documentation for CBOR tag 38, a
	tag for serializing language-tagged text strings in CBOR. The text		tag for serializing language-tagged text strings in CBOR. The text
	of this appendix is adapted from the specification text supplied for		of this appendix is adapted from the specification text supplied for
	its initial registration. It has been extended to allow		its initial registration. It has been extended to allow
	supplementing the language tag by a direction indication.		supplementing the language tag by a direction indication.
	As with any IANA-registered item, a specification that further		As with any IANA-registered item, a specification that further
	updates this registration needs to update the reference column of the		updates this registration needs to update the reference column of the
	IANA registry (see Section 6.5). Future specifications may update		IANA registry (see Section 6.5). Future specifications may update
	this appendix, other parts of this document, or both. (When updating		this appendix, other parts of this document, or both. (When updating
	this appendix, keep in mind that applications beyond concise problem		this appendix, keep in mind that applications beyond Concise Problem
	details may adopt the tag defined here.) Users of this tag are		Details data items may adopt the tag defined here.) Users of this
	advised to consult the registry to obtain the most recent update for		tag are advised to consult the registry to obtain the most recent
	this appendix.		update for this appendix.
	A.1. Introduction		A.1. Introduction
	In some cases it is useful to specify the natural language of a text		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		string. This specification defines a tag that does just that. One
	technology that supports language-tagged strings is the Resource		technology that supports language-tagged strings is the Resource
	Description Framework (RDF) [RDF].		Description Framework (RDF) [RDF].
	A.2. Detailed Semantics		A.2. Detailed Semantics
	A language-tagged string in CBOR has the tag 38 and consists of an		A language-tagged text string in CBOR has the tag 38 and consists of
	array with a length of 2 or 3.		an array with a length of 2 or 3.
	The first element is a well-formed language tag under Best Current		The first element is a well-formed language tag described in BCP 47
	Practice 47 ([RFC5646] and [RFC4647]), represented as a UTF-8 text		([RFC5646] and [RFC4647]), represented as a UTF-8 text string (major
	string (major type 3).		type 3).
	The second element is an arbitrary 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		Both the language tag and the arbitrary string can optionally be
	annotated with CBOR tags; this is not shown in the CDDL below.		annotated with CBOR tags; this is not shown in the CDDL below.
	The optional third element, if present, represents a ternary value		The optional third element, if present, represents a ternary value
	that indicates a direction, as follows:		that indicates a direction, as follows:
	* false: left-to-right direction ("ltr"). The text is expected to		* false: left-to-right direction ("ltr"). The text is expected to
	be displayed with left-to-right base direction if standalone, and		be displayed with left-to-right base direction if standalone and
	isolated with left-to-right direction (as if enclosed in LRI ...		isolated with left-to-right direction (as if enclosed in LRI ...
	PDI or equivalent, see [Unicode-14.0.0-bidi]) in the context of a		PDI or equivalent, see [Unicode-14.0.0-bidi]) in the context of a
	longer string or text.		longer string or text.
	* true: right-to-left direction ("rtl"). The text is expected to be		* true: right-to-left direction ("rtl"). The text is expected to be
	displayed with right-to-left base direction if standalone, and		displayed with right-to-left base direction if standalone and
	isolated with right-to-left direction (as if enclosed in RLI ...		isolated with right-to-left direction (as if enclosed in RLI ...
	PDI or equivalent, see [Unicode-14.0.0-bidi]) in the context of a		PDI or equivalent, see [Unicode-14.0.0-bidi]) in the context of a
	longer string or text.		longer string or text.
	* null indicates that no indication is made about the direction		* null: indicates that no indication is made about the direction
	("auto"), enabling an internationalization library to make an		("auto"), enabling an internationalization library to make an
	auto-detection decision such as treating the string as if enclosed		auto-detection decision such as treating the string as if enclosed
	in FSI ... PDI or equivalent, see [Unicode-14.0.0-bidi].		in FSI ... PDI or equivalent, see [Unicode-14.0.0-bidi].
	If the third element is absent, directionality context may be		If the third element is absent, directionality context may be applied
	applying (e.g., base directionality information for an entire CBOR		(e.g., base-directionality information for an entire CBOR message or
	message or part thereof). If there is no directionality context		part thereof). If there is no directionality context applied, the
	applying, the default interpretation is the same as for null		default interpretation is the same as for null ("auto").
	("auto").
	In CDDL:		In CDDL:
	tag38 = #6.38([tag38-ltag, text, ?tag38-direction])		tag38 = #6.38([tag38-ltag, text, ?tag38-direction])
	tag38-ltag = text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"		tag38-ltag = text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"
	tag38-direction = &(ltr: false, rtl: true, auto: null)		tag38-direction = &(ltr: false, rtl: true, auto: null)
	NOTE: Language tags of any combination of case are allowed. But		NOTE: Language tags of any combination of case are allowed. But
	Section 2.1.1 of [RFC5646], part of Best Current Practice 47,		Section 2.1.1 of [RFC5646], part of BCP 47, recommends a case
	recommends a case combination for language tags that encoders that		combination for language tags that encoders that support tag 38 may
	support tag 38 may wish to follow when generating language tags.		wish to follow when generating language tags.
	Data items with tag 38 that do not meet the criteria above are not		Data items with tag 38 that do not meet the criteria above are not
	valid (see Section 5.3.2 of [STD94]).		valid (see Section 5.3.2 of RFC 8949 [STD94]).
	NOTE: The Unicode Standard [Unicode-14.0.0] includes a set of		NOTE: The Unicode Standard [Unicode-14.0.0] includes a set of
	characters designed for tagging text (including language tagging), in		characters designed for tagging text (including language tagging) in
	the range U+E0000 to U+E007F. Although many applications, including		the range U+E0000 to U+E007F. Although many applications, including
	RDF, do not disallow these characters in text strings, the Unicode		RDF, do not disallow these characters in text strings, the Unicode
	Consortium has deprecated these characters and recommends annotating		Consortium has deprecated these characters and recommends annotating
	language via a higher-level protocol instead. See the section		language via a higher-level protocol instead. See the section
	"Deprecated Tag Characters" in Section 23.9 of [Unicode-14.0.0], as		"Deprecated Tag Characters" in Section 23.9 of [Unicode-14.0.0] as
	well as [RFC6082].		well as [RFC6082].
			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.
	A.3. Examples		A.3. Examples
	Examples in this section are given in CBOR diagnostic notation first		Examples in this section are given in CBOR diagnostic notation first
	and then as a pretty-printed hexadecimal representation of the		and then as a pretty-printed hexadecimal representation of the
	encoded item.		encoded item.
	The following example shows how the English-language string "Hello"		The following example shows how the English-language string "Hello"
	is represented.		is represented.
	38(["en", "Hello"])		38(["en", "Hello"])
	skipping to change at page 22, line 17 ¶		skipping to change at line 964 ¶
	38(["fr", "Bonjour"])		38(["fr", "Bonjour"])
	D8 26 # tag(38)		D8 26 # tag(38)
	82 # array(2)		82 # array(2)
	62 # text(2)		62 # text(2)
	6672 # "fr"		6672 # "fr"
	67 # text(7)		67 # text(7)
	426F6E6A6F7572 # "Bonjour"		426F6E6A6F7572 # "Bonjour"
	The following example shows how the Hebrew-language string "שלום"		The following example uses right-to-left (RTL) script, which in the
	(HEBREW LETTER SHIN, HEBREW LETTER LAMED, HEBREW LETTER VAV, HEBREW		context of this specification may be rendered differently by
	LETTER FINAL MEM, U+05E9 U+05DC U+05D5 U+05DD) is represented. Note		different document presentation environments. The descriptive text
	the rtl direction expressed by setting the third element in the array		may be more reliable to follow than the necessarily device- and
	to "true".		application-specific rendering. The example shows how the Hebrew-
			language string
			שלום
			is represented, where in direction of reading, the sequence of
			characters is: "ש" (HEBREW LETTER SHIN, U+05E9), "ל" (HEBREW LETTER
			LAMED, U+05DC), "ו" (HEBREW LETTER VAV, U+05D5), "ם" (HEBREW LETTER
			FINAL MEM, U+05DD). Note the rtl direction expressed by setting the
			third element in the array to "true".
	38(["he", "שלום", true])		38(["he", "שלום", true])
	D8 26 # tag(38)		D8 26 # tag(38)
	83 # array(3)		83 # array(3)
	62 # text(2)		62 # text(2)
	6865 # "he"		6865 # "he"
	68 # text(8)		68 # text(8)
	D7A9D79CD795D79D # "שלום"		D7A9D79CD795D79D # "שלום"
	F5 # primitive(21)		F5 # primitive(21)
	Appendix B. Interworking with RFC 7807		Appendix B. Interworking with RFC 7807
	On certain occasions, it will be necessary to carry ("tunnel")		On certain occasions, it will be necessary to carry ("tunnel")
	[RFC7807] problem details in a Concise Problem Details data item.		[RFC7807] problem details in a Concise Problem Details data item.
	This appendix defines a Custom Problem Details entry for that		This appendix defines a Custom Problem Detail entry for that purpose.
	purpose. This is assigned Custom Problem Detail key 7807 in		This is assigned Custom Problem Detail key 7807 in Section 6.2. Its
	Section 6.2. Its structure is:		structure is:
	tunnel-7807 = {		tunnel-7807 = {
	? &(type: 0) => ~uri		? &(type: 0) => ~uri
	? &(status: 1) => 0..999		? &(status: 1) => 0..999
	* text => any		* text => any
	}		}
	To carry an [RFC7807] problem details JSON object in a Concise		To carry an [RFC7807] problem details JSON object in a Concise
	Problem Details data item, first convert the JSON object to CBOR as		Problem Details data item, first convert the JSON object to CBOR as
	per Section 6.2 of [STD94]. Create an empty Concise Problem Details		per Section 6.2 of RFC 8949 [STD94]. Create an empty Concise Problem
	data item.		Details data item.
	Move the values for "title", "detail", and "instance", if present,		Move the values for "title", "detail", and "instance", if present,
	from the [RFC7807] problem details to the equivalent Standard Problem		from the [RFC7807] problem details to the equivalent Standard Problem
	Detail entries. Create a Custom Problem Details entry with key 7807.		Detail entries. Create a Custom Problem Detail entry with key 7807.
	Move the values for "type" and "status", if present, to the		Move the values for "type" and "status", if present, to the
	equivalent keys 0 and 1 of the Custom Problem Details entry. Move		equivalent keys 0 and 1 of the Custom Problem Detail entry. Move all
	all remaining key/value pairs (additional members as per Section 3.2		remaining key/value pairs (additional members as per Section 3.2 of
	of [RFC7807]) in the converted [RFC7807] problem details object to		[RFC7807]) in the converted [RFC7807] problem details object to the
	the Custom Problem Details map unchanged.		Custom Problem Detail map unchanged.
	The inverse direction, carrying Concise Problem Details in a Problem		The inverse direction, carrying Concise Problem Details in an RFC
	Details JSON object requires the additional support provided by		7807 problem details JSON object requires the additional support
	[I-D.ietf-httpapi-rfc7807bis], which is planned to create the HTTP		provided by [HTTPAPI], which is planned to create the HTTP Problem
	Problem Types Registry. An HTTP Problem Type can then be registered		Types Registry. An HTTP Problem Type can then be registered that
	that extracts top-level items from the Concise Problem Details data		extracts top-level items from the Concise Problem Details data item
	item in a similar way to the conversion described above, and which		in a similar way to the conversion described above and that carries
	carries the rest of the Concise Problem Details data item in an		the rest of the Concise Problem Details data item in an additional
	additional member via base64url encoding without padding (Section 5		member via base64url encoding without padding (Section 5 of
	of [RFC4648]). Details can be defined in a separate document when		[RFC4648]). Details can be defined in a separate document when the
	the work on [I-D.ietf-httpapi-rfc7807bis] is completed.		work on [HTTPAPI] is completed.
	Acknowledgments		Acknowledgments
	Mark Nottingham and Erik Wilde, authors of RFC 7807. Klaus Hartke		The authors would like to thank Mark Nottingham and Erik Wilde, the
	and Jaime Jiménez, co-authors of an earlier generation of this		authors of RFC 7807; Klaus Hartke and Jaime Jiménez, the coauthors of
	specification. Christian Amsüss, Marco Tiloca, Ari Keränen and		an earlier draft version of this specification; Christian Amsüss,
	Michael Richardson for review and comments on this document.		Marco Tiloca, Ari Keränen, and Michael Richardson for review and
	Francesca Palombini for her review (and support) as responsible AD,		comments on this document. Francesca Palombini for her review (and
	and Joel Jaeggli for his OPSDIR review, both of which brought		support) as responsible AD, and Joel Jaeggli for his OPSDIR review,
	significant additional considerations to this document.		both of which brought significant additional considerations to this
			document.
	For Appendix A, John Cowan and Doug Ewell are also to be		For Appendix A, John Cowan and Doug Ewell are also to be
	acknowledged. The content of an earlier version of this appendix was		acknowledged. The content of an earlier draft version of this
	also discussed in the "apps-discuss at ietf.org" and "ltru at		appendix was also discussed in the "apps-discuss@ietf.org" and
	ietf.org" mailing lists. More recently, the authors initiated a		"ltru@ietf.org" mailing lists. More recently, the authors initiated
	discussion about the handling of writing direction information in		a discussion about the handling of writing direction information in
	conjunction with language tags. That led to discussions within the		conjunction with language tags. That led to discussions within the
	W3C Internationalization Core Working Group. The authors would like		W3C Internationalization Core Working Group. The authors would like
	to acknowledge that cross-organization cooperation and particular		to acknowledge that cross-organization cooperation and particular
	contributions from John Klensin and Addison Phillips, and specific		contributions from John Klensin and Addison Phillips and specific
	text proposals by Martin Dürst.		text proposals by Martin Dürst.
	Contributors		Contributors
	Peter Occil		Peter Occil
	Email: poccil14 at gmail dot com		Email: poccil14@gmail.com
	URI: http://peteroupc.github.io/CBOR/		URI: http://peteroupc.github.io/CBOR/
	Peter defined CBOR tag 38, basis of Appendix A.		Peter defined CBOR tag 38, basis of Appendix A.
	Christian Amsüss		Christian Amsüss
	Email: christian@amsuess.com		Email: christian@amsuess.com
	Christian contributed what became Section 3.1.1.		Christian contributed what became Section 3.1.1.
	Authors' Addresses		Authors' Addresses
	Thomas Fossati		Thomas Fossati
	arm		Arm Limited
	Email: thomas.fossati@arm.com		Email: thomas.fossati@arm.com
	Carsten Bormann		Carsten Bormann
	Universität Bremen TZI		Universität Bremen TZI
	Postfach 330440		Postfach 330440
	D-28359 Bremen		D-28359 Bremen
	Germany		Germany
	Phone: +49-421-218-63921		Phone: +49-421-218-63921
	Email: cabo@tzi.org		Email: cabo@tzi.org
End of changes. 130 change blocks.
	442 lines changed or deleted		447 lines changed or added
This html diff was produced by rfcdiff 1.48.