draft-ietf-cbor-cddl-control-03.txt   draft-ietf-cbor-cddl-control-04.txt 
Network Working Group C. Bormann Network Working Group C. Bormann
Internet-Draft Universität Bremen TZI Internet-Draft Universität Bremen TZI
Intended status: Informational 4 March 2021 Intended status: Informational 31 July 2021
Expires: 5 September 2021 Expires: 1 February 2022
Additional Control Operators for CDDL Additional Control Operators for CDDL
draft-ietf-cbor-cddl-control-03 draft-ietf-cbor-cddl-control-04
Abstract Abstract
The Concise Data Definition Language (CDDL), standardized in RFC The Concise Data Definition Language (CDDL), standardized in RFC
8610, provides "control operators" as its main language extension 8610, provides "control operators" as its main language extension
point. point.
The present document defines a number of control operators that did The present document defines a number of control operators that did
not make it into RFC 8610: ".plus", ".cat" and ".det" for the not make it into RFC 8610: ".plus", ".cat" and ".det" for the
construction of constants, ".abnf"/".abnfb" for including ABNF (RFC construction of constants, ".abnf"/".abnfb" for including ABNF (RFC
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 September 2021. This Internet-Draft will expire on 1 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Computed Literals . . . . . . . . . . . . . . . . . . . . . . 3 2. Computed Literals . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Numeric Addition . . . . . . . . . . . . . . . . . . . . 3 2.1. Numeric Addition . . . . . . . . . . . . . . . . . . . . 4
2.2. String Concatenation . . . . . . . . . . . . . . . . . . 4 2.2. String Concatenation . . . . . . . . . . . . . . . . . . 4
2.3. String Concatenation with Dedenting . . . . . . . . . . . 5 2.3. String Concatenation with Dedenting . . . . . . . . . . . 5
3. Embedded ABNF . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Embedded ABNF . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Features . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Features . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
7. Security considerations . . . . . . . . . . . . . . . . . . . 10 7. Security considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Concise Data Definition Language (CDDL), standardized in RFC The Concise Data Definition Language (CDDL), standardized in RFC
8610, provides "control operators" as its main language extension 8610, provides "control operators" as its main language extension
point. point.
The present document defines a number of control operators that did The present document defines a number of control operators that did
not make it into RFC 8610: not make it into RFC 8610:
+==========+===========================================+ +==========+===========================================+
| Name | Purpose | | Name | Purpose |
+==========+===========================================+ +==========+===========================================+
| .plus | Numeric addition | | .plus | Numeric addition |
+----------+-------------------------------------------+ +----------+-------------------------------------------+
| .cat | String Concatenation | | .cat | String Concatenation |
+----------+-------------------------------------------+ +----------+-------------------------------------------+
| .det | String Concatenation, dedenting rhs | | .det | String Concatenation, pre-dedenting |
+----------+-------------------------------------------+ +----------+-------------------------------------------+
| .abnf | ABNF in CDDL (text strings) | | .abnf | ABNF in CDDL (text strings) |
+----------+-------------------------------------------+ +----------+-------------------------------------------+
| .abnfb | ABNF in CDDL (byte strings) | | .abnfb | ABNF in CDDL (byte strings) |
+----------+-------------------------------------------+ +----------+-------------------------------------------+
| .feature | Detecting feature use in extension points | | .feature | Detecting feature use in extension points |
+----------+-------------------------------------------+ +----------+-------------------------------------------+
Table 1: New control operators in this document Table 1: New control operators in this document
skipping to change at page 3, line 43 skipping to change at page 3, line 43
side operand, and "controller" to the right hand side operand. side operand, and "controller" to the right hand side operand.
2. Computed Literals 2. Computed Literals
CDDL as defined in [RFC8610] does not have any mechanisms to compute CDDL as defined in [RFC8610] does not have any mechanisms to compute
literals. As an 80 % solution, this specification adds three control literals. As an 80 % solution, this specification adds three control
operators: ".plus" for numeric addition, ".cat" for string operators: ".plus" for numeric addition, ".cat" for string
concatenation, and ".det" for string concatenation with dedenting of concatenation, and ".det" for string concatenation with dedenting of
the right hand side (controller). the right hand side (controller).
For these operators, as with all control operators, targets and
controllers are types. The resulting type is therefore formally a
function of the elements of the cross-product of the two types. Not
all tools may be able to work with non-unique targets or controllers.
2.1. Numeric Addition 2.1. Numeric Addition
In many cases in a specification, numbers are needed relative to a In many cases in a specification, numbers are needed relative to a
base number. The ".plus" control identifies a number that is base number. The ".plus" control identifies a number that is
constructed by adding the numeric values of the target and of the constructed by adding the numeric values of the target and of the
controller. controller.
Target and controller MUST be numeric. If the target is a floating Target and controller MUST be numeric. If the target is a floating
point number and the controller an integer number, or vice versa, the point number and the controller an integer number, or vice versa, the
sum is converted into the type of the target; converting from a sum is converted into the type of the target; converting from a
skipping to change at page 4, line 37 skipping to change at page 4, line 44
"interval" that gives a lower and an upper bound and optionally a "interval" that gives a lower and an upper bound and optionally a
tolerance. "rect" combines two of these groups into a map, one group tolerance. "rect" combines two of these groups into a map, one group
for the X dimension and one for Y dimension. for the X dimension and one for Y dimension.
2.2. String Concatenation 2.2. String Concatenation
It is often useful to be able to compose string literals out of It is often useful to be able to compose string literals out of
component literals defined in different places in the specification. component literals defined in different places in the specification.
The ".cat" control identifies a string that is built from a The ".cat" control identifies a string that is built from a
concatenation of the target and the controller. As targets and concatenation of the target and the controller. Target and
controllers are types, the resulting type is formally the cross- controller MUST be strings. The result of the operation has the type
product of the two types, although not all tools may be able to work of the target. The concatenation is performed on the bytes in both
with non-unique targets or controllers. strings. If the target is a text string, the result of that
concatenation MUST be valid UTF-8.
Target and controller MUST be strings. The result of the operation
has the type of the target. The concatenation is performed on the
bytes in both strings. If the target is a text string, the result of
that concatenation MUST be valid UTF-8.
a = "foo" .cat ' a = "foo" .cat '
bar bar
baz baz
' '
; on a system where the newline is \n, is the same string as: ; on a system where the newline is \n, is the same string as:
b = "foo\n bar\n baz\n" b = "foo\n bar\n baz\n"
Figure 2: Example: concatenation of text and byte string Figure 2: Example: concatenation of text and byte string
The example in Figure 2 builds a text string named "a" out of The example in Figure 2 builds a text string named "a" out of
concatenating the target text string ""foo"" and the controller byte concatenating the target text string ""foo"" and the controller byte
string entered in a text form byte string literal. (This particular string entered in a text form byte string literal. (This particular
idiom is useful when the text string contains newlines, which, as idiom is useful when the text string contains newlines, which, as
shown in the example for "b", may be harder to read when entered in shown in the example for "b", may be harder to read when entered in
the format that the pure CDDL text string notation inherits from the format that the pure CDDL text string notation inherits from
JSON.) JSON.)
skipping to change at page 5, line 33 skipping to change at page 5, line 41
cbor-tags-oid = ' cbor-tags-oid = '
oid = 1*arc oid = 1*arc
roid = *arc roid = *arc
arc = [nlsb] %x00-7f arc = [nlsb] %x00-7f
nlsb = %x81-ff *%x80-ff nlsb = %x81-ff *%x80-ff
' '
Figure 3: Example: dedenting concatenation Figure 3: Example: dedenting concatenation
The control operator ".det" works like ".cat", except that the right The control operator ".det" works like ".cat", except that both
hand side (controller) is _dedented_ first. For the purposes of this arguments (target and controller) are independently _dedented_ before
the concatenation takes place. For the purposes of this
specification, we define dedenting as: specification, we define dedenting as:
1. determining the smallest amount of left-most white space (number 1. determining the smallest amount of left-most white space (number
of leading space characters) in all the non-blank lines, and of leading space characters) in all the non-blank lines, and
2. removing exactly that number of leading space characters from 2. removing exactly that number of leading space characters from
each line. For blank (white space only or empty) lines, there each line. For blank (white space only or empty) lines, there
may be less (or no) leading space characters than this amount, in may be less (or no) leading space characters than this amount, in
which case all leading space is removed. which case all leading space is removed.
(The name ".det" is a shortcut for "dedenting cat". The maybe more (The name ".det" is a shortcut for "dedenting cat". The maybe more
obvious name ".dedcat" has not been chosen as it is longer and may obvious name ".dedcat" has not been chosen as it is longer and may
invoke unpleasant images.) invoke unpleasant images.)
If left-hand-side (target) dedenting is needed as well, this can be Occasionally, dedenting of only a single item is needed. This can be
achieved with the slightly longer construct "("" .det lhs) .det rhs". achieved by using this operator with an empty string, e.g., """ .det
rhs" or "lhs .det """, which can in turn be combined with a ".cat":
in the construct "lhs .cat ("" .det rhs)", only "rhs" is dedented.
3. Embedded ABNF 3. Embedded ABNF
Many IETF protocols define allowable values for their text strings in Many IETF protocols define allowable values for their text strings in
ABNF [RFC5234] [RFC7405]. It is often desirable to define a text ABNF [RFC5234] [RFC7405]. It is often desirable to define a text
string type in CDDL by employing existing ABNF embedded into the CDDL string type in CDDL by employing existing ABNF embedded into the CDDL
specification. Without specific ABNF support in CDDL, that ABNF specification. Without specific ABNF support in CDDL, that ABNF
would usually need to be translated into a regular expression (if would usually need to be translated into a regular expression (if
that is even possible). that is even possible).
skipping to change at page 6, line 47 skipping to change at page 7, line 13
by an "element" that selects from that ABNF and a newline. by an "element" that selects from that ABNF and a newline.
* For the same reason, ABNF requires newlines; specifying newlines * For the same reason, ABNF requires newlines; specifying newlines
in CDDL text strings is tedious (and leads to essentially in CDDL text strings is tedious (and leads to essentially
unreadable ABNF). The workaround employs the ".cat" operator unreadable ABNF). The workaround employs the ".cat" operator
introduced in Section 2.2 and the syntax for text in byte strings. introduced in Section 2.2 and the syntax for text in byte strings.
As is customary for ABNF, the syntax of ABNF itself (NOT the As is customary for ABNF, the syntax of ABNF itself (NOT the
syntax expressed in ABNF!) is relaxed to allow a single linefeed syntax expressed in ABNF!) is relaxed to allow a single linefeed
as a newline: as a newline:
CRLF = %x0A / %x0D.0A CRLF = %x0A / %x0D.0A
* One set of rules provided in an ABNF specification is often used * One set of rules provided in an ABNF specification is often used
in multiple positions, in particular staples such as DIGIT and in multiple positions, in particular staples such as DIGIT and
ALPHA. (Note that all rules referenced need to be defined in each ALPHA. (Note that all rules referenced need to be defined in each
ABNF operator controller string -- there is no implicit import of ABNF operator controller string -- there is no implicit import of
[RFC5234] Core ABNF or other rules.) The composition this calls [RFC5234] Core ABNF or other rules.) The composition this calls
for can be provided by the ".cat" operator. for can be provided by the ".cat" operator, and/or by ".det" if
there is indentation to be disposed of.
These points are combined into an example in Figure 4, which uses These points are combined into an example in Figure 4, which uses
ABNF from [RFC3339] to specify one of the CBOR tags defined in ABNF from [RFC3339] to specify one each of the CBOR tags defined in
[RFC8943]. [RFC8943] and [RFC8949].
; for draft-ietf-cbor-date-tag ; for RFC 8943
Tag1004 = #6.1004(text .abnf full-date) Tag1004 = #6.1004(text .abnf full-date)
; for RFC 7049 ; for RFC 8949
Tag0 = #6.0(text .abnf date-time) Tag0 = #6.0(text .abnf date-time)
full-date = "full-date" .det rfc3339 full-date = "full-date" .cat rfc3339
date-time = "date-time" .det rfc3339 date-time = "date-time" .cat rfc3339
; Note the trick of idiomatically starting with a newline, separating ; Note the trick of idiomatically starting with a newline, separating
; off the element in the concatenations above from the rule-list ; off the element in the concatenations above from the rule-list
rfc3339 = ' rfc3339 = '
date-fullyear = 4DIGIT date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12 date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year ; month/year
time-hour = 2DIGIT ; 00-23 time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59 time-minute = 2DIGIT ; 00-59
skipping to change at page 7, line 45 skipping to change at page 8, line 34
time-secfrac = "." 1*DIGIT time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac] [time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset full-time = partial-time time-offset
date-time = full-date "T" full-time date-time = full-date "T" full-time
' .cat rfc5234-core ' .det rfc5234-core
rfc5234-core = ' rfc5234-core = '
DIGIT = %x30-39 ; 0-9 DIGIT = %x30-39 ; 0-9
; abbreviated here ; abbreviated here
' '
Figure 4: Example: employing RFC 3339 ABNF for defining CBOR Tags Figure 4: Example: employing RFC 3339 ABNF for defining CBOR Tags
4. Features 4. Features
skipping to change at page 8, line 30 skipping to change at page 9, line 25
may mark the instance as using a feature that is annotated by the may mark the instance as using a feature that is annotated by the
specification. specification.
More specifically, the tool's diagnostic output might contain the More specifically, the tool's diagnostic output might contain the
controller (right hand side) as a feature name, and the target (left controller (right hand side) as a feature name, and the target (left
hand side) as a feature detail. However, in some cases, the target hand side) as a feature detail. However, in some cases, the target
has too much detail, and the specification might want to hint the has too much detail, and the specification might want to hint the
tool that more limited detail is appropriate. In this case, the tool that more limited detail is appropriate. In this case, the
controller should be an array, with the first element being the controller should be an array, with the first element being the
feature name (that would otherwise be the entire controller), and the feature name (that would otherwise be the entire controller), and the
second element being the detail (usually another string). second element being the detail (usually another string), as
illustrated in Figure 5.
foo = { foo = {
kind: bar / baz .feature (["foo-extensions", "bazify"]) kind: bar / baz .feature (["foo-extensions", "bazify"])
} }
bar = ... bar = ...
baz = ... ; complex stuff that doesn't all need to be in the detail baz = ... ; complex stuff that doesn't all need to be in the detail
Figure 5 shows what could be the definition of a person, with Figure 5: Providing explicit detail with .feature
Figure 6 shows what could be the definition of a person, with
potential extensions beyond "name" and "organization" being marked potential extensions beyond "name" and "organization" being marked
"further-person-extension". Extensions that are known at the time "further-person-extension". Extensions that are known at the time
this definition is written can be collected into "$$person- this definition is written can be collected into "$$person-
extensions". However, future extensions would be deemed invalid extensions". However, future extensions would be deemed invalid
unless the wildcard at the end of the map is added. These extensions unless the wildcard at the end of the map is added. These extensions
could then be specifically examined by a user or a tool that makes could then be specifically examined by a user or a tool that makes
use of the validation result; the label (map key) actually used makes use of the validation result; the label (map key) actually used makes
a fine feature detail for the tool's diagnostic output. a fine feature detail for the tool's diagnostic output.
Leaving out the entire extension point would mean that instances that Leaving out the entire extension point would mean that instances that
skipping to change at page 9, line 21 skipping to change at page 10, line 14
person = { person = {
? name: text ? name: text
? organization: text ? organization: text
$$person-extensions $$person-extensions
* (text .feature "further-person-extension") => any * (text .feature "further-person-extension") => any
} }
$$person-extensions //= (? bloodgroup: text) $$person-extensions //= (? bloodgroup: text)
Figure 5: Map extensibility with .feature Figure 6: Map extensibility with .feature
Figure 6 shows another example where ".feature" provides for type Figure 7 shows another example where ".feature" provides for type
extensibility. extensibility.
allowed-types = number / text / bool / null allowed-types = number / text / bool / null
/ [* number] / [* text] / [* bool] / [* number] / [* text] / [* bool]
/ (any .feature "allowed-type-extension") / (any .feature "allowed-type-extension")
Figure 6: Type extensibility with .feature Figure 7: Type extensibility with .feature
A CDDL tool may simply report the set of features being used; the A CDDL tool may simply report the set of features being used; the
control then only provides information to the process requesting the control then only provides information to the process requesting the
validation. One could also imagine a tool that takes arguments validation. One could also imagine a tool that takes arguments
allowing the tool to accept certain features and reject others allowing the tool to accept certain features and reject others
(enable/disable). The latter approach could for instance be used for (enable/disable). The latter approach could for instance be used for
a JSON/CBOR switch: a JSON/CBOR switch, as illustrated in Figure 8.
SenML-Record = { SenML-Record = {
; ... ; ...
? v => number ? v => number
; ... ; ...
} }
v = JC<"v", 2> v = JC<"v", 2>
JC<J,C> = J .feature "json" / C .feature "cbor" JC<J,C> = J .feature "json" / C .feature "cbor"
Figure 8: Describing variants with .feature
It remains to be seen if the enable/disable approach can lead to new It remains to be seen if the enable/disable approach can lead to new
idioms of using CDDL. The language currently has no way to enforce idioms of using CDDL. The language currently has no way to enforce
mutually exclusive use of features, as would be needed in this mutually exclusive use of features, as would be needed in this
example. example.
5. IANA Considerations 5. IANA Considerations
This document requests IANA to register the contents of Table 2 into This document requests IANA to register the contents of Table 2 into
the CDDL Control Operators registry [IANA.cddl]: the registry "CDDL Control Operators" of [IANA.cddl]:
+==========+===========+ +==========+===========+
| Name | Reference | | Name | Reference |
+==========+===========+ +==========+===========+
| .plus | [RFCthis] | | .plus | [RFCthis] |
+----------+-----------+ +----------+-----------+
| .cat | [RFCthis] | | .cat | [RFCthis] |
+----------+-----------+ +----------+-----------+
| .det | [RFCthis] | | .det | [RFCthis] |
+----------+-----------+ +----------+-----------+
| .abnf | [RFCthis] | | .abnf | [RFCthis] |
+----------+-----------+ +----------+-----------+
| .abnfb | [RFCthis] | | .abnfb | [RFCthis] |
+----------+-----------+ +----------+-----------+
| .feature | [RFCthis] | | .feature | [RFCthis] |
+----------+-----------+ +----------+-----------+
Table 2 Table 2: New control
operators to be
registered
6. Implementation Status 6. Implementation Status
This section is to be removed before publishing as an RFC.
An early implementation of the control operator ".feature" has been An early implementation of the control operator ".feature" has been
available in the CDDL tool described in Appendix F of [RFC8610] since available in the CDDL tool described in Appendix F of [RFC8610] since
version 0.8.11. The validator warns about each feature being used version 0.8.11. The validator warns about each feature being used
and provides the set of target values used with the feature. The and provides the set of target values used with the feature. The
other control operators defined in this specification are also other control operators defined in this specification are also
implemented as of version 0.8.21. implemented as of version 0.8.21 and 0.8.26 (double-handed ".det").
Andrew Weiss' [CDDL-RS] has an ongoing implementation of this draft Andrew Weiss' [CDDL-RS] has an ongoing implementation of this draft
which is feature-complete except for the ABNF and dedenting support which is feature-complete except for the ABNF and dedenting support
(https://github.com/anweiss/cddl/pull/79 (https://github.com/anweiss/cddl/pull/79
(https://github.com/anweiss/cddl/pull/79)). (https://github.com/anweiss/cddl/pull/79)).
7. Security considerations 7. Security considerations
The security considerations of [RFC8610] apply. The security considerations of [RFC8610] apply.
skipping to change at page 11, line 43 skipping to change at page 12, line 43
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC8943] Jones, M., Nadalin, A., and J. Richter, "Concise Binary [RFC8943] Jones, M., Nadalin, A., and J. Richter, "Concise Binary
Object Representation (CBOR) Tags for Date", RFC 8943, Object Representation (CBOR) Tags for Date", RFC 8943,
DOI 10.17487/RFC8943, November 2020, DOI 10.17487/RFC8943, November 2020,
<https://www.rfc-editor.org/info/rfc8943>. <https://www.rfc-editor.org/info/rfc8943>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
Acknowledgements Acknowledgements
Jim Schaad suggested several improvements. The ".feature" feature Jim Schaad suggested several improvements. The ".feature" feature
was developed out of a discussion with Henk Birkholz. Paul Kyzivat was developed out of a discussion with Henk Birkholz. Paul Kyzivat
helped isolate the need for ".det". helped isolate the need for ".det".
.det is an abbreviation for "dedenting cat", but Det is also the name
of a German TV Cartoon character created in the 1960s.
Author's Address Author's Address
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. 33 change blocks. 
59 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/