]> Independent

Montpellier France anders.rundgren.net@gmail.com https://www.linkedin.com/in/andersrundgren/

Application CBOR CBOR URL Identfier Type This document describes a CBOR tag for augmenting CBOR data items with type identifiers in the form of arbitrary CBOR text strings. This design enables type identifiers to optionally be expressed as URLs, potentially pointing to Web pages holding related descriptions in human readable form, as well as being compatible with established methods for adding type information to JSON and XML data.

Introduction This specification introduces a method for augmenting data expressed in the CBOR notation, with a type identifier mechanism based on CBOR text strings. The primary purposes of the text based type identifier tag described in this document are:

• Enabling developers defining application specific type identifiers without necessarily having to go through an external registration process.
• By supporting URLs as type identifiers, related human readable information may (through dereferencing), be provided for usage with Web browsers. Since URLs are compatible with firmly established methods for adding type information to JSON and XML data, this design may simplify a switch to CBOR. See also .

This specification is also intended to provide a path for ISO using CBOR as a possible alternative to XML by supporting their current URN based type identifier naming scheme. See also . By applying the typing scheme to top level CBOR objects, additional functionality is enabled including:

• Support for embedding CBOR objects in other CBOR and non-CBOR constructs, as well as storage in databases, without being forced adding information about the object.
• Remove the need for application specific media types. In many cases "application/cbor" would suffice.

Terminology In this document the term CBOR "object" is used interchangeably with the CBOR "data item". 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.

Specification This specification builds on the CBOR tag feature (major type 6), by defining a fixed tag with the preliminary decimal value of 1010. See also . This tag MUST in turn enclose a CBOR array (major type 4) with two elements, where the first element MUST contain a type identifier in textual format indicating the definition of a CBOR object, while the second element MUST hold an instance of the associated object itself. The type identifier MUST be a valid CBOR text string (major type 3), while the only constraint on the targeted object is that it MUST be a valid CBOR object. The syntax expressed in CBOR diagnostic notation (section 8 of ) would read as:     1010([Object Type Identifier, Object Instance Data]) Note that real-world usages will typically impose constraints like requiring type identifiers to be expressed as HTTPS URLs etc.

Sample Consider the following sample: 1010(["https://example.com/myobject", { 1: "data", 2: "more data" }]) Converting the sample above to CBOR expressed in hexadecimal notation (here shown with embedded comments as well), should result in the following output: D9 03F2 # tag(1010) 82 # array(2) 78 1C # text(28) 68747470733A2F2F6578616D706C652E636F6D2F6D796F626A656374 # "https://example.com/myobject" A2 # map(2) 01 # unsigned(1) 64 # text(4) 64617461 # "data" 02 # unsigned(2) 69 # text(9) 6D6F72652064617461 # "more data" In a typical implementation "https://example.com/myobject" would also serve as a hyper-link to human readable information about the identifier, accessed through a Web browser.

IANA Considerations In the registry , IANA is requested to allocate the tag defined in . Values for Tag Numbers

Tag	Data Item	Semantics	Reference
1010	array: [id: text string, obj: any]	Object type identifier	draft-rundgren-cotx-04

Security Considerations This specification inherits all the security considerations of CBOR . URL-based type identifiers MUST NOT be used for automatically downloading CBOR schema data like CDDL to CBOR processors, since this introduces potential vulnerabilities. The availability of type information does in no way limit the need for input data validation. For signed CBOR objects, it is RECOMMENDED to include the object type identifier extension in the signature calculation as well. The same considerations apply to encryption using AEAD algorithms.

References Normative References Internet Assigned Numbers Authority Informative References W3C What WG

URI and URL Identifiers The primary reason for using URI or URL based type identifiers is for maintaining a single name-space for the entire specification of a system. Note that the referenced URL specification does not distinguish between URIs and URLs. This non-normative section describes different methods for dealing with type identifiers expressed as URIs or URLs.

Registering a Dedicated Domain A core issue with identifiers depending on domain (DNS) names is that domain names may not necessarily remain valid during the anticipated life-time of an identifier. The owner of a domain name may due to organizational changes, neglect, lack of interest, or even death, lose control over its use, effectively leaving associated identifiers orphaned.

Using a Sub-domain An alternative is using a dedicated sub-domain belonging to an entity that is likely to survive for the foreseeable future. With the advent of public repositories like GitHub, this appears to be a simpler, cheaper, and more robust solution than maintaining dedicated domain names.

The 'tag' URI Scheme For applications where strict control over the name-space is hard to achieve, the 'tag' URI scheme may be used.

URN Identifiers ISO currently use URN based type identifiers like "urn:iso:std:iso:20022:tech:xsd:pain.001.001.10" for data definitions using XML schema . This method could be applied to CBOR and CDDL as well.

Acknowledgements People who have contributed with valuable feedback to this specification include , , and .

Document History [[ This section to be removed by the RFC Editor before publication as an RFC ]] Version 00:

• Initial publication.

Version 01:

• IANA reference update.

Version 02:

• Made type identifier a CBOR text string.
• Wordsmithing.

Version 03:

• Cleaner abstract and intro.

Version 04:

• Type identifier throughout the spec.