rfc9741v1.txt | rfc9741.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) C. Bormann | Internet Engineering Task Force (IETF) C. Bormann | |||
Request for Comments: 9741 Universität Bremen TZI | Request for Comments: 9741 Universität Bremen TZI | |||
Category: Standards Track February 2025 | Category: Standards Track March 2025 | |||
ISSN: 2070-1721 | ISSN: 2070-1721 | |||
Concise Data Definition Language (CDDL): Additional Control Operators | Concise Data Definition Language (CDDL): Additional Control Operators | |||
for the Conversion and Processing of Text | for the Conversion and Processing of Text | |||
Abstract | Abstract | |||
The Concise Data Definition Language (CDDL), standardized in RFC | The Concise Data Definition Language (CDDL), standardized in RFC | |||
8610, provides "control operators" as its main language extension | 8610, provides "control operators" as its main language extension | |||
point. RFCs have added to this extension point in both an | point. RFCs have added to this extension point in both an | |||
application-specific and a more general way. | application-specific and a more general way. | |||
The present document defines a number of additional generally | The present document defines a number of additional generally | |||
applicable control operators for text conversion (bytes, integers, | applicable control operators for text conversion (bytes, integers, | |||
Printf-style formatting, and JSON) and for an operation on text. | printf-style formatting, and JSON) and for an operation on text. | |||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | Internet Standards is available in Section 2 of RFC 7841. | |||
skipping to change at line 80 ¶ | skipping to change at line 80 ¶ | |||
1. Introduction | 1. Introduction | |||
The Concise Data Definition Language (CDDL), standardized in | The Concise Data Definition Language (CDDL), standardized in | |||
[RFC8610], provides "control operators" as its main language | [RFC8610], provides "control operators" as its main language | |||
extension point (Section 3.8 of [RFC8610]). RFCs have added to this | extension point (Section 3.8 of [RFC8610]). RFCs have added to this | |||
extension point in both an application-specific [RFC9090] and a more | extension point in both an application-specific [RFC9090] and a more | |||
general [RFC9165] way. | general [RFC9165] way. | |||
The present document defines a number of additional generally | The present document defines a number of additional generally | |||
applicable control operators: | 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). | ||||
+===============+=========+=======+==============================+ | +===============+=========+=======+==============================+ | |||
| Name | t | c | Purpose | | | Name | t | c | Purpose | | |||
+===============+=========+=======+==============================+ | +===============+=========+=======+==============================+ | |||
| .b64u, .b64c | text | bytes | Base64 representation of | | | .b64u, .b64c | text | bytes | Base64 representation of | | |||
| | | | byte strings | | | | | | byte strings | | |||
+---------------+---------+-------+------------------------------+ | +---------------+---------+-------+------------------------------+ | |||
| .b64u-sloppy, | text | bytes | (sloppy-tolerant variants of | | | .b64u-sloppy, | text | bytes | Sloppy-tolerant variants of | | |||
| .b64c-sloppy | | | the above) | | | .b64c-sloppy | | | the above | | |||
+---------------+---------+-------+------------------------------+ | +---------------+---------+-------+------------------------------+ | |||
| .hex, .hexlc, | text | bytes | Base16 representation of | | | .hex, .hexlc, | text | bytes | Base16 representation of | | |||
| .hexuc | | | byte strings | | | .hexuc | | | byte strings | | |||
+---------------+---------+-------+------------------------------+ | +---------------+---------+-------+------------------------------+ | |||
| .b32, .h32 | text | bytes | Base32 representation of | | | .b32, .h32 | text | bytes | Base32 representation of | | |||
| | | | byte strings | | | | | | byte strings | | |||
+---------------+---------+-------+------------------------------+ | +---------------+---------+-------+------------------------------+ | |||
| .b45 | text | bytes | Base45 representation of | | | .b45 | text | bytes | Base45 representation of | | |||
| | | | byte strings | | | | | | byte strings | | |||
+---------------+---------+-------+------------------------------+ | +---------------+---------+-------+------------------------------+ | |||
skipping to change at line 113 ¶ | skipping to change at line 115 ¶ | |||
| .printf | text | array | Printf-formatted text | | | .printf | text | array | Printf-formatted text | | |||
| | | | representation of data items | | | | | | representation of data items | | |||
+---------------+---------+-------+------------------------------+ | +---------------+---------+-------+------------------------------+ | |||
| .json | text | any | Text representation of JSON | | | .json | text | any | Text representation of JSON | | |||
| | | | values | | | | | | values | | |||
+---------------+---------+-------+------------------------------+ | +---------------+---------+-------+------------------------------+ | |||
| .join | text or | array | Build text or byte string | | | .join | text or | array | Build text or byte string | | |||
| | bytes | | from array of components | | | | bytes | | from array of components | | |||
+---------------+---------+-------+------------------------------+ | +---------------+---------+-------+------------------------------+ | |||
Table 1: Summary of New Control Operators in This Document, t | Table 1: Summary of New Control Operators in This Document | |||
= target type (left-hand side), c = controller type (right- | ||||
hand side) | ||||
1.1. Terminology | 1.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
Regular expressions mentioned in the text are as defined in | Regular expressions mentioned in the text are as defined in | |||
[RFC9485]. | [RFC9485]. | |||
This specification uses terminology from [RFC8610]. In particular, | This specification uses terminology from [RFC8610]. In particular, | |||
with respect to control operators, "target" refers to the left-hand- | with respect to control operators, "target" refers to the left-hand- | |||
side operand and "controller" to the right-hand-side operand. "Tool" | side operand and "controller" to the right-hand-side operand. "Tool" | |||
refers to tools along the lines of that described in Appendix F of | refers to tools along the lines of that described in Appendix F of | |||
[RFC8610]. Note also that the data model underlying CDDL provides | [RFC8610]. Note also that the data model underlying CDDL provides | |||
for text strings as well as byte strings as two separate types, which | for text strings as well as byte strings as two separate types, which | |||
are then collectively referred to as "strings". | are then collectively referred to as "strings". | |||
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. | ||||
2. Text Conversion | 2. Text Conversion | |||
2.1. Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64 | 2.1. Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64 | |||
A CDDL model often defines data that are byte strings in essence but | 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 | need to be transported in various encoded forms, such as base64 or | |||
hex. This section defines a number of control operators to model | hex. This section defines a number of control operators to model | |||
these conversions. | these conversions. | |||
The control operators generally are of a form that could be used like | The control operators generally are of a form that could be used like | |||
this: | this: | |||
signature-for-json = text .b64u signature | signature-for-json = text .b64u signature | |||
signature = bytes .cbor COSE_Sign1 | signature = bytes .cbor COSE_Sign1 | |||
The specification of these control operators is complicated by the | The specification of these control operators cannot provide full | |||
large number of transformations in use. Inspired by Section 8 of RFC | coverage of the large number of transformations in use; it focuses on | |||
8949 [STD94], this specification uses the representations defined in | [RFC4648] and additionally [RFC9285], as shown in Table 2. For the | |||
[RFC4648] with the following names: | representations defined in [RFC4648], this specification uses names | |||
as inspired by Section 8 of RFC 8949 [STD94]: | ||||
+==============+=======================+========================+ | +==============+===========================+========================+ | |||
| Name | Meaning | Reference | | | Name | Meaning | Reference | | |||
+==============+=======================+========================+ | +==============+===========================+========================+ | |||
| .b64u | Base64url, no padding | Section 5 of [RFC4648] | | | .b64u | Base64url, no padding | Section 5 of | | |||
+--------------+-----------------------+------------------------+ | | | | [RFC4648] | | |||
| .b64u-sloppy | Base64url, no | Section 5 of [RFC4648] | | +--------------+---------------------------+------------------------+ | |||
| | padding, sloppy | | | | .b64u-sloppy | Base64url, no padding, | Section 5 of | | |||
+--------------+-----------------------+------------------------+ | | | sloppy | [RFC4648] | | |||
| .b64c | Base64 classic, | Section 4 of [RFC4648] | | +--------------+---------------------------+------------------------+ | |||
| | padding | | | | .b64c | Base64 classic, padding | Section 4 of | | |||
+--------------+-----------------------+------------------------+ | | | | [RFC4648] | | |||
| .b64c-sloppy | Base64 classic, | Section 4 of [RFC4648] | | +--------------+---------------------------+------------------------+ | |||
| | padding, sloppy | | | | .b64c-sloppy | Base64 classic, padding, | Section 4 of | | |||
+--------------+-----------------------+------------------------+ | | | sloppy | [RFC4648] | | |||
| .b32 | Base32, no padding | Section 6 of [RFC4648] | | +--------------+---------------------------+------------------------+ | |||
+--------------+-----------------------+------------------------+ | | .b32 | Base32, no padding | Section 6 of | | |||
| .h32 | Base32/hex alphabet, | Section 7 of [RFC4648] | | | | | [RFC4648] | | |||
| | no padding | | | +--------------+---------------------------+------------------------+ | |||
+--------------+-----------------------+------------------------+ | | .h32 | Base32 with "Extended | Section 7 of | | |||
| .hex | Base16 (hex), either | Section 8 of [RFC4648] | | | | Hex" alphabet, no padding | [RFC4648] | | |||
| | case | | | +--------------+---------------------------+------------------------+ | |||
+--------------+-----------------------+------------------------+ | | .hex | Base16 (hex), either case | Section 8 of | | |||
| .hexlc | Base16 (hex), lower | Section 8 of [RFC4648] | | | | | [RFC4648] | | |||
| | case | | | +--------------+---------------------------+------------------------+ | |||
+--------------+-----------------------+------------------------+ | | .hexlc | Base16 (hex), lower case | Section 8 of | | |||
| .hexuc | Base16 (hex), upper | Section 8 of [RFC4648] | | | | | [RFC4648] | | |||
| | case | | | +--------------+---------------------------+------------------------+ | |||
+--------------+-----------------------+------------------------+ | | .hexuc | Base16 (hex), upper case | Section 8 of | | |||
| .b45 | Base45 | [RFC9285] | | | | | [RFC4648] | | |||
+--------------+-----------------------+------------------------+ | +--------------+---------------------------+------------------------+ | |||
| .b45 | Base45 | [RFC9285] | | ||||
+--------------+---------------------------+------------------------+ | ||||
Table 2: Control Operators for Text Conversion of Byte Strings | Table 2: Control Operators for Text Conversion of Byte Strings | |||
Note that this specification is somewhat opinionated here: It does | Note that this specification is somewhat opinionated here: It does | |||
not provide base64url, base32, or base32hex encoding with padding, or | not provide base64url or base32(hex) encoding with padding or base64 | |||
base64 classic without padding. Experience indicates that these | classic without padding. Experience indicates that these | |||
combinations only ever occur in error, so the usability of CDDL is | combinations only ever occur in error, so the usability of CDDL is | |||
increased by not providing them in the first place. Also, adding "c" | increased by not providing them in the first place. Also, adding "c" | |||
makes sure that any decision for classic base64 is actively taken. | makes sure that any decision for classic base64 is actively taken. | |||
These control operators are "strict" in their matching, i.e., they | These control operators are "strict" in their matching, i.e., they | |||
only match base encodings that conform to the mandates of their | only match base encodings that conform to the mandates of their | |||
defining documents. Note that this also means that .b64u and .b64c | defining documents. Note that this also means that .b64u and .b64c | |||
only match text strings composed of the set of characters defined for | only match text strings composed of the set of characters defined for | |||
each of them, respectively. (This is perhaps worth pointing out | each of them, respectively. (This is perhaps worth pointing out | |||
explicitly as it contrasts with the "b64" literal prefix that can be | explicitly as it contrasts with the "b64" literal prefix that can be | |||
used to notate byte strings in CDDL source code, which simply accepts | used to notate byte strings in CDDL source code, which simply accepts | |||
characters from either alphabet. This behavior is different from the | characters from either alphabet. This behavior is different from the | |||
matching behavior of the four base64 control operators defined here.) | matching behavior of the four base64 control operators defined here.) | |||
The additional designation "sloppy" indicates that the text string is | The additional designation "sloppy" indicates that the text string is | |||
not validated for any additional bits being zero, in variance to what | not validated for any additional bits being zero, in variance to what | |||
is specified in the paragraph behind Table 1 in Section 4 of | is specified in the paragraph that follows Table 1 in Section 4 of | |||
[RFC4648]. Note that the present specification is opinionated again | [RFC4648]. Note that the present specification is opinionated again | |||
in not specifying a sloppy variant of base32 or base32/hex, as no | 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. | legacy use of sloppy base32(hex) was known at the time of writing. | |||
Base45 [RFC9285] is known to be suboptimal for use in environments | Base45 [RFC9285] is known to be suboptimal for use in environments | |||
with limited data transparency (such as URLs) but is included because | with limited data transparency (such as URLs) but is included because | |||
of its close relationship to QR codes and its wide use in health | of its close relationship to QR codes and its wide use in health | |||
informatics (note that base45 is strongly specified not to allow | informatics (note that base45 is strongly specified not to allow | |||
sloppy forms of encoding). | sloppy forms of encoding). | |||
2.2. Numerals | 2.2. Numerals | |||
+=========+============================+===========+ | +=========+============================+===========+ | |||
| Name | Meaning | Reference | | | Name | Meaning | Reference | | |||
skipping to change at line 239 ¶ | skipping to change at line 249 ¶ | |||
The control operator .base10 allows the modeling of text strings that | The control operator .base10 allows the modeling of text strings that | |||
carry an integer number in decimal form (as a text string with digits | 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 | in the usual base-ten positional numeral system), such as in the | |||
uint64/int64 formats of YANG-JSON [RFC7951]. | uint64/int64 formats of YANG-JSON [RFC7951]. | |||
yang-json-sid = text .base10 (0..9223372036854775807) | yang-json-sid = text .base10 (0..9223372036854775807) | |||
Again, the specification is opinionated by only providing for integer | Again, the specification is opinionated by only providing for integer | |||
numbers represented without leading zeros, i.e., the decimal integer | numbers represented without leading zeros, i.e., the decimal integer | |||
numerals match the regular expression 0|-?[1-9][0-9]* (of course, | numerals match the regular expression 0|-?[1-9][0-9]* (of course, | |||
this is further restricted by the control type). See the next | this is further restricted by the control type). See Section 2.3 for | |||
section for more flexibility and for other numeric bases such as | more flexibility and for other numeric bases such as octal, | |||
octal, hexadecimal, or binary conversions. | hexadecimal, or binary conversions. | |||
Note that this control operator governs text representations of | Note that this control operator governs text representations of | |||
integers and should not be confused with the control operators | integers and should not be confused with the control operators | |||
governing text representations of byte strings (such as b64u). This | governing text representations of byte strings (such as .b64u). This | |||
contrast is somewhat reinforced by spelling out "base" in the name | contrast is somewhat reinforced by spelling out "base" in the name | |||
base10 as opposed to those of the byte string operators. | .base10 as opposed to those of the byte string operators. | |||
2.3. Printf-Style Formatting | 2.3. Printf-Style Formatting | |||
+=========+===================================+===========+ | +=========+=========================================+===========+ | |||
| Name | Meaning | Reference | | | Name | Meaning | Reference | | |||
+=========+===================================+===========+ | +=========+=========================================+===========+ | |||
| .printf | Printf-formatting of data item(s) | --- | | | .printf | Printf-style formatting of data item(s) | --- | | |||
+---------+-----------------------------------+-----------+ | +---------+-----------------------------------------+-----------+ | |||
Table 4: Control Operator for Printf-Formatting of Data | Table 4: Control Operator for Printf-Style Formatting of Data | |||
Item(s) | Item(s) | |||
The control operator .printf allows the modeling of text strings that | The control operator .printf allows the modeling of text strings that | |||
carry various formatted information, as long as the format can be | carry various formatted information, as long as the format can be | |||
represented in Printf-style formatting strings as they are used in | represented in printf-style formatting strings as they are used in | |||
the C language (see Section 7.21.6.1 of [C]). | 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). | ||||
The controller (right-hand side) of the .printf control is an array | 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 | of one printf-style format string and zero or more data items that | |||
fit the individual conversion specifications in the format string. | fit the individual conversion specifications in the format string. | |||
The construct matches a text string representing the textual output | The construct matches a text string representing the textual output | |||
of an equivalent C-language printf function call that is given the | of an equivalent C-language printf function call that receives as | |||
format string and the data items following it in the array. | arguments the format string and the data items following it in the | |||
array. | ||||
From the printf specification in the C language, length modifiers | Out of the functionality described for printf formatting in | |||
(paragraph 7) are not used and MUST NOT be included in the format | Section 7.23.6.1 of the C language specification [C], length | |||
string. The "s" conversion specifier (paragraph 8) is used to | 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 | interpolate a text string in UTF-8 form. The "c" conversion | |||
specifier (paragraph 8) represents a single Unicode scalar value as a | specifier (paragraph 8) represents a single Unicode scalar value as a | |||
UTF-8 character. The "p" and "n" conversion specifiers (paragraph 8) | UTF-8 character. The "p" and "n" conversion specifiers (paragraph 8) | |||
are not used and MUST NOT be included in the format string. | are not used and MUST NOT be included in the format string. | |||
In the following example, my_alg_19 matches the text string "0x0013": | In the following example, my_alg_19 matches the text string "0x0013": | |||
my_alg_19 = hexlabel<19> | my_alg_19 = hexlabel<19> | |||
hexlabel<K> = text .printf (["0x%04x", K]) | hexlabel<K> = text .printf (["0x%04x", K]) | |||
skipping to change at line 336 ¶ | skipping to change at line 349 ¶ | |||
right-hand side of the .json control operator. | right-hand side of the .json control operator. | |||
* This control operator provides no way to constrain the use of | * This control operator provides no way to constrain the use of | |||
blank space or other serialization variants in the JSON | blank space or other serialization variants in the JSON | |||
representation of the data items; restrictions on the | representation of the data items; restrictions on the | |||
serialization to specific variants (e.g., not providing for the | serialization to specific variants (e.g., not providing for the | |||
addition of any insignificant blank space and prescribing an order | addition of any insignificant blank space and prescribing an order | |||
in which map entries are serialized) could be defined in future | in which map entries are serialized) could be defined in future | |||
control operators. | control operators. | |||
* A .jsonseq is not provided in this document for [RFC7464], as no | * A .jsonseq is not provided in this document for JSON text | |||
use case for inclusion in CDDL is known at the time of writing; | sequences [RFC7464], as no use case for inclusion in CDDL is known | |||
again, future control operators could address this use case. | at the time of writing; again, future control operators could | |||
address this use case. | ||||
3. Text Processing | 3. Text Processing | |||
3.1. Join | 3.1. Join | |||
Often, text strings need to be constructed out of parts that can best | Often, text strings need to be constructed out of parts that can best | |||
be modeled as an array. | be modeled as an array. | |||
+=======+==================================+===========+ | +=======+==================================+===========+ | |||
| Name | Meaning | Reference | | | Name | Meaning | Reference | | |||
+=======+==================================+===========+ | +=======+==================================+===========+ | |||
| .join | concatenate elements of an array | --- | | | .join | Concatenate elements of an array | --- | | |||
+-------+----------------------------------+-----------+ | +-------+----------------------------------+-----------+ | |||
Table 6: Control Operator for Text Generation from | Table 6: Control Operator for Text Generation from | |||
Arrays | Arrays | |||
For example, an IPv4 address in dotted-decimal might be modeled as in | For example, an IPv4 address in dotted-decimal might be modeled as in | |||
Figure 1. | Figure 1. | |||
legacy-ip-address = text .join legacy-ip-address-elements | legacy-ip-address = text .join legacy-ip-address-elements | |||
legacy-ip-address-elements = [bytetext, ".", bytetext, ".", | legacy-ip-address-elements = [bytetext, ".", bytetext, ".", | |||
skipping to change at line 400 ¶ | skipping to change at line 414 ¶ | |||
the array elements are laid out explicitly and there are no adjacent | the array elements are laid out explicitly and there are no adjacent | |||
variable elements without intervening constant values, and where | variable elements without intervening constant values, and where | |||
these constant values do not occur within the text described by the | these constant values do not occur within the text described by the | |||
variable elements. If more complex parsing functionality is | variable elements. If more complex parsing functionality is | |||
required, the ABNF control operators (see Section 3 of [RFC9165]) may | required, the ABNF control operators (see Section 3 of [RFC9165]) may | |||
be useful; however, these cannot reach back into CDDL-specified | be useful; however, these cannot reach back into CDDL-specified | |||
elements like .join can. | elements like .join can. | |||
| Implementation note: A validator implementation can use the | | Implementation note: A validator implementation can use the | |||
| marker elements to scan the text and isolate the variable | | marker elements to scan the text and isolate the variable | |||
| elements. It also can build a parsing regexp (Section 6 of | | elements. It also can build a parsing regexp from the elements | |||
| [RFC9485]; see also Section 8 of [RFC9485] for security | | of the controller array, with capture groups for each element, | |||
| considerations related to regexps) from the elements of the | | and validate the captures against the elements of the array. | |||
| controller array, with capture groups for each element, and | | (For more about parsing regexps, see Section 6 of [RFC9485]; | |||
| validate the captures against the elements of the array. In | | see also Section 8 of [RFC9485] for security considerations | |||
| the most general case, these implementation strategies can | | related to regexps.) In the most general case, these | |||
| exhibit false negatives, where the implementation cannot find | | implementation strategies can exhibit false negatives, where | |||
| the structure that would be successfully validated using the | | the implementation cannot find the structure that would be | |||
| controller; it is RECOMMENDED that implementations provide full | | successfully validated using the controller; it is RECOMMENDED | |||
| coverage at least for the marker-based subset outlined in the | | that implementations provide full coverage at least for the | |||
| previous paragraph. | | marker-based subset outlined in the previous paragraph. | |||
4. IANA Considerations | 4. IANA Considerations | |||
IANA has registered the contents of Table 7 into the "CDDL Control | IANA has registered the contents of Table 7 into the "CDDL Control | |||
Operators" registry of [IANA.cddl]: | Operators" registry of [IANA.cddl]: | |||
+==============+===========+ | +==============+===========+ | |||
| Name | Reference | | | Name | Reference | | |||
+==============+===========+ | +==============+===========+ | |||
| .b64u | RFC 9741 | | | .b64u | RFC 9741 | | |||
skipping to change at line 454 ¶ | skipping to change at line 468 ¶ | |||
| .json | RFC 9741 | | | .json | RFC 9741 | | |||
+--------------+-----------+ | +--------------+-----------+ | |||
| .join | RFC 9741 | | | .join | RFC 9741 | | |||
+--------------+-----------+ | +--------------+-----------+ | |||
Table 7: New Control | Table 7: New Control | |||
Operators | Operators | |||
5. Security Considerations | 5. Security Considerations | |||
The security considerations in Section 5 of [RFC8610] apply, as well | The security considerations in Section 5 of [RFC8610] apply. In | |||
as those in Section 12 of [RFC4648] for the control operators defined | addition, for the control operators defined in Section 2.1, the | |||
in Section 2.1. | security considerations in Section 12 of [RFC4648] apply. | |||
6. References | 6. References | |||
6.1. Normative References | 6.1. Normative References | |||
[C] International Organization for Standardization, | [C] International Organization for Standardization, | |||
"Information technology - Programming languages - C", | "Information technology - Programming languages - C", | |||
Fourth Edition, ISO/IEC 9899:2018, June 2018, | Fourth Edition, ISO/IEC 9899:2024, October 2024, | |||
<https://www.iso.org/standard/74528.html>. Technically | <https://www.iso.org/standard/82075.html>. Technically | |||
equivalent specification text is available at | equivalent specification text is available at | |||
<https://web.archive.org/web/20181230041359if_/ | <https://www.open-std.org/jtc1/sc22/wg14/www/docs/ | |||
http://www.open- std.org/jtc1/sc22/wg14/www/abq/ | n3220.pdf>. | |||
c17_updated_proposed_fdis.pdf>. | ||||
[IANA.cddl] | [IANA.cddl] | |||
IANA, "Concise Data Definition Language (CDDL)", | IANA, "Concise Data Definition Language (CDDL)", | |||
<https://www.iana.org/assignments/cddl>. | <https://www.iana.org/assignments/cddl>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at line 552 ¶ | skipping to change at line 565 ¶ | |||
DOI 10.17487/RFC9090, July 2021, | DOI 10.17487/RFC9090, July 2021, | |||
<https://www.rfc-editor.org/info/rfc9090>. | <https://www.rfc-editor.org/info/rfc9090>. | |||
List of Figures | List of Figures | |||
Figure 1: Using the .join Operator to Build Dotted-Decimal IPv4 | Figure 1: Using the .join Operator to Build Dotted-Decimal IPv4 | |||
Addresses | Addresses | |||
List of Tables | List of Tables | |||
Table 1: Summary of New Control Operators in This Document, t = | Table 1: Summary of New Control Operators in This Document | |||
target type (left-hand side), c = controller type (right-hand side) | ||||
Table 2: Control Operators for Text Conversion of Byte Strings | Table 2: Control Operators for Text Conversion of Byte Strings | |||
Table 3: Control Operator for Text Conversion of Integers | Table 3: Control Operator for Text Conversion of Integers | |||
Table 4: Control Operator for Printf-Formatting of Data Item(s) | Table 4: Control Operator for Printf-Style Formatting of Data Item(s) | |||
Table 5: Control Operator for Text Conversion of JSON Values | Table 5: Control Operator for Text Conversion of JSON Values | |||
Table 6: Control Operator for Text Generation from Arrays | Table 6: Control Operator for Text Generation from Arrays | |||
Table 7: New Control Operators | Table 7: New Control Operators | |||
Acknowledgements | Acknowledgements | |||
Henk Birkholz suggested the need for many of the control operators | Henk Birkholz suggested the need for many of the control operators | |||
End of changes. 28 change blocks. | ||||
92 lines changed or deleted | 104 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |