[要約] RFC 9165は、Concise Data Definition Language (CDDL) に追加の制御演算子を導入するもので、データ構造のより詳細な定義と検証を可能にします。この拡張は、複雑なデータフォーマットの仕様を簡潔に記述することを目的としており、IoTデバイスや通信プロトコルなど、さまざまな技術分野での利用が想定されています。
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 9165 Universität Bremen TZI
Category: Standards Track December 2021
ISSN: 2070-1721
Additional Control Operators for the Concise Data Definition Language (CDDL)
簡潔なデータ定義言語の追加制御演算子（CDDL）
Abstract
概要
The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point.
RFC 8610で標準化された簡潔なデータ定義言語（CDDL）は、「制御演算子」を主言語拡張ポイントとして提供します。
The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: .plus, .cat, and .det for the construction of constants; .abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and .feature for indicating the use of a non-basic feature in an instance.
本文書は、RFC 8610が完了した時点でまだ準備ができていなかったいくつかの制御演算子を定義しています。CDDL仕様におけるABNF（RFC 5234およびRFC 7405）を含むための.ABNF / .ABNFB。そして、インスタンス内の非基本的な機能の使用を示すための機能。
Status of This Memo
本文書の位置付け
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/rfc9165.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9165で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Terminology
2. Computed Literals
2.1. Numeric Addition
2.2. String Concatenation
2.3. String Concatenation with Dedenting
3. Embedded ABNF
4. Features
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Author's Address
The Concise Data Definition Language (CDDL), standardized in [RFC8610], provides "control operators" as its main language extension point (Section 3.8 of [RFC8610]).
[RFC8610]で標準化された簡潔なデータ定義言語（CDDL）は、「制御演算子」を主言語拡張ポイントとして提供します（[RFC8610]のセクション3.8）。
The present document defines a number of control operators that were not yet ready at the time [RFC8610] was completed:
本文書は、時刻[RFC8610]が完了した時点でまだ準備ができていなかったいくつかの制御演算子を定義しています。
+==========+==================================================+
| Name | Purpose |
+==========+==================================================+
| .plus | Numeric addition |
+----------+--------------------------------------------------+
| .cat | String concatenation |
+----------+--------------------------------------------------+
| .det | String concatenation, pre-dedenting |
+----------+--------------------------------------------------+
| .abnf | ABNF in CDDL (text strings) |
+----------+--------------------------------------------------+
| .abnfb | ABNF in CDDL (byte strings) |
+----------+--------------------------------------------------+
| .feature | Indicates name of feature used (extension point) |
+----------+--------------------------------------------------+
Table 1: New Control Operators in this Document
表1：この文書の新しい制御演算子
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This specification uses terminology from [RFC8610]. In particular, with respect to control operators, "target" refers to the left-hand side operand and "controller" to the right-hand side operand. "Tool" refers to tools along the lines of that described in Appendix F of [RFC8610]. Note also that the data model underlying CDDL provides for text strings as well as byte strings as two separate types, which are then collectively referred to as "strings".
この仕様は[RFC8610]からの用語を使用しています。特に、制御演算子に関しては、「ターゲット」とは、左側のオペランドおよび右側のオペランドへの「コントローラ」を指す。「ツール」とは、[RFC8610]の付録Fで説明されているものの行に沿ったツールを指します。CDDLの基礎となるデータモデルは、テキスト文字列とバイト文字列を2つの別々の型として提供することにも注意してください。これは、まとめて「文字列」と呼ばれます。
The term "ABNF" in this specification stands for the combination of [RFC5234] and [RFC7405]; i.e., the ABNF control operators defined by this document allow use of the case-sensitive extensions defined in [RFC7405].
本明細書における「ABNF」という用語は、[RFC5234]と[RFC7405]の組み合わせを表しています。すなわち、この文書によって定義されたABNF制御演算子は、[RFC7405]で定義された大文字と小文字を区別する拡張機能を使用することを可能にします。
CDDL as defined in [RFC8610] does not have any mechanisms to compute literals. To cover a large part of the use cases, this specification adds three control operators: .plus for numeric addition, .cat for string concatenation, and .det for string concatenation with dedenting of both sides (target and controller).
[RFC8610]で定義されているCDDLには、リテラルを計算するメカニズムはありません。ユースケースの大部分をカバーするために、この仕様は3つの制御演算子を追加します。数値追加のための.plus、文字列連結のための.cat、および両側の専用（ターゲットとコントローラ）を備えた文字列連結のための.det。
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つのタイプの粗生成物の要素の関数である。すべてのツールが固有のターゲットまたはコントローラを操作できる可能性があります。
In many cases, numbers are needed relative to a base number in a specification. The .plus control identifies a number that is constructed by adding the numeric values of the target and the controller.
多くの場合、仕様内の基本番号に対して数値が必要です。.plusコントロールは、ターゲットとコントローラの数値を追加して構築された番号を識別します。
The target and controller both MUST be numeric. If the target is a floating point number and the controller an integer number, or vice versa, the sum is converted into the type of the target; converting from a floating point number to an integer selects its floor (the largest integer less than or equal to the floating point number, i.e., rounding towards negative infinity).
ターゲットとコントローラの両方が数値でなければなりません。ターゲットが浮動小数点数とコントローラの場合、またはその逆の場合、合計はターゲットの型に変換されます。浮動小数点数から整数への変換は、その階（浮動小数点数以下、すなわち負の無限大に丸める最大整数）を選択する。
interval<BASE> = (
BASE => int ; lower bound
(BASE .plus 1) => int ; upper bound
? (BASE .plus 2) => int ; tolerance
)
X = 0
Y = 3
rect = {
interval<X>
interval<Y>
}
Figure 1: An Example of Addition to a Base Value
図1：基本値への追加例
The example in Figure 1 contains the generic definition of a CDDL group interval that gives a lower and upper bound and, optionally, a tolerance. The parameter BASE allows the non-conflicting use of a multiple of these interval groups in one map by assigning different labels to the entries of the interval. The rule rect combines two of these interval groups into a map, one group for the X dimension (using 0, 1, and 2 as labels) and one for the Y dimension (using 3, 4, and 5 as labels).
図1の例には、低くて上限を与えるCDDLグループ間隔の一般的な定義が含まれています。パラメータベースでは、区間のエントリに異なるラベルを割り当てることで、1つのマップ内の複数のマップの競合しない使用を許可します。Rule Rectは、これらの間隔グループのうちの2つをマップにまとめます（ラベルとして0,1、および2を使用して）X次元（ラベルとして3,4、および5を使用）の1つのグループに1つのグループを組み合わせます。
It is often useful to be able to compose string literals out of component literals defined in different places in the specification.
仕様内のさまざまな場所で定義されているコンポーネントリテラルから文字列リテラルを作成できることがよくあります。
The .cat control identifies a string that is built from a concatenation of the target and the controller. The target and controller both MUST be strings. The result of the operation has the same type as 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.
.catコントロールは、ターゲットとコントローラの連結から構築された文字列を識別します。ターゲットとコントローラの両方が文字列である必要があります。操作の結果はターゲットと同じタイプです。連結は両方の文字列のバイトに対して実行されます。ターゲットがテキスト文字列の場合、その連結の結果は有効なUTF-8でなければなりません。
c = "foo" .cat ' bar baz ' ; on a system where the newline is \n, is the same string as: b = "foo\n bar\n baz\n"
c = "foo" .cat 'bar baz';改行が\ Nのシステムでは、次のようなものと同じ文字列です.b = "foo \ n bar \ n baz \ n"
Figure 2: An Example of Concatenation of Text and Byte Strings
図2：テキストとバイト文字列の連結の例
The example in Figure 2 builds a text string named c from concatenating the target text string "foo" and the controller byte string entered in a text form byte string literal. (This particular 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 the format that the pure CDDL text string notation inherits from JSON.)
図2の例では、ターゲットテキスト文字列 "foo"を連結し、テキスト形式のバイト文字列リテラルに入力されたコントローラバイト文字列を連結したテキスト文字列を構築します。（この特定のIDIOMは、テキスト文字列には、Bの例に示すように、Bの例に示すように、純粋なCDDLテキスト文字列表記がJSONから継承するフォーマットで読みにくい場合があります。）
Multi-line string literals for various applications, including embedded ABNF (Section 3), need to be set flush left, at least partially. Often, having some indentation in the source code for the literal can promote readability, as in Figure 3.
埋め込みABNFを含むさまざまなアプリケーションのマルチライン文字列リテラル（セクション3）は、少なくとも部分的に左に置く必要があります。多くの場合、文字通りのソースコードにいくつかのインデントを持つことは、図3のように、読みやすさを促進することができます。
oid = bytes .abnfb ("oid" .det cbor-tags-oid) roid = bytes .abnfb ("roid" .det cbor-tags-oid)
OID =バイト.ABNFB（ "OID" .det cbor-tags-oid）ROID =バイト.abnfb（ "Roid" .det cbobor-tags-oid）
cbor-tags-oid = '
oid = 1*arc
roid = *arc
arc = [nlsb] %x00-7f
nlsb = %x81-ff *%x80-ff
'
Figure 3: An Example of Dedenting Concatenation
図3：脱退連結の例
The control operator .det works like .cat, except that both arguments (target and controller) are independently _dedented_ before the concatenation takes place.
コントロール演算子.detは、.catのように機能します。
For the first rule in Figure 3, the result is equivalent to Figure 4.
図3の最初の規則では、結果は図4と同じです。
oid = bytes .abnfb 'oid
oid = 1*arc
roid = *arc
arc = [nlsb] %x00-7f
nlsb = %x81-ff *%x80-ff
'
Figure 4: Dedenting Example: Result of First .det
図4：既定の例：最初の.detの結果
For the purposes of this specification, we define "dedenting" as:
本明細書の目的のために、次のように「献身的」を定義します。
1. determining the smallest amount of leftmost blank space (number of leading space characters) present in all the non-blank lines, and
1. 全ての空白行に存在する最小の空白スペース（先頭のスペース文字数）を決定し、
2. removing exactly that number of leading space characters from each line. For blank (blank space only or empty) lines, there may be fewer (or no) leading space characters than this amount, in which case all leading space is removed.
2. 各行からの先行スペース文字の数を正確に削除します。ブランク（空白スペースのみまたは空の）ラインの場合、この金額よりも先行スペース文字が少なくなる可能性があります。この場合、すべての先行スペースが削除されます。
(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 invoke unpleasant images.)
（名前.Detは「脱獄猫」のショートカットです。多分より明白な名前.Dedcatは長いので選択されておらず、不快な画像を呼び出す可能性があります。）
Occasionally, dedenting of only a single item is needed. This can be 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.
時折、単一のアイテムのみの専用のアイテムが必要です。これは、この演算子を空の文字列、例えば「.det RHSまたはLHS .Det」で使用することによって達成することができます。）、RHSだけが損なわれます。
Many IETF protocols define allowable values for their text strings in ABNF [RFC5234] [RFC7405]. It is often desirable to define a text string type in CDDL by employing existing ABNF embedded into the CDDL specification. Without specific ABNF support in CDDL, that ABNF would usually need to be translated into a regular expression (if that is even possible).
多くのIETFプロトコルは、ABNF [RFC5234] [RFC7405]のテキスト文字列の許容値を定義します。CDDL仕様に埋め込まれた既存のABNFを使用することによって、CDDL内のテキスト文字列タイプを定義することがしばしば望ましい。CDDLでの特別なABNFサポートがなければ、ABNFは通常正規表現（それが可能である場合）に変換する必要があります。
ABNF is added to CDDL in the same way that regular expressions were added: by defining a .abnf control operator. The target is usually text or some restriction on it, and the controller is the text of an ABNF specification.
正規表現が追加されたのと同じ方法で、ABNFがCDDLに追加されます。.ABNF制御演算子を定義します。ターゲットは通常テキストまたはその上の制限であり、コントローラはABNF仕様のテキストです。
There are several small issues; the solutions are given here:
いくつかの小さな問題があります。解決策はここに示されています。
* ABNF can be used to define byte sequences as well as UTF-8 text strings interpreted as Unicode scalar sequences. This means this specification defines two control operators: .abnfb for ABNF denoting byte sequences and .abnf for denoting sequences of Unicode scalar values (code points) represented as UTF-8 text strings. Both control operators can be applied to targets of either string type; the ABNF is applied to the sequence of bytes in the string and interprets it as a sequence of bytes (.abnfb) or as a sequence of code points represented as an UTF-8 text string (.abnf). The controller string MUST be a string. When a byte string, it MUST be valid UTF-8 and is interpreted as the text string that has the same sequence of bytes.
* ABNFは、Unicodeスカラーシーケンスとして解釈されたUTF-8テキスト文字列と同様に、バイトシーケンスの定義に使用できます。つまり、この仕様は2つの制御演算子を定義しています。両方の制御演算子は、どちらの文字列型のターゲットにも適用できます。ABNFは文字列内の一連のバイトに適用され、それを一連のバイト（.abnfb）またはUTF-8テキスト文字列（.abnf）として表される一連のコードポイントとして解釈されます。コントローラ文字列は文字列でなければなりません。バイト文字列が有効なUTF-8でなければならず、同じバイトのシーケンスを持つテキスト文字列として解釈されます。
* ABNF defines a list of rules, not a single expression (called "elements" in [RFC5234]). This is resolved by requiring the controller string to be one valid "element", followed by zero or more valid "rules" separated from the element by a newline; thus, the controller string can be built by preceding a piece of valid ABNF by an "element" that selects from that ABNF and a newline.
* ABNFは、単一の式ではなく、ルールのリストを定義します（[RFC5234]の「要素」と呼ばれます）。これは、コントローラ文字列が1つの有効な "要素"になることを要求し、その後に、元の有効な "ルール"が新しいラインによって区切られていることを要求することによって解決されます。したがって、コントローラストリングは、そのABNFから選択された「要素」と改行の有効なABNFの前に構築することができます。
* For the same reason, ABNF requires newlines; specifying newlines in CDDL text strings is tedious (and leads to essentially unreadable ABNF). The workaround employs the .cat operator 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 syntax expressed in ABNF!) is relaxed to allow a single line feed as a newline:
* 同じ理由で、ABNFは改行を必要とします。CDDLテキスト文字列の新選択を指定することは面倒です（そして本質的に読めないABNFにつながります）。この回避策は、セクション2.2で導入された.cat演算子とバイト文字列のテキストの構文を採用しています。ABNFのための慣習的なように、ABNF自体の構文（_not_がABNFで表現された構文！）は、改行として単一行フィードを許可するためにリラックスしています。
CRLF = %x0A / %x0D.0A
* One set of rules provided in an ABNF specification is often used in multiple positions, particularly staples such as DIGIT and ALPHA. (Note that all rules referenced need to be defined in each ABNF operator controller string -- there is no implicit import of core ABNF rules from [RFC5234] or other rules.) The composition this calls for can be provided by the .cat operator and/or by .det if there is indentation to be disposed of.
* ABNF仕様で提供される一連の規則は、複数の位置、特にディジットやアルファなどのステープルでよく使用されます。（参照されているすべての規則は、各ABNF演算子コントローラ文字列で定義する必要があります。 - [RFC5234]またはその他の規則からのコアABNFルールの暗黙のインポートはありません。）この呼び出しは、.cat演算子によって提供できます。/または処分するためのインデントがある場合は/または.detによって。
These points are combined into an example in Figure 5, which uses ABNF from [RFC3339] to specify one of each of the Concise Binary Object Representation (CBOR) tags defined in [RFC8943] and [RFC8949].
これらの点は、[RFC3339]から[RFC8943]と[RFC8949]で定義されている各Concive Binaryオブジェクト表現（CBOR）タグの1つを指定するために、図5の例にまとめられています。
; for RFC 8943
Tag1004 = #6.1004(text .abnf full-date)
; for RFC 8949
Tag0 = #6.0(text .abnf date-time)
full-date = "full-date" .cat rfc3339 date-time = "date-time" .cat rfc3339
フルデート= "alt-date" .cat rfc3339日付 - time = "日付 - 時刻" .cat rfc3339
; Note the trick of idiomatically starting with a newline, separating
; off the element in the concatenations above from the rule-list
rfc3339 = '
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap sec
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset
partial-time =時間/時間： "Time-Minue"： "Time-Sece-SecFrac]フルデート=日付 - 「日付月」 - "日付 - MDAYフルタイム=パーシャルタイムタイムオフセット
date-time = full-date "T" full-time ' .det rfc5234-core
日付 - 時刻=フルタイムの.det RFC5234-Core
rfc5234-core = '
DIGIT = %x30-39 ; 0-9
; abbreviated here
'
Figure 5: An Example of Employing ABNF from RFC 3339 for Defining CBOR Tags
図5：CBORタグを定義するためのRFC 3339からABNFを採用する例
Commonly, the kind of validation enabled by languages such as CDDL provides a Boolean result: valid or invalid.
一般に、CDDLなどの言語によって有効になっている検証の種類は、有効または無効なブール値を提供します。
In rapidly evolving environments, this is too simplistic. The data models described by a CDDL specification may continually be enhanced by additional features, and it would be useful even for a specification that does not yet describe a specific future feature to identify the extension point the feature can use and accept such extensions while marking them as extensions.
急速に進化する環境では、これは単純化すぎる。CDDL仕様によって記述されたデータモデルは、追加の機能によって継続的に強化されている可能性があり、それらをマーキングしながらそのような拡張を使用することができる拡張ポイントを識別するための特定の将来の機能をまだ説明していない仕様でさえ役立ちます。拡張として。
The .feature control annotates the target as making use of the feature named by the controller. The latter will usually be a string. A tool that validates an instance against that specification may mark the instance as using a feature that is annotated by the specification.
.Feature Controlは、コントローラによって指定された機能を使用するようにターゲットに注釈を付けます。後者は通常文字列です。その仕様に対してインスタンスを検証するツールは、仕様によって注釈を付けられている機能を使用してインスタンスをマークすることができます。
More specifically, the tool's diagnostic output might contain the controller (right-hand side) as a feature name and the target (left-hand side) as a feature detail. However, in some cases, the target has too much detail, and the specification might want to hint to the tool that more limited detail is appropriate. In this case, the controller should be an array, with the first element being the feature name (that would otherwise be the entire controller) and the second element being the detail (usually another string), as illustrated in Figure 6.
具体的には、ツールの診断出力には、機能名とターゲット（左側）としてコントローラ（右側）が特徴の詳細として含まれる可能性があります。ただし、場合によっては、ターゲットは詳細が多すぎるため、仕様はより限られた詳細が適切であるというツールにヒントしたいと思うかもしれません。この場合、コントローラは、図6に示すように、最初の要素はフィーチャー名（そうでなければコントローラ全体になります）であり、2番目の要素は詳細（通常は別の文字列）であることがわかります。
foo = {
kind: bar / baz .feature (["foo-extensions", "bazify"])
}
bar = ...
baz = ... ; complex stuff that doesn't all need to be in the detail
Figure 6: Providing Explicit Detail with .feature
図6：.Featureで明確な詳細を提供します
Figure 7 shows what could be the definition of a person, with potential extensions beyond name and organization being marked further-person-extension. Extensions that are known at the time this definition is written can be collected into $$person-extensions. However, future extensions would be deemed invalid 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 use of the validation result; the label (map key) actually used makes a fine feature detail for the tool's diagnostic output.
図7は、人の定義があるものが、名前や組織を超えた潜在的な拡張機能を持つものを示しています。この定義が書かれている時点で知られている拡張子は、$$ Person-Extensionsに収集できます。ただし、マップの最後にあるワイルドカードが追加されていない限り、将来の拡張機能は無効と見なされます。これらの拡張は、検証結果を利用するユーザまたはツールによって特に検査され得る。実際に使用されているラベル（MAPキー）は、ツールの診断出力のための罰金の詳細を細かくします。
Leaving out the entire extension point would mean that instances that make use of an extension would be marked as wholesale invalid, making the entire validation approach much less useful. Leaving the extension point in but not marking its use as special would render mistakes (such as using the label "organisation" instead of "organization") invisible.
延長点全体を省略すると、延長を利用するインスタンスは卸売無効としてマークされ、検証アプローチ全体がはるかに有用ではありません。拡張ポイントを、特別なものとしてマーキングしていませんが、「組織」の代わりに「組織のラベル」を使用するなど）を表示します。
person = {
? name: text
? organization: text
$$person-extensions
* (text .feature "further-person-extension") => any
}
$$person-extensions //= (? bloodgroup: text)
Figure 7: Map Extensibility with .feature
図7：.FeatureとのMap Extensibility
Figure 8 shows another example where .feature provides for type extensibility.
タイプ拡張性を提供する別の例を示します。
allowed-types = number / text / bool / null
/ [* number] / [* text] / [* bool]
/ (any .feature "allowed-type-extension")
Figure 8: Type Extensibility with .feature
図8：.Featureとの型拡張性を入力します
A CDDL tool may simply report the set of features being used; the control then only provides information to the process requesting the validation. One could also imagine a tool that takes arguments, allowing the tool to accept certain features and reject others (enable/disable). The latter approach could, for instance, be used for a JSON/CBOR switch, as illustrated in Figure 9, using Sensor Measurement Lists (SenML) [RFC8428] as the example data model used with both JSON and CBOR.
CDDLツールは、使用されている機能のセットを単に報告することができます。その後、制御は検証を要求するプロセスに情報を提供します。引数を取り、ツールが特定の機能を受け入れて他の機能を拒否することを可能にするツールを想像することもできます（有効/無効）。例えば、図9に示すように、JSONとCBORの両方で使用されるサンプルデータモデルとしてセンサ測定リスト（SENML）[RFC8428]を使用して、後者のアプローチはJSON / CBORスイッチに使用できます。
SenML-Record = {
; ...
? v => number
; ...
}
v = JC<"v", 2>
JC<J,C> = J .feature "json" / C .feature "cbor"
Figure 9: Describing Variants with .feature
図9：
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 mutually exclusive use of features, as would be needed in this example.
イネーブル/ディセーブルアプローチがCDDLを使用する新しい慣用句につながる可能性がある場合は、まだ見られます。この言語は現在、この例で必要とされるように、現在特徴の排他的な使用を強制する方法はありません。
IANA has registered the contents of Table 2 into the "CDDL Control Operators" registry of [IANA.cddl]:
IANAは表2の内容を「IANA.CDDL」の「CDDL制御演算子」レジストリに登録しました。
+==========+===========+
| Name | Reference |
+==========+===========+
| .plus | RFC 9165 |
+----------+-----------+
| .cat | RFC 9165 |
+----------+-----------+
| .det | RFC 9165 |
+----------+-----------+
| .abnf | RFC 9165 |
+----------+-----------+
| .abnfb | RFC 9165 |
+----------+-----------+
| .feature | RFC 9165 |
+----------+-----------+
Table 2: New Control Operators
表2：新しい制御演算子
The security considerations of [RFC8610] apply.
[RFC8610]のセキュリティ上の考慮事項が適用されます。
While both [RFC5234] and [RFC7405] state that security is truly believed to be irrelevant to the respective document, the use of formal description techniques cannot only simplify but sometimes also complicate a specification. This can lead to security problems in implementations and in the specification itself. As with CDDL itself, ABNF should be judiciously applied, and overly complex (or "cute") constructions should be avoided.
セキュリティがそれぞれの文書とは無関係であると本当に信じられている[RFC5234]と[RFC7405]の両方の状態では、正式な説明技術の使用は単純化できないが、特定の仕様も複雑にすることができない。これは実装のセキュリティ上の問題と仕様自体につながる可能性があります。CDDL自体と同様に、ABNFは慎重に適用されるべきであり、そして過度に複雑な（または「かわいい」）構造を避けるべきである。
[IANA.cddl] IANA, "Concise Data Definition Language (CDDL)", <https://www.iana.org/assignments/cddl>.
[IANA.CDDL] IANA、「簡潔なデータ定義言語（CDDL）」、<https://www.iana.org/assignments/cddl>。
[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>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc5234、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc5234,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] KYZIVAT、P。、「ABNFでの大文字と小文字の区別文字列サポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<https：//www.rfc-editor.org/info/rfc7405>。
[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>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[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>.
[RFC3339] Klyne、G.およびC. Newman、「インターネット上の日時：Timestamps」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https：//www.rfc-editor.org/info/rfc3339>。
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, <https://www.rfc-editor.org/info/rfc8428>.
[RFC8428]ジェニングニング、C、Shelby、Z.、Arkko、J.、Keranen、A.、C. Bormann、C. Bormann、RFC 8428、DOI 10.17487 / RFC8428、2018年8月、<HTTPS//www.rfc-editor.org/info/rfc8428>。
[RFC8943] Jones, M., Nadalin, A., and J. Richter, "Concise Binary Object Representation (CBOR) Tags for Date", RFC 8943, DOI 10.17487/RFC8943, November 2020, <https://www.rfc-editor.org/info/rfc8943>.
[RFC8943] Jones、M.、Nadalin、A.、J.RICHTER、「COBOR」、RFC 8943、DOI 10.17487 / RFC8943、2020年11月、<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>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
Acknowledgements
謝辞
Jim Schaad suggested several improvements. The .feature feature was developed out of a discussion with Henk Birkholz. Paul Kyzivat helped isolate the need for .det.
Jim Schaadはいくつかの改良を示唆しました。.Feature機能はHENK Birkholzとの議論から開発されました。Paul Kyzivatは、.detの必要性を分離するのに役立ちました。
.det is an abbreviation for "dedenting cat", but Det is also the name of a German TV cartoon character created in the 1960s.
.detは「脱獄猫」の略語ですが、1960年代に作成されたドイツのTV漫画のキャラクターの名前もあります。
Author's Address
作者の住所
Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany
Carsten BormannUniversitätブレーメンTzi Postfach 330440 D-28359ブレーメンドイツ
Phone: +49-421-218-63921
Email: cabo@tzi.org