Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 9581 Universität Bremen TZI
Category: Standards Track B. Gamari
ISSN: 2070-1721 Well-Typed
H. Birkholz
Fraunhofer SIT
August 2024
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
簡潔なバイナリオブジェクト表現（CBOR、RFC 8949）は、バージョンのネゴシエーションを必要とせずに、非常に小さなコードサイズ、かなり小さなメッセージサイズ、拡張性の可能性を設計目標にするデータ形式です。
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 tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. This document is intended as the reference document for the IANA registration of the CBOR tags defined.
CBORでは、拡張性の1つのポイントはCBORタグの定義です。RFC 8949時間の2つのタグを定義します。CBORタグ0（RFC 3339時間として文字列として）とタグ1（intまたはfloatとしてのposix時間）。それ以来、追加の要件が知られています。現在のドキュメントでは、時間のより精巧な表現を可能にするCBORタグと、期間と期間の関連するCBORタグを定義します。このドキュメントは、定義されたCBORタグのIANA登録のリファレンスドキュメントとして意図されています。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9581.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9581で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. Objectives
3. Time Format
3.1. Key 1
3.2. Keys 4 and 5
3.3. Keys -3, -6, -9, -12, -15, and -18
3.4. Keys -1, -13, and 13: Timescale
3.5. Clock Quality
3.5.1. ClockClass (Key -2)
3.5.2. ClockAccuracy (Key -4)
3.5.3. OffsetScaledLogVariance (Key -5)
3.5.4. Uncertainty (Key -7)
3.5.5. Guarantee (Key -8)
3.6. Keys -10, 10: Time Zone Hint
3.7. Keys -11, 11: IXDTF Suffix Information
4. Duration Format
5. Period Format
6. CDDL Type Names
7. IANA Considerations
7.1. CBOR Tags
7.2. Timescales Registry
7.3. Time Tag Map Keys Registry
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Collected CDDL
Acknowledgements
Authors' Addresses
The Concise Binary Object Representation (CBOR) [RFC8949] provides for the interchange of structured data without a requirement for a pre-agreed schema. RFC 8949 defines a basic set of data types, as well as a tagging mechanism that enables extending the set of data types supported via an IANA registry for CBOR tags (see [IANA.cbor-tags] and Section 9.2 of [RFC8949]).
簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]は、事前に合わせたスキーマを必要とせずに構造化されたデータの交換を提供します。RFC 8949は、基本的なデータ型セットと、CBORタグのIANAレジストリを介してサポートされるデータ型のセットを拡張できるタグ付けメカニズムを定義します（[RFC8949]の[iana.cbor-tags]およびセクション9.2を参照）。
RFC 8949 defines two tags for time: CBOR tag 0 ([RFC3339] time as a string) and tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for durations and time periods. This document is intended as the reference document for the IANA registration of the CBOR tags defined.
RFC 8949は、時間の2つのタグを定義します。CBORタグ0（[RFC3339]時間としての時間）とタグ1（intまたはfloatとしてのposix時間）。それ以来、追加の要件が知られています。現在のドキュメントでは、時間のより精巧な表現を可能にするCBORタグと、期間と期間に関連するCBORタグを定義します。このドキュメントは、定義されたCBORタグのIANA登録のリファレンスドキュメントとして意図されています。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The term "byte" is used in its now customary sense as a synonym for "octet".
「バイト」という用語は、「Octet」の同義語として、現在慣習的な意味で使用されています。
Superscript notation denotes exponentiation. For example, 2 to the power of 64 is notated: 2^64. In the plain-text rendition of this specification, superscript notation is not available and exponentiation is therefore rendered by the surrogate notation seen here in the plain-text rendition.
SuperScript表記は指数を示します。たとえば、64の電力への2が記録されています：2^64。この仕様のプレーンテキスト演出では、上付き文字表記は利用できないため、プレーンテキスト演出で見られる代理表記によって指数が表示されます。
CBOR diagnostic notation is defined in Section 8 of [RFC8949] and Appendix G of [RFC8610]. A machine-processable model of the data structures defined in this specification is provided throughout the text using the Concise Data Definition Language (CDDL) [RFC8610]; Appendix A provides the collected model information.
CBOR診断表記は、[RFC8949]のセクション8および[RFC8610]の付録Gで定義されています。この仕様で定義されたデータ構造の機械加工可能なモデルは、簡潔なデータ定義言語（CDDL）[RFC8610]を使用して、テキスト全体で提供されます。付録Aは、収集されたモデル情報を提供します。
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 direct use in Sections 3.6 and 3.7.
UTCや国際原子時間（TAI）などのいくつかの時間関連の用語は、[RFC9557]で説明されています。
For the time tag, the present specification addresses the following objectives that go beyond the original tags 0 and 1 (defined in Sections 3.4.1 and 3.4.2 of [RFC8949]):
時間タグについては、現在の仕様では、元のタグ0および1を超えて次の目的に対応しています（[RFC8949]のセクション3.4.1および3.4.2で定義されています）：
* 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 approximately microseconds at the time of writing (progressively becoming worse over time).
* エポックベースの時間の追加解像度（タグ1のように）。CBORタグ1は、整数としての時間の表現と、執筆時点で解像度を約マイクロ秒に制限するバイナリ64フローティングポイント値[IEEE754]としてのみを提供します（時間とともに徐々に悪化する）。
* Indication of timescale. Tags 0 and 1 are defined for UTC; however, some interchanges are better performed on TAI. Other timescales may be registered once they become relevant (e.g., one of the proposed successors to UTC that might no longer use leap seconds or a scale based on smeared leap seconds).
* タイムスケールの兆候。タグ0と1は、UTCに対して定義されています。ただし、いくつかのインターチェンジはTAIでより適切に実行されます。他のタイムスケールは、関連すると登録される場合があります（たとえば、UTCの提案された後継者の1つが、塗りつぶし速度に基づいて速度秒またはスケールを使用しなくなる可能性があります）。
By incorporating a way to transport [RFC9557] suffix information (see Sections 3.6 and 3.7), additional indications of intents about the interpretation of the time given can be provided; in particular, for instances of time that, at the time they are being described, are in the future. Intents might include information about time zones, daylight saving times, preferred calendar representations, etc.
[RFC9557]サフィックス情報を輸送する方法を組み込むことにより（セクション3.6および3.7を参照）、与えられた時間の解釈に関する意図の追加の兆候を提供できます。特に、それらが記述されている時点で、将来的にある時間の場合。意図には、タイムゾーン、夏時間の節約時間、好みのカレンダー表現などに関する情報が含まれる場合があります。
Semantics not covered by this document can be added by registering additional map keys for the map that is the content of the tag (see etime-detailed in Figure 1), the specification for which is referenced by the registry entry (see Section 3).
このドキュメントでカバーされていないセマンティクスは、タグのコンテンツであるマップの追加マップキーを登録することで追加できます（図1でETIME検出を参照）。レジストリエントリで参照される仕様（セクション3を参照）。
For example, map keys could be registered for direct representations of natural platform time formats. Some platforms use epoch-based time formats that require some computation to convert them into the representations allowed by tag 1; these computations can also lose precision and cause ambiguities. (The present specification does not take a position on whether tag 1 can be "fixed" to include, e.g., Decimal or Bigfloat representations. It does define how to use these representations with the extended time format.)
たとえば、マップキーは、自然なプラットフォーム時間形式の直接表現に登録できます。一部のプラットフォームでは、エポックベースの時間形式を使用して、タグ1で許可された表現に変換するためにいくらかの計算を必要とします。これらの計算は、精度を失い、あいまいさを引き起こす可能性があります。（現在の仕様では、タグ1を「固定」することができるかどうかについての位置を取得していません。たとえば、10進またはBigFloat表現を含めることができます。これらの表現を拡張時間形式で使用する方法を定義します。）
Additional tags are defined for durations and periods.
追加のタグは、期間と期間に対して定義されています。
An extended time is indicated by CBOR tag 1001, the content of which is a map data item (CBOR major type 5). The map may contain integer (major types 0 and 1) or text string (major type 3) keys, with the value type determined by each specific key. For negative integer keys and text string values of the key, implementations MUST ignore key/value pairs they do not understand; these keys are "elective", as the extended time as a whole is still usable without the information they carry if an implementation elects not to implement them. Conversely, implementations MUST signal an error when encountering key/value pairs that use unsigned integer keys they do not understand or implement (these are either "base time" or "critical", see below).
長時間はCborタグ1001で示され、その内容はマップデータ項目（CBORメジャータイプ5）です。マップには、整数（メジャータイプ0および1）またはテキスト文字列（メジャータイプ3）キーが含まれ、各特定のキーによって決定される値タイプが決まります。ネガティブな整数キーとキーのテキスト文字列値の場合、実装は理解できないキー/値のペアを無視する必要があります。これらのキーは「選択的」です。延長時間全体が、実装がそれらを実装しないことを選択した場合、彼らが携帯する情報なしにまだ使用可能であるためです。逆に、実装は、理解または実装されていない署名されていない整数キーを使用するキー/値のペアに遭遇したときにエラーを通知する必要があります（これらは「ベースタイム」または「クリティカル」のいずれかです。以下を参照）。
The map MUST contain exactly one unsigned integer key that specifies the "base time" and MAY also contain one or more negative integer or text-string keys, which may encode supplementary information.
マップには、「ベース時間」を指定する1つの署名されていない整数キーが1つ含まれている必要があります。また、補足情報をエンコードする場合がある1つ以上の負の整数またはテキストストリングキーも含まれている場合があります。
Supplementary information MAY also be provided by additional unsigned integer keys that are explicitly defined to provide supplementary information (we say these keys are defined to be "critical"); as these are required to be understood, there can be no confusion with base time keys.
補足情報は、補足情報を提供するために明示的に定義されている追加の署名されていない整数キーによっても提供される場合があります（これらのキーは「クリティカル」であると定義されていると言います）。これらを理解する必要があるため、ベースタイムキーと混乱することはできません。
Negative integer and text string keys always supply supplementary information (they are "elective", and this will not be explicitly stated below).
負の整数とテキスト文字列キーは常に補足情報を提供します（それらは「選択的」であり、これは以下に明示的に記載されていません）。
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
* デフォルトのUTCおよび1970-01-01とは異なるリファレンスタイムスケールとエポックと
* 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.
追加のキーは、「タイムタグマップキー」レジストリ（セクション7.3）に登録することで定義できます。たとえば、登録キーは、タイムゾーン、夏時間の節約時間、および/または位置決め座標などの意図情報を追加して、現地時間を示す情報を表現する場合があります。
This document does not define supplementary text keys. A number of both unsigned and negative-integer keys are defined in the following subsections.
このドキュメントは、補足テキストキーを定義しません。以下のサブセクションでは、署名されていないキーと否定的なキーの両方が定義されています。
Figure 1 provides a formal definition of tag 1001 in CDDL.
図1は、CDDLのタグ1001の正式な定義を示しています。
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
Figure 1: CDDL Definition of Tag 1001
図1：タグ1001のCDDL定義
Key 1 indicates a base time value that is exactly like the data item that would be tagged by CBOR tag 1 (POSIX time [TIME_T] as int or float). As described above, the time value indicated by the value under this key can be further modified by other keys.
キー1は、Cborタグ1（posix time [time_t]がintまたはfloat）でタグ付けされるデータ項目とまったく同じような基本時間値を示します。上記のように、このキーの下の値で示される時間値は、他のキーによってさらに変更できます。
$$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 as defined 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 to avoid rounding errors.
キー4と5は、基本時間値を示し、キー1のようなものです。ただし、データ項目は、それぞれCborタグ4または5で定義されている配列です。これを使用して、10進数またはBigFloat Epochベースのフロート[Time_t]を長時間に含めることができます。たとえば、より高い解像度を達成したり、丸めエラーを回避したりします。
$$ETIME-BASETIME //= (4: ~decfrac)
$$ETIME-BASETIME //= (5: ~bigfloat)
The keys -3, -6, -9, -12, -15, and -18 indicate additional decimal fractions by giving an unsigned integer (major type 0) and scaling this with the scale factor 1e-3, 1e-6, 1e-9, 1e-12, 1e-15, and 1e-18, respectively (see Table 1). Each extended time data item MUST NOT contain more than one of these keys. These additional fractions are added to a base time in seconds [SI-SECOND] indicated by key 1, which then MUST also be present and MUST have an integer value.
キー-3、-6、-9、-12、-15、および-18は、符号なし整数（メジャータイプ0）を与え、スケール係数1E -3、1E -6、1Eでこれをスケーリングすることにより、追加の小数画分を示しています。-9、1E-12、1E-15、および1E-18、それぞれ（表1を参照）。各拡張時間データ項目は、これらのキーを複数搭載してはなりません。これらの追加の画分は、キー1で示される秒[Si-second]でベースタイムに追加されます。これも存在する必要があり、整数値が必要です。
+=====+==============+=================+
| 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) |
+-----+--------------+-----------------+
Table 1: Keys for Decimally Scaled Fractions
表1：細かくスケーリングされた画分のキー
$$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 representing pairs of the form second/decimal fraction of a second, as found for instance in C timespec (Section 7.27.1 of [C]). When ingesting a timestamp with one of these keys into a type provided by the target platform, care has to be taken to meet its invariants. For example, for C timespec, the fractional part tv_nsec needs to be between 0 inclusive and 10^9 exclusive, which can be achieved by also adjusting the base time appropriately.
これらのキーは、たとえばC TimesPec（[c]のセクション7.27.1）で見つかったように、フォームの2番目の小数/小数のペアを容易にするために提供されていることに注意してください。これらのキーのいずれかを使用してタイムスタンプをターゲットプラットフォームによって提供されるタイプに摂取する場合、その侵害を満たすために注意する必要があります。たとえば、C TimesPecの場合、分数パーツTV_NSECは0インクルーシブから10^9の排他的である必要があります。これは、ベース時間を適切に調整することで達成できます。
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 item MUST NOT contain more than one of these keys.
キー-1、-13、および13は、キー13が重要なタイムスケールを示すために使用されます。キー-1と-13には同一のセマンティクスがあります（両方ともキー-1が最初に選択されたために割り当てられ、次にキー13が追加されると、負の等価性があることが望ましいと思われます）。各拡張時間データ項目は、これらのキーを複数搭載してはなりません。
The value 0 indicates UTC, with the POSIX epoch [TIME_T]; the value 1 indicates TAI, with the Precision Time Protocol (PTP) epoch (1 January 1970 00:00:00 TAI, see [IEEE1588-2019] or [IEEE1588-2008]).
値0はUTCを示し、POSIXエポック[time_t];値1はTAIを示し、精密時間プロトコル（PTP）エポック（1970年1月1日00:00:00 TAI、[IEEE1588-2019]または[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.
キーが存在しない場合、デフォルトのタイムスケール値0が暗示されています。
Timescale values MUST be unsigned integers or text strings; text strings are provided for experimentation and MUST NOT be used between parties that 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.)
タイムスケール値は、署名されていない整数またはテキスト文字列でなければなりません。テキスト文字列は実験用に提供されており、実験の両方ではないパーティー間で使用してはなりません。追加の署名されていない整数値は、「タイムスケール」レジストリ（セクション7.2）に登録できます。（タイムスケール「GPS」または「NTP」[RFC5905]はないはずであることに注意してください。代わりに、単一の追加または減算を使用して時間をTAIまたはUTCに変換する必要があります。）
t = t - 2208988800
utc ntp
t = t + 315964819
tai gps
Figure 2: Converting Common Offset Timescales
図2：一般的なオフセットタイムスケールの変換
Editor's note: This initial set of timescales was deliberately chosen to be frugal, as the specification of the tag provides an extension point where additional timescales can be registered at any time. Registrations are clearly needed for earth-referenced timescales (such as UT1 and TT), as well as possibly for specific realizations of abstract timescales (such as TAI(USNO), the specific realization obtained at the United States Naval Observatory, which is more accurate as a constant offset basis for GPS times). While the registration process itself is trivial, these registrations need to be made based on a solid specification of their actual definition.
編集者注：この最初のタイムスケールのセットは、タグの仕様にはいつでも追加のタイムスケールを登録できる拡張ポイントを提供するため、意図的に質素になるように意図的に選択されました。登録は、地球参照のタイムスケール（UT1やTTなど）、およびおそらく抽象的なタイムスケール（TAI（USNOなど）の特定の実現に明らかに必要です。GPS時間の一定のオフセットベースとして）。登録プロセス自体は簡単ですが、これらの登録は、実際の定義のしっかりした仕様に基づいて行う必要があります。
A number of keys are defined to indicate the quality of the clock that was used to determine the point in time.
時点を決定するために使用された時計の品質を示すために、多くのキーが定義されています。
The first three are analogous to clock-quality-grouping in [RFC8575], which is in turn based on the definitions in [IEEE1588-2008]; the last two are specific to this document.
最初の3つは、[RFC8575]のクロック品質グループに類似しており、[IEEE1588-2008]の定義に基づいています。最後の2つはこのドキュメントに固有です。
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 range defined in IEEE 1588.
キー-2（ClockClass）を使用して、[RFC8575]（[IEEE1588-2008]のセクション7.6.2.4の表5に基づいています。[IEEE1588-2019のセクション7.6.2.5の表4）]言語を更新しました）。IEEE 1588で定義されている範囲であるため、1バイトの符号なし整数として定義されます。
Key -4 (ClockAccuracy) can be used to indicate the clock accuracy as per [RFC8575] (which is based on Table 6 in Section 7.6.2.5 of [IEEE1588-2008]; additional values have been defined in Table 5 in Section 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 scale from 1 ps to 1 s in [IEEE1588-2019] (in [IEEE1588-2008], the range was a subset of that, 32 to 47 for 25 ns to 1 s) -- see Figure 3; the number 254 is the value to be used if an unknown accuracy needs to be expressed.
キー-4（clockaccuracy）を使用して、[RFC8575]に従ってクロックの精度を示すことができます（これは[IEEE1588-2008]のセクション7.6.2.5の表6に基づいています。追加値は、セクション7.6の表5に定義されています。[IEEE1588-2019]の2.6]）。それはそこで定義されている範囲であるため、1バイトの符号なし整数として定義されます。23〜47の範囲は、[IEEE1588-2019]の1 psから1秒までのわずかに歪んだ対数スケールです（[IEEE1588-2008]では、その範囲はその範囲で、25 nsから1秒で32から47で47から47でした）- 図3を参照してください。数字254は、未知の精度を表す必要がある場合に使用する値です。
acc
enum ≈ 48 + ⌊2 ⋅log ──── - ε⌋
acc 10 s
Figure 3: Approximate Conversion from Accuracy to Accuracy Enumeration Value
図3：精度から精度の列挙値への近似変換
Key -5 (OffsetScaledLogVariance) can be used to represent the variance exhibited by the clock when it has lost its synchronization with an external reference clock. The details for the computation of this characteristic are defined in Section 7.6.3 of [IEEE1588-2019] and the same section in [IEEE1588-2008].
キー-5（offsetscaledlogvariance）を使用して、外部参照クロックとの同期を失ったときに時計が示す分散を表すことができます。この特性の計算の詳細は、[IEEE1588-2019]のセクション7.6.3および[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).
キー-7（不確実性）を使用して、数秒または期間として数値として、クロックの測定の既知の不確実性を表すことができます（セクション4）。
For this document, uncertainty is defined as in Section 2.2.3 of [GUM]: "parameter, associated with the result of a measurement, that characterizes the dispersion of the values that could reasonably be attributed to the measurand". More specifically, the value for this key represents the expanded uncertainty for k = 2 (Section 6.2.1 of [GUM]) in seconds.
このドキュメントでは、[ガム]のセクション2.2.3のように不確実性が定義されます。「測定の結果に関連するパラメーターは、測定値に合理的に起因する値の分散を特徴付けます」。より具体的には、このキーの値は、数秒でk = 2（[ガム]のセクション6.2.1）の拡大された不確実性を表します。
Note that the additional information that can be meaningfully provided with the duration that represents an uncertainty is limited, e.g., it is not customary to provide an uncertainty for a duration representing an uncertainty. Implementations are free to reduce the information contained in an uncertainty (which is already elective) to the information they can process.
不確実性を表す期間で有意義に提供できる追加情報は限られていることに注意してください。たとえば、不確実性を表す期間、不確実性を提供することは慣習ではありません。実装は、処理できる情報に対して不確実性（すでに選択的）に含まれる情報を自由に削減できます。
For example, a timestamp that is given to a resolution of 10^-6 seconds (microseconds) but only has an uncertainty of 10^-3 seconds (milliseconds) could be expressed by one of the extended time tags in Figure 4 (note the slight rounding error in the third case, which is probably inconsequential for an uncertainty value):
たとえば、10^-6秒（マイクロ秒）の解像度に与えられるが、10^-3秒（ミリ秒）の不確実性しか与えられていないタイムスタンプは、図4の延長されたタイムタグの1つによって表現できます（注意3番目のケースでのわずかな丸めエラー。これは、おそらく不確実性の値には取るに足らないものです）：
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}})
Figure 4: Examples Using Uncertainty
図4：不確実性を使用した例
Key -8 (Guarantee) can be used to represent a stated guarantee for the accuracy of the point in time as a numeric value in seconds or as a duration (Section 4) representing the maximum allowed deviation from the true value.
キー-8（保証）を使用して、秒単位の数値として、または真の値からの最大許容偏差を表す期間（セクション4）としての時点の精度の定められた保証を表すことができます。
While such a guarantee is unattainable in theory, existing standards such 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 the actual time by more than the value of the guarantee in seconds.
このような保証は理論的には達成できませんが、[RFC3161]などの既存の標準はそのような保証の表現を規定しているため、この形式はそれらを表現する方法を提供します。指定された時間値は、数秒で保証の値を超えて実際の時間から逸脱しないことが名目上保証されています。
Note that the additional information that can be meaningfully provided with the duration that represents a guarantee is limited, e.g., it is not meaningful to provide a guarantee of accuracy for the duration representing a guarantee of accuracy. Implementations are free to reduce a guarantee (which is already elective) to the information they can process.
保証を表す期間で有意義に提供できる追加情報は制限されていることに注意してください。たとえば、精度の保証を表す期間の精度の保証を提供することは意味がないことに注意してください。実装は、処理できる情報に対する保証（すでに選択的）を自由に削減できます。
Keys -10 and 10 supply supplementary information, where key 10 is critical.
キー-10および10は、キー10が重要な補足情報を供給します。
They can be used to provide a hint about the time zone that would best fit for displaying the time given to humans, using a text string in the format defined for time-zone-name or time-numoffset in [RFC9557]. Key -10 is equivalent to providing this information as an elective hint, while key 10 provides this information as critical (i.e., it MUST be used when interpreting the entry with this key).
[RFC9557]のTime-Zone-NameまたはTime-Numoffsetで定義された形式のテキスト文字列を使用して、人間に与えられた時間を表示するのに最適なタイムゾーンに関するヒントを提供するために使用できます。Key -10は、この情報を選択的ヒントとして提供することに相当しますが、Key 10はこの情報を重要なものとして提供します（つまり、このキーでエントリを解釈するときは使用する必要があります）。
Keys -10 and 10 MUST NOT both be present.
キー-10と10の両方が存在してはなりません。
$$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.
キー-11および11は、キー11が重要な補足情報を供給します。
Similar to keys -10 and 10, keys -11 (elective) and 11 (critical) can be 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 the time given to humans. The key's value is a map that has IXDTF suffix-key names as keys and corresponding suffix values as values, specifically:
キー-10と10と同様に、キー-11（選択科目）および11（クリティカル）を使用して、インターネットのスタイルのスタイルで追加情報を提供できます。人間に与えられた時間を表示します。キーの値は、キーとしてIXDTFの接尾辞key名を持ち、特に次のように対応する接尾辞値を持つマップです。
$$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 maps MUST NOT have entries with the same map keys.
キー-11と11の両方が存在する場合、2つのマップには同じマップキーを持つエントリが必要です。
Figure 4 of [RFC9557] gives an example for an extended date-time with both time zone and suffix information:
[RFC9557]の図4は、タイムゾーンとサフィックス情報の両方を備えた延長日付の例を示しています。
1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
A time tag that is approximating this example, in CBOR diagnostic notation, would be:
この例に近似しているタイムタグは、CBOR診断表記で、次のとおりです。
/ 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 therefore provide elective information, as in the IXDTF form given in the comment. Also note that, in this example, the time numeric offset (-08:00) is lost in translating from the [RFC3339] information in the IXDTF into a POSIX time that can be included under key 1 in a time tag.
-10と-11の両方がネガティブキーを使用しているため、コメントに記載されているIXDTF形式のように、選択情報を提供していることに注意してください。また、この例では、IXDTFの[RFC3339]情報からの翻訳では、時間タグのキー1に含まれるPOSIX時間に翻訳する際に、時間数のオフセット（-08：00）が失われることに注意してください。
A duration is the length of an interval of time. Durations in this format are given in International System of Units (SI) seconds, possibly adjusted for conventional corrections of the timescale given (e.g., leap seconds).
期間とは、時間間隔の長さです。この形式の期間は、国際ユニット（SI）秒で与えられ、指定されたタイムスケールの従来の補正のために調整される可能性があります（例：LEAP秒）。
Except for using tag 1002 instead of 1001, durations are structurally identical to time values.
1001の代わりにタグ1002を使用することを除き、期間は時間値と構造的に同一です。
Duration = #6.1002(etime-detailed)
Semantically, they do not measure the time elapsed from a given epoch but from the start to the end of an (otherwise unspecified) interval of time.
意味的には、特定のエポックからの経過時間を測定するのではなく、時間の（そうでなければ不特定の）間隔の最初から終わりまで測定します。
In combination with an epoch identified in the context, a duration can also be used to express an absolute time.
コンテキストで特定されたエポックと組み合わせて、絶対時間を表現するために期間を使用することもできます。
Without such context, durations are subject to some uncertainties underlying the timescale used. For example, for durations intended as a determinant of future time periods, there is some uncertainty of what irregularities (such as leap seconds and timescale corrections) will be exhibited by the timescale in that period. For durations as measurements of past periods, abstracting the period to a duration loses some detail about timescale irregularities. For many applications, these uncertainties are acceptable and thus the use of durations is appropriate.
そのような文脈がなければ、使用されるタイムスケールの根底にあるいくつかの不確実性の対象となります。たとえば、将来の期間の決定要因として意図された期間では、その期間のタイムスケールによってどのような不規則性（跳躍やタイムスケールの修正など）が示されるかについての不確実性があります。過去の期間の測定としての期間の場合、期間を抽象化すると、タイムスケールの不規則性に関する詳細が失われます。多くのアプリケーションでは、これらの不確実性が許容されるため、期間の使用が適切です。
Note that the durations defined in [ISO8601:1988] and [ISO8601-1:2019] are rather different from the ones defined in the present specification; there is no intention to support ISO 8601 durations here.
[ISO8601：1988]および[ISO8601-1：2019]で定義されている期間は、現在の仕様で定義されている期間とはかなり異なることに注意してください。ここでISO 8601期間をサポートするつもりはありません。
A period is a specific interval of time, specified as either two extended times giving the start and the end of that interval or as one of these two plus a duration.
期間は特定の時間間隔であり、その間隔の開始と終了を与える2つの延長時間として指定されているか、これら2つの1つ以上の期間として指定されます。
This is represented as an array of unwrapped time and duration elements, tagged with tag 1003, one of:
これは、タグ1003でタグ付けされた、包装されていない時間と期間の要素の配列として表されます。
* a start and end time, in which case the tag content is an array of two unwrapped extended time elements, or
* 開始時間と終了時間、その場合、タグコンテンツは2つの包装されていない拡張時間要素の配列です。
* a start time with duration or an end time with duration. The tag content is an array of 3 elements: the first two as above but either the start or end time MUST be set to null and the third one then is an unwrapped duration.
* 期間の開始時間または期間の終了時間。タグコンテンツは3つの要素の配列です。上記の最初の2つですが、開始時間または終了時間をnullに設定する必要があり、3番目の時間は包装されていません。
A simple CDDL definition that does not capture all the constraints is:
すべての制約をキャプチャしない単純なCDDL定義は次のとおりです。
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:
3つの要素のうち正確な2つが存在し、非ヌルでなければなりません。これは、CDDLで次のように多少冗長に表現される可能性があります。
Period = #6.1003([
(start: ~Etime,
((end: ~Etime) //
(end: null,
duration: ~Duration))) //
(start: null,
end: ~Etime,
duration: ~Duration)
])
When detailed validation is not needed, the type names defined in Figure 5 are recommended:
詳細な検証が必要ない場合、図5に定義されているタイプ名が推奨されます。
etime = #6.1001({* (int/tstr) => any})
duration = #6.1002({* (int/tstr) => any})
period = #6.1003([~etime/null, ~etime/null, ?~duration])
Figure 5: Recommended Type Names for CDDL
図5：CDDLの推奨タイプ名
In the "CBOR Tags" registry [IANA.cbor-tags], IANA has allocated the tags in Table 2.
「CBORタグ」レジストリ[IANA.CBOR-TAGS]では、IANAは表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] |
+------+-----------+---------------+----------------------+
Table 2: Values for Tags
表2：タグの値
IANA has updated the "Data Item" column for tag 1003 from "map" to "array".
IANAは、「マップ」から「アレイ」にタグ1003の「データ項目」列を更新しました。
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" (Sections 4.5 and 4.7 of RFC 8126 [BCP26], respectively).
この仕様に従って、IANAは「Conscise Binary Object Adplissation（CBOR）タグ」レジストリグループ[IANA.CBOR-TAGS]内に新しい「タイムスケール」レジストリを作成しました。登録手順には、「専門家のレビュー」と「RFC要求」の両方が必要です（それぞれRFC 8126 [BCP26]のセクション4.5と4.7）。
Each entry needs to provide a timescale name (a sequence of uppercase ASCII 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 description of the semantics, and a specification reference (RFC). The initial contents are shown in Table 3.
各エントリは、タイムスケール名（大文字のASCII文字と数字のシーケンスを提供する必要があります。ここでは、最初に数字が発生しない場合があります：[a-z] [a-z0-9]*）、値（cbor unsigned integer、uint、0..18446744073709551615）、セマンティクスの簡単な説明と仕様参照（RFC）。初期内容を表3に示します。
+===========+=======+======================+===========+
| Timescale | Value | Semantics | Reference |
+===========+=======+======================+===========+
| UTC | 0 | UTC with POSIX Epoch | [RFC9581] |
+-----------+-------+----------------------+-----------+
| TAI | 1 | TAI with PTP Epoch | [RFC9581] |
+-----------+-------+----------------------+-----------+
Table 3: Initial Content of Timescale Registry
表3：タイムスケールレジストリの初期内容
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 "Specification Required" (Section 4.6 of RFC 8126 [BCP26]).
この仕様に従って、IANAは、「Concise Binary Object Lexpressation（CBOR）タグ」レジストリグループ[IANA.CBOR-TAGS]内に新しい「Time Tag Map Keys」レジストリを作成しました。登録手順は「必要な仕様」です（RFC 8126 [BCP26]のセクション4.6）。
The designated expert is requested to assign the key values with the shortest encodings (1+0 and 1+1 encoding) to registrations that are likely to enjoy wide use and can benefit from short encodings.
指定された専門家は、幅広い使用を享受する可能性が高く、短いエンコーディングの恩恵を受ける可能性のある登録に、最短のエンコーディング（1+0および1+1エンコード）を持つキー値を割り当てるように要求されます。
Each entry needs to provide a map key value (CBOR integer, int, -18446744073709551616..18446744073709551615), a brief description of the semantics, and a specification reference. Note that negative integers indicate an elective key, while unsigned integers indicate a key that either provides a base time or is critical. 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 in Table 4). For the unsigned integers as keys, the choice of base time or critical needs to be indicated in the brief semantics description. (Elective map keys may be explicitly marked as such in the description, e.g., to distinguish them from critical keys.)
各エントリは、マップキー値（Cbor Integer、Int、-184467444073709551616..184467444073709551615）、セマンティクスの簡単な説明、および仕様参照を提供する必要があります。負の整数は選択的キーを示すことに注意してください。一方、署名されていない整数は、基本時間を提供するか、重要であるキーを示します。指定された専門家は、選択的キー値が批判的キーのネガティブである場合、同じ情報の選択的キーと重要なキーのペアを登録することが望ましいかどうか登録者と話し合うように要求されます（たとえば、方法と同様です-11と11は表4に割り当てられています）。キーとして署名されていない整数の場合、簡単なセマンティクスの説明では、基本時間または重要な重要な必要があります。（選択的マップキーは、記述でそのように明示的にマークされる場合があります。たとえば、それらを重要なキーと区別するためです。）
The initial contents are shown in Table 4.
初期内容を表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] |
+-------+-------------------------------------+------------+
Table 4: Initial Content of Time Tag Map Keys Registry
表4：タイムタグマップキーレジストリの初期内容
The security considerations of [RFC8949] apply; the tags introduced here are not expected to raise security considerations beyond those.
[RFC8949]のセキュリティ上の考慮事項が適用されます。ここで導入されたタグは、それらを超えてセキュリティ上の考慮事項を提起することは期待されていません。
Time, of course, has significant security considerations; these include the exploitation of ambiguities where time is security relevant (e.g., for freshness or in a validity span) or the disclosure of characteristics of the emitting system (e.g., time zone or clock resolution and wall clock offset).
もちろん、時間には重大なセキュリティ上の考慮事項があります。これらには、時間がセキュリティに関連する曖昧さの悪用（鮮度や有効性の範囲など）またはエミッティングシステムの特性の開示（例：タイムゾーンまたはクロック解像度と壁の時計オフセット）の開示が含まれます。
A more detailed discussion of security considerations emanating from using a representation of time that allows the inclusion of complex and possibly inconsistent information is available in "Security Considerations" (Section 7 of [RFC9557]).
複雑な情報とおそらく一貫性のない情報を含めることを可能にする時間の表現を使用することから生じるセキュリティに関する考慮事項のより詳細な議論は、「セキュリティに関する考慮事項」（[RFC9557]のセクション7）で利用できます。
[BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:
Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[GUM] Joint Committee for Guides in Metrology, "Evaluation of
measurement data -- Guide to the expression of uncertainty
in measurement", JCGM 100:2008, September 2008,
<https://www.bipm.org/en/publications/guides/gum.html>.
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.
[IEEE1588-2008]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE 1588-2008, July 2008,
<https://standards.ieee.org/ieee/1588/4355/>. Often
called PTP v2, as it replaced the earlier 2002 version of
this standard by a non-backwards compatible protocol.
[IEEE1588-2019]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE 1588-2019, June 2020,
<https://standards.ieee.org/ieee/1588/6825/>. Often
called PTP v2.1, as it has been designed so it can be used
in a way that is fully backwards compatible to
IEEE1588-2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8575] Jiang, Y., Ed., Liu, X., Xu, J., and R. Cummings, Ed.,
"YANG Data Model for the Precision Time Protocol (PTP)",
RFC 8575, DOI 10.17487/RFC8575, May 2019,
<https://www.rfc-editor.org/info/rfc8575>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[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>.
[RFC9557] Sharma, U. and C. Bormann, "Date and Time on the Internet:
Timestamps with Additional Information", RFC 9557,
DOI 10.17487/RFC9557, April 2024,
<https://www.rfc-editor.org/info/rfc9557>.
[SI-SECOND]
ISO, "Quantities and units -- Part 3: Space and time",
ISO 80000-3:2019, October 2019,
<https://www.iso.org/standard/64974.html>.
[TIME_T] IEEE, "The Open Group Base Specifications Issue 7",
Section 4.16 Seconds Since the Epoch, IEEE
Std 1003.1-2017, 2018,
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
V1_chap04.html#tag_04_16>.
[C] ISO, "Information technology -- Programming languages --
C", Fourth Edition, ISO/IEC 9899:2018, June 2018,
<https://www.iso.org/standard/74528.html>. Contents
available via <https://www.open-
std.org/jtc1/sc22/wg14/www/docs/n2310.pdf>
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic",
IEEE 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July
2019, <https://ieeexplore.ieee.org/document/8766229>.
[ISO8601-1:2019]
ISO, "Date and time -- Representations for information
interchange -- Part 1: Basic rules", ISO 8601-1:2019,
February 2019, <https://www.iso.org/standard/70907.html>.
[ISO8601:1988]
ISO, "Data elements and interchange formats -- Information
interchange -- Representation of dates and times",
ISO 8601:1988, June 1988,
<https://www.iso.org/standard/15903.html>. Also available
from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/
fipspub4-1-1991.pdf
(https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/
fipspub4-1-1991.pdf)>.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://www.rfc-editor.org/info/rfc3161>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
This appendix collects the CDDL rules spread over the document into one convenient place.
この付録は、ドキュメント上に広がったCDDLルールを1つの便利な場所に収集します。
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])
Figure 6: Collected CDDL Rules from This Specification
図6：この仕様から収集されたCDDLルール
The authors would like to acknowledge the many comments from members of the CBOR WG, Francesca Palombini for her AD review, Thomas Fossati and Qin Wu for their directorate reviews, and Rohan Mahy for one more review late in the process.
著者は、CBOR WGのメンバー、彼女の広告レビューのためにフランチェスカパロンビニ、監督レビューのためにトーマスフォッサティとQin Wu、およびプロセスの後半でもう1回のレビューのために多くのコメントを認めたいと思います。
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Ben Gamari
Well-Typed
117 Middle Rd.
Portsmouth, NH 03801
United States of America
Email: ben@well-typed.com
Henk Birkholz
Fraunhofer Institute for Secure Information Technology
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@ietf.contact