Notable CBOR Tags

1.1. The CBOR Tags Registry

CBOR tags are an extension point of CBOR, and that extension point is managed through an IANA registry ([IANA.cbor-tags] as set up in Section 9.2 of RFC 8949 [STD94]), not through publishing documents.¶

Some tag ranges require a stable specification to be publicly available under the "Specification Required" policy (Section 4.6 of RFC 8126 [BCP26]). That stable availability can be provided by any suitable means, such as a (specific revision of a) GitHub repository, a document published by an SDO or other entity, or even by a specific revision of an Internet-Draft, or an RFC if that happens to be in the pipeline. (In the latter case, while the RFC is being developed, the allocation will probably be made when that RFC still is in Internet-Draft state, which is then referenced in the registry and is usually updated to the RFC number when that is published.)¶

An example for this is provided by Section 9.1 of the present document. A few allocations were made for these tags (101, 121-127, 1280-1400) that are now a permanent part of the CBOR Tags registry. These allocations do reference revision –07 of the present Internet-Draft, because that contains an explanation of what these tags are supposed to be used for. That document revision –07 is part of the permanent record of the IETF and is not going away, so we are able to use it as a stable part of the information provided with the allocation. (In more recent revisions of the present document, some glue text was updated and a clerical error in illustrative CDDL code was fixed; eventually, there may be some incentive to update the registry entry to a newer revision of the present document.)¶

As with other stable specifications referenced this way, there is no need for the present document to be a published RFC before the tags become useful; i.e., the publication action that makes the tag numbers available for wide use in interchange is the acceptance of the tags into the IANA CBOR Tags registry.¶

1.2. Terminology

The definitions of [STD94] apply. Specifically: The term "byte" is used in its now customary sense as a synonym for "octet"; "byte strings" are CBOR data items carrying a sequence of zero or more (binary) bytes, while "text strings" are CBOR data items carrying a sequence of zero or more Unicode scalar values (code points that can be part of a string of Unicode characters), encoded in UTF-8 [STD63]. Where bit arithmetic is explained, this document uses the notation familiar from the programming language C ([C], including C++14's 0bnnn binary literals [Cplusplus20]), except that superscript notation (example for two to the power of 64: 2⁶⁴) denotes exponentiation; in the plain text version of this document, superscript notation is rendered in paragraph text by C-incompatible surrogate notation as seen in this example. Ranges expressed using .. are inclusive of the limits given. Type names such as "int", "bigint" or "decfrac" are taken from Appendix D of [RFC8610], the Concise Data Definition Language (CDDL).¶

2.1. Tags Related to Those Defined in RFC 7049

Separately registered tags that are directly related to the tags predefined in RFC 7049 include:¶

• Tag 63, registered by this document (Section 12), is a parallel to tag 24, with the single difference that its byte string tag content carries a CBOR Sequence [RFC8742] instead of a single encoded CBOR data item.¶

• Tag 108, registered by this document (Section 12), is a parallel to tag 23, with the single difference that the hexadecimal form uses lowercase instead of uppercase letters.¶

  • • Note that tag 23 has a serialization that is one byte shorter than tag 108, so if all else is equal, tag 23 (and thus upper case hex) would be chosen as it is slightly more efficient than tag 108. However, designers of CBOR protocols that use one of these tags often have reason to prefer lowercase hex in the application they are trying to be compatible with, in which case 108 provides a solution that is only one byte more expensive.¶

• Tag 257, registered by Peter Occil with a specification in http://peteroupc.github.io/CBOR/binarymime.html, is a parallel to tag 36, except that the tag content is a byte string, which therefore can also carry binary MIME messages as per [RFC2045].¶

• Tag 21065, having been registered by this document (Section 12), is a parallel to tag 35, with the difference that its text string tag content carries an I-Regexp regular expression [RFC9485] instead of a regexp of a more unspecified flavor. Companion tag 21066, having been registered by Joe Hildebrand with a specification in https://github.com/hildjj/cbor-specs/blob/main/regexp.md, is the equivalent for JavaScript (ECMA262), but besides the regular expression itself also can include the regular expression flags as a separate item.¶

2.2. Tags from RFC 7049 not listed in RFC 8949

Appendix G.3 of RFC 8949 [STD94] states:¶

Tag 35 is not defined by this document; the registration based on the definition in RFC 7049 remains in place.¶

The reason for this exclusion is that the definition of Tag 35 in Section 2.4.4.3 of [RFC7049], leaves too much open to ensure interoperability:¶

Tag 35 is for regular expressions in Perl Compatible Regular Expressions (PCRE) / JavaScript syntax [ECMA262].¶

Not only are two partially incompatible specifications given for the semantics, JavaScript regular expressions have also developed significantly within the decade since JavaScript 5.1 (which was referenced as "ECMA262" by [RFC7049]), making it less reliable to assume that a producing application will manage to stay within that 2011 subset.¶

Nonetheless, the registration is in place, so it is available for applications that simply want to mark a text string as being a regular expression roughly of the PCRE/Javascript flavor families. See also Tag 21065 and 21066 above.¶

3.1. COSE

CBOR Object Signing and Encryption (COSE) is defined in a number of RFCs. [RFC8152] was the initial specification, set up the registries, and populated them with an initial set of assignments. A revision split this specification into the data structure definitions (RFC9052), an Internet Standard [STD96], and a separate document defining the representation for the algorithms employed [RFC9053], which is expected to be updated more frequently than the COSE format itself. [RFC9054] added a separate set of algorithms for cryptographic hash functions (Hash functions have been a component of some [RFC9053] combined algorithms but weren't originally assigned separate codepoints themselves). A revised COSE counter signature structure was defined in RFC9338, another part of [STD96]; this also defines a tag for these.¶

Standard_COSE_Hash<alg, value> =
    #6.<hashmiddle .plus (alg .within directhash)>(value)
General_COSE_Hash<alg, value> = #6.<hashmiddle>([
    hashAlg: alg .within (int .ne directhash  / tstr),
    hashValue: value .within bstr ])
