Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 9741 Universität Bremen TZI
Category: Standards Track March 2025
ISSN: 2070-1721
The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way.
RFC 8610に標準化された簡潔なデータ定義言語（CDDL）は、その主要言語拡張ポイントとして「制御演算子」を提供します。RFCは、アプリケーション固有とより一般的な方法の両方で、この拡張ポイントに追加されました。
The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text.
現在のドキュメントでは、テキスト変換（バイト、整数、printfスタイルのフォーマット、およびJSON）およびテキストの操作について、多くの追加の追加適用制御演算子を定義しています。
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/rfc9741.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9741で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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. Text Conversion
2.1. Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64
2.2. Numerals
2.3. Printf-Style Formatting
2.4. JSON Values
3. Text Processing
3.1. Join
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
List of Figures
List of Tables
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]). RFCs have added to this extension point in both an application-specific [RFC9090] and a more general [RFC9165] way.
[RFC8610]に標準化された簡潔なデータ定義言語（CDDL）は、その主要言語拡張ポイント（[RFC8610]のセクション3.8）として「コントロール演算子」を提供します。RFCは、アプリケーション固有の[RFC9090]とより一般的な[RFC9165]方法の両方で、この拡張ポイントに追加されました。
The present document defines a number of additional generally applicable control operators. In Table 1, the column marked t is for "target type" (left-hand side), and the column marked c is for "controller type" (right-hand side).
現在のドキュメントでは、一般的に適用可能な多くの制御オペレーターを定義しています。表1では、tとマークされた列は「ターゲットタイプ」（左側）用で、cとマークされた列は「コントローラータイプ」（右側）用です。
+===============+=========+=======+==============================+
| Name | t | c | Purpose |
+===============+=========+=======+==============================+
| .b64u, .b64c | text | bytes | Base64 representation of |
| | | | byte strings |
+---------------+---------+-------+------------------------------+
| .b64u-sloppy, | text | bytes | Sloppy-tolerant variants of |
| .b64c-sloppy | | | the above |
+---------------+---------+-------+------------------------------+
| .hex, .hexlc, | text | bytes | Base16 representation of |
| .hexuc | | | byte strings |
+---------------+---------+-------+------------------------------+
| .b32, .h32 | text | bytes | Base32 representation of |
| | | | byte strings |
+---------------+---------+-------+------------------------------+
| .b45 | text | bytes | Base45 representation of |
| | | | byte strings |
+---------------+---------+-------+------------------------------+
| .base10 | text | int | Text representation of |
| | | | integer numbers |
+---------------+---------+-------+------------------------------+
| .printf | text | array | Printf-formatted text |
| | | | representation of data items |
+---------------+---------+-------+------------------------------+
| .json | text | any | Text representation of JSON |
| | | | values |
+---------------+---------+-------+------------------------------+
| .join | text or | array | Build text or byte string |
| | bytes | | from array of components |
+---------------+---------+-------+------------------------------+
Table 1: Summary of 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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Regular expressions mentioned in the text are as defined in [RFC9485].
テキストで言及されている正規表現は、[RFC9485]で定義されています。
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 "opinionated" is used in this document to explain that the selection of operators included is somewhat frugal, based on opinions about what the preferred (and likely) usage scenarios will be. Specifically, not including a potential choice doesn't by itself intend to express that the choice is unacceptable; it might still be added in a future registration if these opinions evolve.
このドキュメントでは、「意見を述べた」という用語は、含まれるオペレーターの選択が、好みの（および可能性の高い）使用シナリオが何であるかについての意見に基づいて、やや質素であることを説明するために使用されています。具体的には、潜在的な選択を含めないこと自体は、選択が受け入れられないことを表現するつもりはありません。これらの意見が進化した場合、将来の登録にまだ追加される可能性があります。
A CDDL model often defines data that are byte strings in essence but need to be transported in various encoded forms, such as base64 or hex. This section defines a number of control operators to model these conversions.
CDDLモデルは、多くの場合、本質的にバイト文字列であるが、Base64やHexなどのさまざまなエンコードされたフォームで輸送する必要があるデータを定義します。このセクションでは、これらの変換をモデル化するために多くの制御演算子を定義します。
The control operators generally are of a form that could be used like this:
コントロール演算子は一般に、次のように使用できる形式です。
signature-for-json = text .b64u signature
signature = bytes .cbor COSE_Sign1
The specification of these control operators cannot provide full coverage of the large number of transformations in use; it focuses on [RFC4648] and additionally [RFC9285], as shown in Table 2. For the representations defined in [RFC4648], this specification uses names as inspired by Section 8 of RFC 8949 [STD94]:
これらの制御演算子の仕様は、使用中の多数の変換を完全にカバーすることはできません。[RFC4648]、さらに[RFC9285]に焦点を当てています。表2に示すように。[RFC4648]で定義されている表現については、この仕様では、RFC 8949 [STD94]のセクション8に触発された名前を使用します。
+==============+===========================+========================+
| Name | Meaning | Reference |
+==============+===========================+========================+
| .b64u | Base64url, no padding | Section 5 of |
| | | [RFC4648] |
+--------------+---------------------------+------------------------+
| .b64u-sloppy | Base64url, no padding, | Section 5 of |
| | sloppy | [RFC4648] |
+--------------+---------------------------+------------------------+
| .b64c | Base64 classic, padding | Section 4 of |
| | | [RFC4648] |
+--------------+---------------------------+------------------------+
| .b64c-sloppy | Base64 classic, padding, | Section 4 of |
| | sloppy | [RFC4648] |
+--------------+---------------------------+------------------------+
| .b32 | Base32, no padding | Section 6 of |
| | | [RFC4648] |
+--------------+---------------------------+------------------------+
| .h32 | Base32 with "Extended | Section 7 of |
| | Hex" alphabet, no padding | [RFC4648] |
+--------------+---------------------------+------------------------+
| .hex | Base16 (hex), either case | Section 8 of |
| | | [RFC4648] |
+--------------+---------------------------+------------------------+
| .hexlc | Base16 (hex), lower case | Section 8 of |
| | | [RFC4648] |
+--------------+---------------------------+------------------------+
| .hexuc | Base16 (hex), upper case | Section 8 of |
| | | [RFC4648] |
+--------------+---------------------------+------------------------+
| .b45 | Base45 | [RFC9285] |
+--------------+---------------------------+------------------------+
Table 2: Control Operators for Text Conversion of Byte Strings
表2：バイト文字列のテキスト変換のための制御演算子
Note that this specification is somewhat opinionated here: It does not provide base64url or base32(hex) encoding with padding or base64 classic without padding. Experience indicates that these combinations only ever occur in error, so the usability of CDDL is increased by not providing them in the first place. Also, adding "c" makes sure that any decision for classic base64 is actively taken.
この仕様はここで多少意見を述べていることに注意してください。これは、パディングなしでパディングまたはbase64クラシックでエンコードするbase64urlまたはbase32（六角）を提供しません。経験は、これらの組み合わせが誤ってのみ発生することを示しているため、CDDLの使いやすさはそもそも提供しないことで増加します。また、「C」を追加すると、Classic Base64の決定が積極的に行われることを確認します。
These control operators are "strict" in their matching, i.e., they only match base encodings that conform to the mandates of their defining documents. Note that this also means that .b64u and .b64c only match text strings composed of the set of characters defined for each of them, respectively. (This is perhaps worth pointing out explicitly as it contrasts with the "b64" literal prefix that can be used to notate byte strings in CDDL source code, which simply accepts characters from either alphabet. This behavior is different from the matching behavior of the four base64 control operators defined here.)
これらの制御オペレーターは、マッチングで「厳格」です。つまり、定義するドキュメントの任務に準拠するベースエンコーディングのみを一致させます。これは、.b64uと.b64cがそれぞれに定義された文字のセットで構成されるテキスト文字列のみを一致させることも意味します。（これはおそらく、Alphabetの文字を単に受け入れるCDDLソースコードのバイト文字列を記述するために使用できる「B64」リテラルプレフィックスとは対照的であるため、おそらく明示的に指摘する価値があります。
The additional designation "sloppy" indicates that the text string is not validated for any additional bits being zero, in variance to what is specified in the paragraph that follows Table 1 in Section 4 of [RFC4648]. Note that the present specification is opinionated again in not specifying a sloppy variant of base32 or base32hex, as no legacy use of sloppy base32(hex) was known at the time of writing. Base45 [RFC9285] is known to be suboptimal for use in environments with limited data transparency (such as URLs) but is included because of its close relationship to QR codes and its wide use in health informatics (note that base45 is strongly specified not to allow sloppy forms of encoding).
追加の指定「sloppy」は、[RFC4648]のセクション4の表1に次の段落で指定されているものとは異なる追加のビットについて、テキスト文字列がゼロであることに対して検証されていないことを示します。現在の仕様は、base32またはbase32hexのずさんなバリアントを指定しないことで再び意見を述べられていることに注意してください。執筆時点ではずさんなbase32（六角）のレガシーの使用は知られていなかったためです。Base45 [RFC9285]は、データの透明性（URLなど）が限られている環境で使用するために最適ではないことが知られていますが、QRコードとの密接な関係と健康情報学での幅広い使用のために含まれています（Base45は、エンコーディングのずさんな形式を許可しないように強く指定されています）。
+=========+============================+===========+
| Name | Meaning | Reference |
+=========+============================+===========+
| .base10 | Base-ten (decimal) integer | --- |
+---------+----------------------------+-----------+
Table 3: Control Operator for Text Conversion of Integers
表3：整数のテキスト変換のための制御演算子
The control operator .base10 allows the modeling of text strings that carry an integer number in decimal form (as a text string with digits in the usual base-ten positional numeral system), such as in the uint64/int64 formats of YANG-JSON [RFC7951].
コントロール演算子.base10は、Yang-json [RFC7951]のUINT64/INT64形式のように、10進数（通常のベーステン位置数値システムに数字を持つテキスト文字列として）で整数数を運ぶテキスト文字列のモデリングを許可します。
yang-json-sid = text .base10 (0..9223372036854775807)
Again, the specification is opinionated by only providing for integer numbers represented without leading zeros, i.e., the decimal integer numerals match the regular expression 0|-?[1-9][0-9]* (of course, this is further restricted by the control type). See Section 2.3 for more flexibility and for other numeric bases such as octal, hexadecimal, or binary conversions.
繰り返しますが、仕様は、先行ゼロなしで表される整数数を提供することによってのみ意見があります。つまり、小数整数数は正規表現0 | - ？[1-9] [0-9]*（もちろん、これはコントロールタイプによってさらに制限されます）。より柔軟性、およびOctal、16進数、バイナリ変換などの他の数値ベースについては、セクション2.3を参照してください。
Note that this control operator governs text representations of integers and should not be confused with the control operators governing text representations of byte strings (such as .b64u). This contrast is somewhat reinforced by spelling out "base" in the name .base10 as opposed to those of the byte string operators.
このコントロール演算子は、整数のテキスト表現を管理しており、バイト文字列（.B64Uなど）のテキスト表現を支配するコントロール演算子と混同しないでください。このコントラストは、バイト文字列演算子のものとは対照的に、名前の「ベース」を「ベース」に綴ることによって多少補強されます。
+=========+=========================================+===========+
| Name | Meaning | Reference |
+=========+=========================================+===========+
| .printf | Printf-style formatting of data item(s) | --- |
+---------+-----------------------------------------+-----------+
Table 4: Control Operator for Printf-Style Formatting of Data Item(s)
表4：データ項目のprintfスタイルのフォーマットのための制御演算子
The control operator .printf allows the modeling of text strings that carry various formatted information, as long as the format can be represented in printf-style formatting strings as they are used in the C language (see Section 7.23.6.1 of [C]; note that the "C23" standard includes %b and %B for formatting into binary digits).
コントロール演算子.Printfは、形式がC言語で使用されているように印刷された形式の文字列で表現できる限り、さまざまなフォーマットされた情報を伝達するテキスト文字列のモデリングを許可します（「C23」標準には、バイナリの図式にフォーマットするための％Bおよび％Bが含まれることに注意してください）。
The controller (right-hand side) of the .printf control is an array of one printf-style format string and zero or more data items that fit the individual conversion specifications in the format string. The construct matches a text string representing the textual output of an equivalent C-language printf function call that receives as arguments the format string and the data items following it in the array.
.printfコントロールのコントローラー（右側）は、1つのprintfスタイルの形式の文字列と、個々の変換仕様にフォーマット文字列に適合するゼロ以上のデータ項目の配列です。コンストラクトは、形式の文字列とそれに続く配列に続くデータ項目を受信する同等のC言語Printf関数呼び出しのテキスト出力を表すテキスト文字列と一致します。
Out of the functionality described for printf formatting in Section 7.23.6.1 of the C language specification [C], length modifiers (paragraph 7) are not used and MUST NOT be included in the format string. The "s" conversion specifier (paragraph 8) is used to interpolate a text string in UTF-8 form. The "c" conversion specifier (paragraph 8) represents a single Unicode scalar value as a UTF-8 character. The "p" and "n" conversion specifiers (paragraph 8) are not used and MUST NOT be included in the format string.
C言語仕様[c]のセクション7.23.6.1で印刷された形式で説明されている機能のうち、長さの修飾子（パラグラフ7）は使用されておらず、形式の文字列に含める必要はありません。「S」変換指定子（パラグラフ8）を使用して、UTF-8フォームのテキスト文字列を補間します。「C」変換仕様（パラグラフ8）は、UTF-8文字として単一のユニコードスカラー値を表します。「p」および「n」変換仕様（パラグラフ8）は使用されておらず、形式の文字列に含めてはなりません。
In the following example, my_alg_19 matches the text string "0x0013":
次の例では、my_alg_19はテキスト文字列「0x0013」と一致します。
my_alg_19 = hexlabel<19>
hexlabel<K> = text .printf (["0x%04x", K])
The data items in the controller array do not need to be literals, as in the following example:
次の例のように、コントローラーアレイ内のデータ項目はリテラルである必要はありません。
any_alg = hexlabel<1..20>
hexlabel<K> = text .printf (["0x%04x", K])
Here, any_alg matches the text strings "0x0013" or "0x0001" but not "0x1234".
ここで、any_algはテキスト文字列「0x0013」または「0x0001」と一致しますが、「0x1234」ではありません。
Some applications store complete JSON texts [STD90] into text strings. The JSON value of these can easily be defined in CDDL by using the default JSON-to-CBOR conversion rules provided in Section 6.2 of RFC 8949 [STD94]. This is supported by a control operator similar to .cbor as defined in Section 3.8.4 of [RFC8610].
一部のアプリケーションは、完全なJSONテキスト[STD90]をテキスト文字列に保存します。これらのJSON値は、RFC 8949 [STD94]のセクション6.2に記載されているデフォルトのJSON間変換ルールを使用することにより、CDDLで簡単に定義できます。これは、[RFC8610]のセクション3.8.4で定義されているように、.cborと同様の制御演算子によってサポートされています。
+=======+=========+===========+
| Name | Meaning | Reference |
+=======+=========+===========+
| .json | JSON | [STD90] |
+-------+---------+-----------+
Table 5: Control Operator for Text Conversion of JSON Values
表5：JSON値のテキスト変換のためのコントロール演算子
embedded-claims = text .json claims
claims = {iss: text, exp: text}
Notes:
注：
* JSON has known interoperability problems [RFC7493]. While Section 4 of [RFC7493] probably is not relevant to this specification, Section 2 of [RFC7493] provides requirements that need to be followed to make use of the generic data model underlying CDDL. Note that the intention of Section 2.2 of [RFC7493] is directly supported by Section 6.2 of RFC 8949 [STD94]. The recommendation to use text strings for representing numbers outside JSON's interoperable range is a requirement on the application data model and therefore needs to be reflected on the right-hand side of the .json control operator.
* JSONは相互運用性の問題を知っています[RFC7493]。[RFC7493]のセクション4はおそらくこの仕様には関係ありませんが、[RFC7493]のセクション2には、CDDLの根底にある汎用データモデルを利用するために従う必要がある要件を提供します。[RFC7493]のセクション2.2の意図は、RFC 8949 [STD94]のセクション6.2で直接サポートされていることに注意してください。JSONの相互運用可能な範囲外の数値を表すためにテキスト文字列を使用することを推奨することは、アプリケーションデータモデルの要件であるため、.JSONコントロール演算子の右側に反映する必要があります。
* This control operator provides no way to constrain the use of blank space or other serialization variants in the JSON representation of the data items; restrictions on the serialization to specific variants (e.g., not providing for the addition of any insignificant blank space and prescribing an order in which map entries are serialized) could be defined in future control operators.
* この制御演算子は、データ項目のJSON表現に空白スペースまたはその他のシリアル化バリアントの使用を制約する方法を提供しません。特定のバリエーションへのシリアル化の制限（たとえば、取るに足らない空白スペースの追加を提供しない、マップエントリがシリアル化される順序を処方する）は、将来の制御演算子で定義できます。
* A .jsonseq is not provided in this document for JSON text sequences [RFC7464], as no use case for inclusion in CDDL is known at the time of writing; again, future control operators could address this use case.
* a .jsonseqは、JSONテキストシーケンス[RFC7464]のこのドキュメントでは提供されていません。CDDLに含まれる場合は、執筆時点では知られていないためです。繰り返しますが、将来の制御オペレーターはこのユースケースに対処できます。
Often, text strings need to be constructed out of parts that can best be modeled as an array.
多くの場合、テキスト文字列は、配列としてモデル化するのが最適な部品から構築する必要があります。
+=======+==================================+===========+
| Name | Meaning | Reference |
+=======+==================================+===========+
| .join | Concatenate elements of an array | --- |
+-------+----------------------------------+-----------+
Table 6: Control Operator for Text Generation from Arrays
表6：アレイからのテキスト生成の制御演算子
For example, an IPv4 address in dotted-decimal might be modeled as in Figure 1.
たとえば、図1のように、点線のIPv4アドレスがモデル化される場合があります。
legacy-ip-address = text .join legacy-ip-address-elements
legacy-ip-address-elements = [bytetext, ".", bytetext, ".",
bytetext, ".", bytetext]
bytetext = text .base10 byte
byte = 0..255
Figure 1: Using the .join Operator to Build Dotted-Decimal IPv4 Addresses
図1：.join演算子を使用して、点線のIPv4アドレスを構築する
The elements of the controller array need to be strings (text or byte strings). The control operator matches a data item if that data item is also a string, built by concatenating the strings in the array. The result of this concatenation is of the same kind of string (text or bytes) as the first element of the array. (If there is no element in the array, the .join construct matches either kind of empty string, obviously further constrained by the control operator target.) The concatenation is performed on the sequences of bytes in the strings. If the result of the concatenation is a text string, the resulting sequence of bytes only matches the target data item if that result is a valid text string (i.e., valid UTF-8). Note that in contrast to the algorithm used in Section 3.2.3 of RFC 8949 [STD94], there is no need for all individual byte sequences going into the concatenation to constitute valid text strings.
コントローラーアレイの要素は、文字列（テキストまたはバイト文字列）である必要があります。コントロール演算子は、そのデータ項目がアレイ内の文字列を連結することによって構築された文字列でもある場合、データ項目と一致します。この連結の結果は、配列の最初の要素と同じ種類の文字列（テキストまたはバイト）です。（配列に要素がない場合、.Joinコンストラクトは、明らかに制御演算子ターゲットによってさらに制約されている空の文字列のいずれかの種類と一致します。）連鎖の連結は、文字列のバイトのシーケンスで実行されます。連結の結果がテキスト文字列である場合、結果の結果は、その結果が有効なテキスト文字列（つまり、有効なUTF-8）である場合にのみターゲットデータ項目と一致します。RFC 8949 [STD94]のセクション3.2.3で使用されているアルゴリズムとは対照的に、すべての個々のバイトシーケンスが連結に入って有効なテキスト文字列を構成する必要はないことに注意してください。
Note that this control operator is hard to validate in the most general case, as this would require full parser functionality. Simple implementation strategies will use array elements with constant values as guideposts ("markers", such as the "." in Figure 1) for isolating the variable elements that need further validation at the CDDL data model level. Therefore, it is recommended to limit the use of .join to simple arrangements where the array elements are laid out explicitly and there are no adjacent variable elements without intervening constant values, and where these constant values do not occur within the text described by the variable elements. If more complex parsing functionality is required, the ABNF control operators (see Section 3 of [RFC9165]) may be useful; however, these cannot reach back into CDDL-specified elements like .join can.
このコントロール演算子は、最も一般的なケースで検証するのが難しいことに注意してください。これには完全なパーサー機能が必要であるためです。単純な実装戦略では、CDDLデータモデルレベルでさらに検証する必要がある変数要素を分離するために、ガイドポスト（図1のような「マーカー」」として一定の値のアレイ要素を使用します。したがって、Array要素が明示的にレイアウトされ、一定の値に介入することなく隣接する変数要素がなく、可変要素で記述されたテキスト内でこれらの定数値が発生しない場合、.thing on of。o. on of o.Joinを単純な配置に制限することをお勧めします。より複雑な解析機能が必要な場合、ABNF制御演算子（[RFC9165]のセクション3を参照）が役立つ場合があります。ただし、これらは.Join CanのようなCDDL指定の要素に戻ることはできません。
Implementation note: A validator implementation can use the marker elements to scan the text and isolate the variable elements. It also can build a parsing regexp from the elements of the controller array, with capture groups for each element, and validate the captures against the elements of the array. (For more about parsing regexps, see Section 6 of [RFC9485]; see also Section 8 of [RFC9485] for security considerations related to regexps.) In the most general case, these implementation strategies can exhibit false negatives, where the implementation cannot find the structure that would be successfully validated using the controller; it is RECOMMENDED that implementations provide full coverage at least for the marker-based subset outlined in the previous paragraph.
実装注：バリデーターの実装は、マーカー要素を使用してテキストをスキャンし、変数要素を分離できます。また、各要素のキャプチャグループを使用して、コントローラーアレイの要素から解析の再遺伝子を構築し、配列の要素に対してキャプチャを検証することもできます。（修理の解析の詳細については、[RFC9485]のセクション6を参照してください。レジクスに関連するセキュリティ上の考慮事項については、[RFC9485]のセクション8も参照してください。）最も一般的なケースでは、これらの実装戦略は、コントローラーを使用して正常に検証される構造を実装できない誤ったネガを示すことができます。少なくとも前の段落で概説されているマーカーベースのサブセットには、実装が完全なカバレッジを提供することをお勧めします。
IANA has registered the contents of Table 7 into the "CDDL Control Operators" registry of [IANA.cddl]:
IANAは、[IANA.CDDL]の「CDDL制御演算子」レジストリに表7の内容を登録しました。
+==============+===========+
| Name | Reference |
+==============+===========+
| .b64u | RFC 9741 |
+--------------+-----------+
| .b64u-sloppy | RFC 9741 |
+--------------+-----------+
| .b64c | RFC 9741 |
+--------------+-----------+
| .b64c-sloppy | RFC 9741 |
+--------------+-----------+
| .b45 | RFC 9741 |
+--------------+-----------+
| .b32 | RFC 9741 |
+--------------+-----------+
| .h32 | RFC 9741 |
+--------------+-----------+
| .hex | RFC 9741 |
+--------------+-----------+
| .hexlc | RFC 9741 |
+--------------+-----------+
| .hexuc | RFC 9741 |
+--------------+-----------+
| .base10 | RFC 9741 |
+--------------+-----------+
| .printf | RFC 9741 |
+--------------+-----------+
| .json | RFC 9741 |
+--------------+-----------+
| .join | RFC 9741 |
+--------------+-----------+
Table 7: New Control Operators
表7：新しい制御演算子
The security considerations in Section 5 of [RFC8610] apply. In addition, for the control operators defined in Section 2.1, the security considerations in Section 12 of [RFC4648] apply.
[RFC8610]のセクション5のセキュリティ上の考慮事項が適用されます。さらに、セクション2.1で定義されている制御演算子には、[RFC4648]のセクション12のセキュリティ上の考慮事項が適用されます。
[C] International Organization for Standardization,
"Information technology - Programming languages - C",
Fourth Edition, ISO/IEC 9899:2024, October 2024,
<https://www.iso.org/standard/82075.html>. Technically
equivalent specification text is available at
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/
n3220.pdf>.
[IANA.cddl]
IANA, "Concise Data Definition Language (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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[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>.
[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>.
[RFC9165] Bormann, C., "Additional Control Operators for the Concise
Data Definition Language (CDDL)", RFC 9165,
DOI 10.17487/RFC9165, December 2021,
<https://www.rfc-editor.org/info/rfc9165>.
[RFC9285] Fältström, P., Ljunggren, F., and D.W. van Gulik, "The
Base45 Data Encoding", RFC 9285, DOI 10.17487/RFC9285,
August 2022, <https://www.rfc-editor.org/info/rfc9285>.
[RFC9485] Bormann, C. and T. Bray, "I-Regexp: An Interoperable
Regular Expression Format", RFC 9485,
DOI 10.17487/RFC9485, October 2023,
<https://www.rfc-editor.org/info/rfc9485>.
[STD90] Internet Standard 90,
<https://www.rfc-editor.org/info/std90>.
At the time of writing, this STD comprises the following:
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:
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>.
[RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text
Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,
<https://www.rfc-editor.org/info/rfc7464>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR)
Tags for Object Identifiers", RFC 9090,
DOI 10.17487/RFC9090, July 2021,
<https://www.rfc-editor.org/info/rfc9090>.
Figure 1: Using the .join Operator to Build Dotted-Decimal IPv4 Addresses
図1：.join演算子を使用して、点線のIPv4アドレスを構築する
Table 1: Summary of New Control Operators in This Document
表1：このドキュメントの新しい制御演算子の概要
Table 2: Control Operators for Text Conversion of Byte Strings
表2：バイト文字列のテキスト変換のための制御演算子
Table 3: Control Operator for Text Conversion of Integers
表3：整数のテキスト変換のための制御演算子
Table 4: Control Operator for Printf-Style Formatting of Data Item(s)
表4：データ項目のprintfスタイルのフォーマットのための制御演算子
Table 5: Control Operator for Text Conversion of JSON Values
表5：JSON値のテキスト変換のためのコントロール演算子
Table 6: Control Operator for Text Generation from Arrays
表6：アレイからのテキスト生成の制御演算子
Table 7: New Control Operators
表7：新しい制御演算子
Henk Birkholz suggested the need for many of the control operators defined here. The author would like to thank Laurence Lundblade and Jeremy O'Donoghue for sharpening some of the mandates, Mikolai Gütschow for improvements to some examples, A.J. Stein for serving as shepherd for this document and for his shepherd review, the IESG and Directorate reviewers (notably Ari Keränen, Darrel Miller, and Éric Vyncke), and Orie Steele for serving as responsible AD and for providing a detailed AD review.
Henk Birkholzは、ここで定義されている多くの制御オペレーターの必要性を示唆しました。著者は、いくつかの任務のいくつかをシャープにしてくれたLaurence LundbladeとJeremy O'Donoghueに感謝したいと思います。この文書と彼の羊飼いのレビュー、IESGおよび監督のレビュアー（特にアリケラネン、ダレルミラー、エリックヴィンケ）、および責任ある広告を提供し、詳細な広告レビューを提供するために、彼の羊飼いのレビュー、IESGおよび監督のレビュー担当者のために奉仕するスタイン。
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org