| RFC 9581 | CBOR Tag for Extended Time | August 2024 |
| Bormann, et al. | Standards Track | [Page] |
The Concise Binary Object Representation (CBOR, RFC 8949) is a dataformat whose design goals include the possibility of extremely smallcode size, fairly small message size, and extensibility without theneed for version negotiation.¶
In CBOR, one point of extensibility is the definition of CBOR tags.RFC 8949 defines two tags for time: CBOR tag 0 (RFC 3339 time as a string) and tag1 (POSIX time as int or float). Since then, additional requirements havebecome known. The present document defines a CBOR tag for time thatallows a more elaborate representation of time, as well as relatedCBOR tags for duration and time period. This document isintended as the reference document for the IANA registration of theCBOR tags defined.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9581.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Concise Binary Object Representation (CBOR)[RFC8949] providesfor the interchange of structured data without a requirement for apre-agreed schema.RFC 8949 defines a basic set of data types, as well as a taggingmechanism that enables extending the set of data types supported viaan IANA registry for CBOR tags (see[IANA.cbor-tags] andSection 9.2 of [RFC8949]).¶
RFC 8949 defines two tags for time: CBOR tag 0 ([RFC3339] time as a string) and tag1 (POSIX time as int or float). Since then, additional requirements havebecome known. The present document defines a CBOR tag for time thatallows a more elaborate representation of time, as well as relatedCBOR tags for durations and time periods. This document isintended as the reference document for the IANA registration of theCBOR tags defined.¶
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[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The term "byte" is used in its now customary sense as a synonym for"octet".¶
Superscript notation denotes exponentiation. For example, 2 to thepower of 64 is notated: 264. In the plain-text renditionof this specification, superscript notation is not available andexponentiation is therefore rendered by the surrogate notation seenhere in the plain-text rendition.¶
CBOR diagnostic notation is defined inSection 8 of [RFC8949] andAppendix G of [RFC8610].A machine-processable model of the data structures defined in thisspecification is provided throughout the text using the Concise DataDefinition Language (CDDL)[RFC8610];Appendix A provides thecollected model information.¶
Several time-related terms, such as UTC and International Atomic Time (TAI), are discussed in[RFC9557], which may be a useful companion document beyond its directuse in Sections3.6 and3.7.¶
For the time tag,the present specification addresses the following objectives that gobeyond the original tags 0 and 1 (defined in Sections3.4.1 and3.4.2 of[RFC8949]):¶
Additional resolution for epoch-based time (as in tag 1). CBOR tag 1 only provides for representation of time as an integer and as up to a binary64 floating-point value[IEEE754], which limits the resolution to approximatelymicroseconds at the time of writing (progressively becomingworse over time).¶
Indication of timescale. Tags 0 and 1 are defined for UTC; however, someinterchanges are better performed on TAI. Other timescales may beregistered once they become relevant (e.g., one of the proposedsuccessors to UTC that might no longer use leap seconds or ascale based on smeared leap seconds).¶
By incorporating a way to transport[RFC9557] suffix information (see Sections3.6 and3.7), additional indications of intents about the interpretation of the time given can be provided; in particular, for instances oftime that, at the time they are being described, are in the future.Intents might include information about time zones, daylight savingtimes, preferred calendar representations, etc.¶
Semantics not covered by this document can be added by registeringadditional map keys for the map that is the content of the tag (seeetime-detailed inFigure 1),the specification forwhich is referenced by the registry entry (seeSection 3).¶
For example, map keys could be registered for direct representationsof natural platform time formats. Some platforms use epoch-basedtime formats that require some computation to convert them into therepresentations allowed by tag 1; these computations can also loseprecision and cause ambiguities. (The present specification doesnot take a position on whether tag 1 can be "fixed" to include,e.g., Decimal or Bigfloat representations. It does define how touse these representations with the extended time format.)¶
Additional tags are defined for durations and periods.¶
An extended time is indicated by CBOR tag 1001, the content of which is a map dataitem (CBOR major type 5). The map may contain integer (major types 0and 1) or text string (major type 3) keys, with the value typedetermined by each specific key.For negative integer keys and text string values of the key,implementationsMUST ignore key/value pairs they do not understand;these keys are "elective", as the extended time as a whole is stillusable without the information they carry if an implementation elects not to implement them. Conversely, implementationsMUST signal an errorwhen encountering key/value pairs that use unsigned integer keys they do not understand or implement (theseare either "base time" or "critical", see below).¶
The mapMUST contain exactly one unsigned integer key that specifiesthe "base time" andMAY also contain one or more negative integer ortext-string keys, which may encode supplementary information.¶
Supplementary informationMAY also be provided by additional unsignedinteger keys that are explicitly defined to provide supplementaryinformation (we say these keys are defined to be "critical"); as theseare required to be understood, there can be no confusion with basetime keys.¶
Negative integer and text string keys always supply supplementaryinformation (they are "elective", and this will not be explicitly statedbelow).¶
Supplementary information may include:¶
a higher precision time offset to be added to the base time,¶
a reference timescale and epoch different from the default UTC and 1970-01-01, and¶
information about clock quality parameters, such as source,accuracy, and uncertainty.¶
Additional keys can be defined by registering them in the "Time Tag Map Keys"registry (Section 7.3).Registered keys may, for instance, add intent information such as time zone, daylight saving time,and/or possibly positioning coordinates to express information that would indicate a local time.¶
This document does not define supplementary text keys.A number of both unsigned and negative-integer keys are defined inthe following subsections.¶
Figure 1 provides a formal definition of tag 1001 in CDDL.¶
Etime = #6.1001(etime-detailed)etime-framework = { uint => any ; at least one base time * (nint/text) => any ; elective supplementary information * uint => any ; critical supplementary information}etime-detailed = ({ $$ETIME-BASETIME ClockQuality-group * $$ETIME-ELECTIVE * $$ETIME-CRITICAL * ((nint/text) .feature "etime-elective-extension") => any * (uint .feature "etime-critical-extension") => any}) .within etime-frameworkKey 1 indicates a base time value that is exactly like the data item that wouldbe tagged by CBOR tag 1 (POSIX time[TIME_T] as int or float).As described above, the time value indicated by the value under thiskey can be furthermodified by other keys.¶
$$ETIME-BASETIME //= (1: ~time)¶
Keys 4 and 5 indicate a base time value and are like key 1, except that the data item is an array asdefined for CBOR tag 4 or 5, respectively.This can be used to include a Decimal or Bigfloat epoch-based float[TIME_T] in an extended time, e.g., to achieve higher resolution or toavoid rounding errors.¶
$$ETIME-BASETIME //= (4: ~decfrac)$$ETIME-BASETIME //= (5: ~bigfloat)¶
The keys -3, -6, -9, -12, -15, and -18 indicate additional decimal fractions bygiving an unsigned integer (major type 0) and scaling this with thescale factor 1e-3, 1e-6, 1e-9, 1e-12, 1e-15, and 1e-18, respectively(seeTable 1).Each extended time data itemMUST NOT contain more than oneof these keys.These additional fractions are added to a base time in seconds[SI-SECOND]indicated by key 1, which thenMUST also be present andMUST have aninteger value.¶
| Key | Meaning | Example Usage |
|---|---|---|
| -3 | milliseconds | Java time |
| -6 | microseconds | (old) UNIX time |
| -9 | nanoseconds | (new) UNIX time |
| -12 | picoseconds | Haskell time |
| -15 | femtoseconds | (future) |
| -18 | attoseconds | (future) |
$$ETIME-ELECTIVE //= (-3: uint)$$ETIME-ELECTIVE //= (-6: uint)$$ETIME-ELECTIVE //= (-9: uint)$$ETIME-ELECTIVE //= (-12: uint)$$ETIME-ELECTIVE //= (-15: uint)$$ETIME-ELECTIVE //= (-18: uint)¶
Note that these keys have been provided to facilitate representingpairs of the form second/decimal fraction of a second, as found forinstance in Ctimespec (Section 7.27.1 of[C]).When ingesting a timestamp with one of these keys into a type providedby the target platform, care has to be taken to meet its invariants.For example, for Ctimespec, the fractional parttv_nsec needs to bebetween 0 inclusive and 109 exclusive, which can beachieved by also adjusting the base time appropriately.¶
Keys -1, -13, and 13 are used to indicate a timescale, where key 13 is critical. Keys -1 and -13 have identical semantics (both are assigned because key -1 was chosen first and then, when key 13 was added, it appeared desirable to have a negative equivalent). Each extended time data itemMUST NOT contain more than one of these keys.¶
The value 0 indicates UTC,with the POSIX epoch[TIME_T]; the value 1 indicates TAI, with thePrecision Time Protocol (PTP) epoch (1 January 1970 00:00:00 TAI, see[IEEE1588-2019] or[IEEE1588-2008]).¶
$$ETIME-ELECTIVE //= (-1 => $ETIME-TIMESCALE)$$ETIME-ELECTIVE //= (-13 => $ETIME-TIMESCALE)$$ETIME-CRITICAL //= (13 => $ETIME-TIMESCALE)$ETIME-TIMESCALE /= &(etime-utc: 0)$ETIME-TIMESCALE /= &(etime-tai: 1)¶
If none of the keys are present, the default timescale value 0 is implied.¶
Timescale valuesMUST be unsigned integers or text strings; text strings areprovided for experimentation andMUST NOT be used between partiesthat are not both part of the experiment.Additional unsigned integer values can be registered in the "Timescales" registry(Section 7.2).(Note that there should be no timescales "GPS" or "NTP"[RFC5905] -- instead,the time should be converted to TAI or UTC using a single addition or subtraction.)¶
Editor's note:This initial set of timescales was deliberately chosen to be frugal, asthe specification of the tag provides an extension point whereadditional timescales can be registered at any time.Registrations are clearly needed for earth-referenced timescales (suchas UT1 and TT), as well as possibly for specific realizations ofabstract timescales (such as TAI(USNO), the specific realization obtained at the United States Naval Observatory, which is more accurate as aconstant offset basis for GPS times).While the registration process itself is trivial, these registrationsneed to be made based on a solid specification of their actualdefinition.¶
A number of keys are defined to indicate the quality of the clock that wasused to determine the point in time.¶
The first three are analogous toclock-quality-grouping in[RFC8575], which is in turn based on the definitions in[IEEE1588-2008]; the last two are specific to this document.¶
ClockQuality-group = ( ? &(ClockClass: -2) => uint .size 1 ; PTP/RFC8575 ? &(ClockAccuracy: -4) => uint .size 1 ; PTP/RFC8575 ? &(OffsetScaledLogVariance: -5) => uint .size 2 ; PTP/RFC8575 ? &(Uncertainty: -7) => ~time/~duration ? &(Guarantee: -8) => ~time/~duration)¶
Key -2 (ClockClass) can be used to indicate the clock class as per[RFC8575] (which is based on Table 5 in Section 7.6.2.4 of[IEEE1588-2008]; Table 4 in Section 7.6.2.5 of[IEEE1588-2019] has updated language).It is defined as a one-byte unsigned integer as that is the rangedefined in IEEE 1588.¶
Key -4 (ClockAccuracy) can be used to indicate the clock accuracy asper[RFC8575] (which is based on Table 6 in Section 7.6.2.5 of[IEEE1588-2008]; additional values have been defined in Table 5 inSection 7.6.2.6 of[IEEE1588-2019]).It is defined as a one-byte unsigned integer as that is the range defined there.The range between 23 and 47 is a slightly distorted logarithmic scalefrom 1 ps to 1 s in[IEEE1588-2019] (in[IEEE1588-2008], the range wasa subset of that, 32 to 47 for 25 ns to 1 s) -- seeFigure 3; the number 254 is thevalue to be used if an unknown accuracy needs to be expressed.¶
Key -5 (OffsetScaledLogVariance) can be used to represent the varianceexhibited by the clock when it has lost its synchronization with anexternal reference clock. The details for the computation of thischaracteristic are defined in Section 7.6.3 of[IEEE1588-2019] and thesame section in[IEEE1588-2008].¶
Key -7 (Uncertainty) can be used to represent a known uncertainty of measurement for the clock as a numeric value in seconds or as a duration (Section 4).¶
For this document, uncertainty is defined as in Section 2.2.3 of[GUM]: "parameter, associated with the result of a measurement, thatcharacterizes the dispersion of the values that could reasonably beattributed to the measurand". More specifically, the value for thiskey represents the expanded uncertainty for k = 2 (Section 6.2.1 of[GUM]) in seconds.¶
Note that the additional information that can be meaningfully providedwith the duration that represents an uncertainty is limited, e.g., itis not customary to provide an uncertainty for a duration representingan uncertainty.Implementations are free to reduce the information contained in anuncertainty (which is already elective) to the information they canprocess.¶
For example, a timestamp that is given to a resolution of10-6 seconds (microseconds) but only has an uncertainty of10-3 seconds (milliseconds) could be expressed by one ofthe extended time tags inFigure 4 (note the slightrounding error in the third case, which is probably inconsequentialfor an uncertainty value):¶
1001({1: 1697724754, -6: 873294, -7: {1: 0, -6: 1000}}),1001({1: 1697724754, -6: 873294, -7: {1: 0, -3: 1}}),1001({1: 1697724754, -6: 873294, -7: {1: 0.001}})Key -8 (Guarantee) can be used to represent a stated guarantee for theaccuracy of the point in time as a numeric value in seconds or as aduration (Section 4)representing the maximum allowed deviation from the true value.¶
While such a guarantee is unattainable in theory, existing standardssuch as[RFC3161] stipulate the representation of such guarantees,and therefore this format provides a way to represent them as well;the time value given is nominally guaranteed to not deviate from theactual time by more than the value of the guarantee in seconds.¶
Note that the additional information that can be meaningfully providedwith the duration that represents a guarantee is limited, e.g., it isnot meaningful to provide a guarantee of accuracy for the durationrepresenting a guarantee of accuracy.Implementations are free to reduce a guarantee (which is alreadyelective) to the information they can process.¶
Keys -10 and 10 supply supplementary information, where key 10 is critical.¶
They can be used to provide a hint about the time zone thatwould best fit for displaying the time given to humans, using a textstring in the format defined fortime-zone-name ortime-numoffsetin[RFC9557].Key -10 is equivalent to providing this information as an electivehint, while key 10 provides this information as critical (i.e., itMUST be used when interpreting the entry with this key).¶
Keys -10 and 10MUST NOT both be present.¶
$$ETIME-ELECTIVE //= (-10: time-zone-info)$$ETIME-CRITICAL //= (10: time-zone-info)time-zone-info = tstr .abnf ("time-zone-name / time-numoffset" .det IXDTFtz)IXDTFtz = ' time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-numoffset = ("+" / "-") time-hour ":" time-minute time-zone-initial = ALPHA / "." / "_" time-zone-char = time-zone-initial / DIGIT / "-" / "+" time-zone-part = time-zone-initial *time-zone-char ; but not "." or ".." time-zone-name = time-zone-part *("/" time-zone-part) ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9' ; extracted from [RFC9557] and [RFC3339]¶Keys -11 and 11 supply supplementary information, where key 11 is critical.¶
Similar to keys -10 and 10, keys -11 (elective) and 11 (critical) canbe used to provide additional information in the style of Internet Extended Date/Time Format (IXDTF)suffixes, such as the calendar that would best fit for displaying thetime given to humans.The key's value is a map that has IXDTFsuffix-key names as keys and corresponding suffix values as values, specifically:¶
$$ETIME-ELECTIVE //= (-11: suffix-info-map)$$ETIME-CRITICAL //= (11: suffix-info-map)suffix-info-map = { * suffix-key => suffix-values }suffix-key = tstr .abnf ("suffix-key" .det IXDTF)suffix-values = one-or-more<suffix-value>one-or-more<T> = T / [ 2* T ]suffix-value = tstr .abnf ("suffix-value" .det IXDTF)IXDTF = ' key-initial = lcalpha / "_" key-char = key-initial / DIGIT / "-" suffix-key = key-initial *key-char suffix-value = 1*alphanum alphanum = ALPHA / DIGIT lcalpha = %x61-7A ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9' ; extracted from [RFC9557]¶When keys -11 and 11 are both present, the two mapsMUST NOT haveentries with the same map keys.¶
Figure 4 of[RFC9557] gives an example for an extended date-time with both time zone and suffix information:¶
1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]¶
A time tag that is approximating this example, in CBOR diagnosticnotation, would be:¶
/ 1996-12-19T16:39:57-08:00[America//Los_Angeles][u-ca=hebrew] /1001({ 1: 851042397, -10: "America/Los_Angeles", -11: { "u-ca": "hebrew" }})¶Note that both -10 and -11 are using negative keys and thereforeprovide elective information, as in the IXDTF form given in the comment.Also note that, in this example, the time numeric offset (-08:00) islost in translating from the[RFC3339] information in the IXDTF into aPOSIX time that can be included under key 1 in a time tag.¶
A duration is the length of an interval of time.Durations in this format are given in International System of Units (SI) seconds, possibly adjustedfor conventional corrections of the timescale given (e.g., leapseconds).¶
Except for using tag 1002 instead of 1001,durations are structurally identical to time values.¶
Duration = #6.1002(etime-detailed)¶
Semantically, they do not measure the time elapsed from a given epochbut from the start to the end of an (otherwise unspecified) intervalof time.¶
In combination with an epoch identified in the context, a duration canalso be used to express an absolute time.¶
Without such context, durations are subject to some uncertaintiesunderlying the timescale used.For example, for durations intended as a determinant of future time periods,there is some uncertainty of what irregularities (such as leapseconds and timescale corrections) will be exhibited by the timescale inthat period.For durations as measurements of past periods, abstracting the periodto a duration loses some detail about timescale irregularities.For many applications, these uncertainties are acceptable and thusthe use of durations is appropriate.¶
Note that the durations defined in[ISO8601:1988] and[ISO8601-1:2019] are rather different from the ones definedin the present specification; there is no intention to support ISO 8601durations here.¶
A period is a specific interval of time, specified as either twoextended times giving the start and the end of that interval or asone of these two plus a duration.¶
This is represented as an array of unwrapped time and duration elements,tagged with tag 1003, one of:¶
a start and end time, in which case thetag content is an array of two unwrapped extended time elements, or¶
a start time with duration or an end time with duration.The tag content is an array of 3 elements: the first two asabove but either the start or end timeMUST be set to null and thethird one then is an unwrapped duration.¶
A simple CDDL definition that does not capture all the constraints is:¶
simple-Period = #6.1003([ start: ~Etime / null end: ~Etime / null ? duration: ~Duration])¶
Exactly two out of the three elements must be present and non-null;this can be somewhat more verbosely expressed in CDDL as:¶
Period = #6.1003([ (start: ~Etime, ((end: ~Etime) // (end: null, duration: ~Duration))) // (start: null, end: ~Etime, duration: ~Duration)])¶
When detailed validation is not needed, thetype names defined inFigure 5 are recommended:¶
etime = #6.1001({* (int/tstr) => any})duration = #6.1002({* (int/tstr) => any})period = #6.1003([~etime/null, ~etime/null, ?~duration])In the "CBOR Tags" registry[IANA.cbor-tags],IANA has allocated the tags inTable 2.¶
| Tag | Data Item | Semantics | Reference |
|---|---|---|---|
| 1001 | map | extended time | [RFC9581,Section 3] |
| 1002 | map | duration | [RFC9581,Section 4] |
| 1003 | array | period | [RFC9581,Section 5] |
IANA has updated the "Data Item" column for tag 1003 from"map" to "array".¶
Per this specification, IANA has created a new "Timescales" registry within the"Concise Binary Object Representation (CBOR) Tags" registry group[IANA.cbor-tags]. The registration procedure requires both "Expert Review" and "RFC Required" (Sections4.5 and4.7 of RFC 8126[BCP26], respectively).¶
Each entry needs to provide a timescale name (a sequence of uppercaseASCII characters and digits, where a digit may not occur at the start:[A-Z][A-Z0-9]*), a value (CBOR unsigned integer, uint,0..18446744073709551615), a brief descriptionof the semantics, and a specification reference (RFC).The initial contents are shown inTable 3.¶
| Timescale | Value | Semantics | Reference |
|---|---|---|---|
| UTC | 0 | UTC with POSIX Epoch | [RFC9581] |
| TAI | 1 | TAI with PTP Epoch | [RFC9581] |
Per this specification, IANA has created a new "Time Tag Map Keys" registry within the "Concise Binary Object Representation (CBOR) Tags" registry group[IANA.cbor-tags]. The registration procedure is "SpecificationRequired" (Section4.6 of RFC 8126[BCP26]).¶
The designated expert is requested to assign the key values with theshortest encodings (1+0 and 1+1 encoding) to registrations that arelikely to enjoy wide use and can benefit from short encodings.¶
Each entry needs to provide a map key value (CBOR integer, int,-18446744073709551616..18446744073709551615), a brief descriptionof the semantics, and a specification reference.Note that negative integers indicate an elective key, while unsignedintegers indicate a key that either provides a base time or iscritical. The designated expert is requested to discuss with the registrant whether or not it is desirable to register a pair of an elective and a critical key for the same information, where the elective key value is the negative of the critical key (similar to how for example -11 and 11 have been assigned inTable 4).For the unsigned integers as keys, the choice of base time or criticalneeds to be indicated in the brief semantics description.(Elective map keys may be explicitly marked as such in thedescription, e.g., to distinguish them from critical keys.)¶
The initial contents are shown inTable 4.¶
| Value | Semantics | Reference |
|---|---|---|
| -18 | attoseconds | [RFC9581] |
| -15 | femtoseconds | [RFC9581] |
| -13 | timescale (elective) | [RFC9581] |
| -12 | picoseconds | [RFC9581] |
| -11 | IXDTF Suffix Information (elective) | [RFC9581],[RFC9557] |
| -10 | IXDTF Time Zone Hint (elective) | [RFC9581],[RFC9557] |
| -9 | nanoseconds | [RFC9581] |
| -8 | Guarantee | [RFC9581] |
| -7 | Uncertainty | [RFC9581] |
| -6 | microseconds | [RFC9581] |
| -5 | Offset-Scaled Log Variance | [RFC9581] |
| -4 | Clock Accuracy | [RFC9581] |
| -3 | milliseconds | [RFC9581] |
| -2 | Clock Class | [RFC9581] |
| -1 | timescale (elective) legacy | [RFC9581] |
| 1 | base time value as in CBOR tag 1 | [RFC8949], [RFC9581] |
| 4 | base time value as in CBOR tag 4 | [RFC8949], [RFC9581] |
| 5 | base time value as in CBOR tag 5 | [RFC8949], [RFC9581] |
| 10 | IXDTF Time Zone Hint (critical) | [RFC9557], [RFC9581] |
| 11 | IXDTF Suffix Information (critical) | [RFC9557], [RFC9581] |
| 13 | timescale (critical) | [RFC9581] |
The security considerations of[RFC8949] apply; the tags introducedhere are not expected to raise security considerations beyond those.¶
Time, of course, has significant security considerations; theseinclude the exploitation of ambiguities where time is securityrelevant (e.g., for freshness or in a validity span) or the disclosureof characteristics of the emitting system (e.g., time zone or clockresolution and wall clock offset).¶
A more detailed discussion of security considerations emanating fromusing a representation of time that allows the inclusion of complex andpossibly inconsistent information is available in "Security Considerations"(Section 7 of [RFC9557]).¶
This appendix collects the CDDL rules spread over the document intoone convenient place.¶
Etime = #6.1001(etime-detailed)etime-framework = { uint => any ; at least one base time * (nint/text) => any ; elective supplementary information * uint => any ; critical supplementary information}etime-detailed = ({ $$ETIME-BASETIME ClockQuality-group * $$ETIME-ELECTIVE * $$ETIME-CRITICAL * ((nint/text) .feature "etime-elective-extension") => any * (uint .feature "etime-critical-extension") => any}) .within etime-framework$$ETIME-BASETIME //= (1: ~time)$$ETIME-BASETIME //= (4: ~decfrac)$$ETIME-BASETIME //= (5: ~bigfloat)$$ETIME-ELECTIVE //= (-3: uint)$$ETIME-ELECTIVE //= (-6: uint)$$ETIME-ELECTIVE //= (-9: uint)$$ETIME-ELECTIVE //= (-12: uint)$$ETIME-ELECTIVE //= (-15: uint)$$ETIME-ELECTIVE //= (-18: uint)$$ETIME-ELECTIVE //= (-1 => $ETIME-TIMESCALE)$$ETIME-ELECTIVE //= (-13 => $ETIME-TIMESCALE)$$ETIME-CRITICAL //= (13 => $ETIME-TIMESCALE)$ETIME-TIMESCALE /= &(etime-utc: 0)$ETIME-TIMESCALE /= &(etime-tai: 1)ClockQuality-group = ( ? &(ClockClass: -2) => uint .size 1 ; PTP/RFC8575 ? &(ClockAccuracy: -4) => uint .size 1 ; PTP/RFC8575 ? &(OffsetScaledLogVariance: -5) => uint .size 2 ; PTP/RFC8575 ? &(Uncertainty: -7) => ~time/~duration ? &(Guarantee: -8) => ~time/~duration)$$ETIME-ELECTIVE //= (-10: time-zone-info)$$ETIME-CRITICAL //= (10: time-zone-info)time-zone-info = tstr .abnf ("time-zone-name / time-numoffset" .det IXDTFtz)IXDTFtz = ' time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-numoffset = ("+" / "-") time-hour ":" time-minute time-zone-initial = ALPHA / "." / "_" time-zone-char = time-zone-initial / DIGIT / "-" / "+" time-zone-part = time-zone-initial *time-zone-char ; but not "." or ".." time-zone-name = time-zone-part *("/" time-zone-part) ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9' ; extracted from [RFC9557] and [RFC3339]$$ETIME-ELECTIVE //= (-11: suffix-info-map)$$ETIME-CRITICAL //= (11: suffix-info-map)suffix-info-map = { * suffix-key => suffix-values }suffix-key = tstr .abnf ("suffix-key" .det IXDTF)suffix-values = one-or-more<suffix-value>one-or-more<T> = T / [ 2* T ]suffix-value = tstr .abnf ("suffix-value" .det IXDTF)IXDTF = ' key-initial = lcalpha / "_" key-char = key-initial / DIGIT / "-" suffix-key = key-initial *key-char suffix-value = 1*alphanum alphanum = ALPHA / DIGIT lcalpha = %x61-7A ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9' ; extracted from [RFC9557]Duration = #6.1002(etime-detailed)simple-Period = #6.1003([ start: ~Etime / null end: ~Etime / null ? duration: ~Duration])Period = #6.1003([ (start: ~Etime, ((end: ~Etime) // (end: null, duration: ~Duration))) // (start: null, end: ~Etime, duration: ~Duration)])etime = #6.1001({* (int/tstr) => any})duration = #6.1002({* (int/tstr) => any})period = #6.1003([~etime/null, ~etime/null, ?~duration])The authors would like to acknowledge the many comments from membersof the CBOR WG,Francesca Palombini for her AD review,Thomas Fossati andQin Wu for their directorate reviews, andRohan Mahy for one more review late in the process.¶