hashmiddle = 18556
directhash = (-256 .. -1) / (1 .. 255)

18540(
 h'b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9')

=============== NOTE: '\' line wrapping per RFC 8792 ================

d9 486c                                 # tag(18540)
   58 20                                # bytes(32)
      \
     b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

18556([-4711, h'1234123412341234123412341234123412341234'])

3.2. RFC 8392 (CWT)

[RFC8392] defines the CBOR Web Token (CWT), making use of COSE to define a CBOR variant of the JOSE Web Token (JWT), [RFC7519], a standardized security token that has found use in the area of web applications, but is not technically limited to those.¶

4.1. YANG-CBOR

YANG [RFC7950] is a data modeling language originally designed in the context of the Network Configuration Protocol (NETCONF) [RFC6241], now widely used for modeling management and configuration information. [RFC7950] defines an XML-based representation format, and [RFC7951] defines a JSON-based [RFC8259] representation format for YANG.¶

YANG-CBOR [RFC9254] is a representation format for YANG data in CBOR.¶

[I-D.bormann-cbor-yang-standin] proposes to employ additional tags to enable the use of efficient binary encodings for certain frequently used YANG data types [RFC9911].¶

5.1. DOTS

DDoS Open Threat Signaling (DOTS) defines tag number 271 for the DOTS signal channel object in [RFC9132].¶

5.2. RAINS

As an example for how experimental protocols can make use of CBOR tag definitions, the RAINS (Another Internet Naming Service) Protocol Specification defines tag number 15309736 for a RAINS Message [I-D.trammell-rains-protocol]. (The seemingly random tag number was chosen so that, when represented as an encoded CBOR tag argument, it contains the Unicode character "雨" (U+96E8) in UTF-8, which represents rain in a number of languages.)¶

6.1. Advanced arithmetic

General information about the representation of numbers in CBOR can be found in [STD94] as well as [I-D.bormann-cbor-numbers].¶

A number of tags have been registered for arithmetic representations beyond those built into CBOR and defined by tags in [RFC7049]. These are all documented under http://peteroupc.github.io/CBOR/; the last pathname component for the URL is given in the column "Reference" of Table 5.¶