Carsten,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Currently, the definitions for "t" and "c" are included in the
title of Table 1:
Original:
Table 1: Summary of New Control Operators in this Document,
t = target type (left-hand side), c = controller type (right-hand
side)
We recommend removing these definitions from the title and either 1) adding
them to the text preceding the table or 2) creating a legend below the
table. What do you prefer?
Perhaps (add to text before table):
The present document defines a number of additional generally
applicable control operators. In the table below, "t" is for "target type"
(left-hand side) and "c" is for "controller type" (right-hand side).
Or (add legend after table):
t - target type (left-hand side)
c - controller type (right-hand side)
-->
2) <!-- [rfced] In Table 1, are parentheses needed for the following? The other
fields in this column do not have parentheses.
Original:
(sloppy-tolerant variants of
the above)
Perhaps:
sloppy-tolerant variants of
the above
-->
3) <!-- [rfced] Tables
a) Tables 3, 4, and 6 have three dashes in the Reference column. Would you
like to remove this column altogether as it is empty?
b) Tables 2 and 5 contain a reference in the References column, but they are
different from the reference (i.e., his document) for the same control
operators in Table 7 in the IANA section. Will this cause any issues for
readers? Let us know if any updates are needed.
-->
4) <!-- [rfced] This sentence introduces Table 2 and mentions "representations
defined in [RFC4648]", but the last item in Table 2 is defined in RFC
9285 (not RFC 4648). May we update this sentence to include RFC 9285?
Also, would it be helpful to reorder the sentence to say "this
specification uses the following names" rather than "this specification
uses the representations"?
Original:
Inspired by Section 8 of RFC
8949 [STD94], this specification uses representations defined in
[RFC4648] with the following names:
Perhaps:
Inspired by Section 8 of RFC
8949 [STD94], this specification uses the following names for the
representations defined in [RFC4648] and [RFC9285]:
-->
5) <!-- [rfced] The following sentences include "specification is
opinionated". As a specification cannot be opinionated (a person can),
may we trim this phrasing as shown below? Another option is to revise the
text to mention the author (e.g., "the specification expresses the
author's opinoin...").
Original:
Note that this specification is somewhat opinionated here: It does
not provide base64url, base32 or base32hex encoding with padding, or
base64 classic without padding.
...
Note that the present specification is opinionated again
in not specifying a sloppy variant of base32 or base32/hex, as no
legacy use of sloppy base32(/hex) was known at the time of writing.
...
Again, the specification is opinionated by only providing for integer
numbers and these only represented without leading zeros,
Perhaps (trimmed):
Note that this specification does
not provide base64url, base32 or base32hex encoding with padding, or
base64 classic without padding.
...
Note that the present specification does
not specify a sloppy variant of base32 or base32/hex, as no
legacy use of sloppy base32(/hex) was known at the time of writing.
...
Again, the specification only provides for integer
numbers and these only represented without leading zeros,
-->
6) <!-- [rfced] "behind table 1" is unclear. Is the intent to say "after Table
1"?
Original:
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 behind table 1 in Section 4 of
[RFC4648].
Perhaps:
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 behind table 1 in Section 4 of
[RFC4648].
-->
7) <!-- [rfced] We do not see the exact term "YANG-JSON" in RFC 7951, though the
document discusses JSON encoding of YANG data. Is this text okay, or
should it be updated?
Original:
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].
-->
8) <!-- [rfced] We believe "next section" here refers to Section 2.3. May we
update accordingly? Also, we see "conversion" and "hex" in Section 2.3
but not "octal" or "binary". Will this cause any issues for readers?
Original:
See the next section for more flexibility, and for other numeric bases such
as
octal, hexadecimal, or binary conversions.
-->
9) <!-- [rfced] In the first sentence below, should "b64u" be updated to
".b64u"?
And in the second sentence, should "base10" be updated to ".base10"?
Original:
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 (b64u etc.).
...
This
contrast is somewhat reinforced by spelling out "base" in the name
base10 as opposed to those of the byte string operators.
-->
10) <!-- [rfced] Should "printf" in these sentences be updated to either
"Printf"
(capitalized) or ".printf" (prefaced with dot)? Also, in the first
sentence, will "that is given" be clear to readers?
Original:
The construct matches a text string representing the textual output
of an equivalent C-language printf function call that is given the
format string and the data items following it in the array.
...
From the printf specification in the C language, length modifiers
(paragraph 7) are not used and MUST NOT be included in the format
string.
Perhaps:
The construct matches a text string representing the textual output
of an equivalent C-language .printf function call that presents the
format string and the data items following it in the array.
...
From the .printf specification in the C language, length modifiers
(paragraph 7) are not used and MUST NOT be included in the format
string.
-->
11) <!-- [rfced] Would it be helpful to update "From the printf specification in
the C language" as shown below (e.g., change "From" to "Per" and add the
relavent section of [C])? We believe the specific paragraphs mentioned in
this text are from Section 7.21.6.1 of [C]. We can only view the web
archive link provided in the reference entry and that section uses
"fprintf" (rather than "printf").
Original:
From the printf specification in the C language, 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.
Perhaps:
Per Section 7.21.6.1 of the printf specification in the C language [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.
-->
12) <!-- [rfced] In Section 2.4, would it be helpful to include text
introducing/explaining the sourcecode? This is done with sourcecode in
other sections.
-->
13) <!-- [rfced] Should "for [RFC7464]" be updated to "for JSON text sequences
[RFC7464]" or something similar?
Original:
* A .jsonseq is not provided in this document for [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.
Perhaps:
* 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.
-->
14) <!-- [rfced] We see that "parsing-regexp" (with hyphen) is used in Section 8
of RFC 9485. Would you like to update "parsing regexp" here accordingly?
Original:
It also can build a parsing regexp (Section 6 of
[RFC9485]; see also Section 8 of [RFC9485] for security
considerations related to regexps) from the elements of the
controller array, with capture groups for each element, and
validate the captures against the elements of the array.
-->
15) <!-- [rfced] To improve readability, we suggest moving the long
parenthetical
to be its own sentence. Let us know your thoughts.
Original:
It also can build a parsing regexp (Section 6 of
[RFC9485]; see also Section 8 of [RFC9485] for security
considerations related to regexps) from the elements of the
controller array, with capture groups for each element, and
validate the captures against the elements of the array.
Perhaps:
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.)
-->
16) <!-- [rfced] FYI - In Section 4, we removed the xref with the relative
attribute. IANA has recommended against use of the registry-specific
URLs; the web portion of the style guide was recently updated to make
this more clear.
-->
17) <!-- [rfced] How may we update "Section 5 of [RFC8610] apply, as well as
those in
Section 12 of [RFC4648]" for clarity?
Original:
The security considerations in Section 5 of [RFC8610] apply, as well
as those in Section 12 of [RFC4648] for the control operators defined
in Section 2.1.
Perhaps:
The security considerations in Section 5 of [RFC8610] apply. In addition,
the security considerations
in Section 12 of [RFC4648] apply for the control operators defined
in Section 2.1.
-->
18) <!-- [rfced] The following reference is withdrawn (see
https://www.iso.org/standard/74528.html), and a new version is available
(see https://www.iso.org/standard/82075.html). Would you like to cite the
updated version? If so, is the web archive link provided in the
annotation element still applicable? If we update to a new version,
please verify that "Section 7.21.6.1 of [C]" and the paragraph pointers
in Section 3.3 are still correct.
Original:
[C] International Organization for Standardization,
"Information technology - Programming languages - C",
Fourth Edition, ISO/IEC 9899:2018, June 2018,
<https://www.iso.org/standard/74528.html>. Technically
equivalent specification text is available at
https://web.archive.org/web/20181230041359if_/
http://www.open- std.org/jtc1/sc22/wg14/www/abq/
c17_updated_proposed_fdis.pdf
(https://web.archive.org/web/20181230041359if_/
http://www.open- std.org/jtc1/sc22/wg14/www/abq/
c17_updated_proposed_fdis.pdf)
Perhaps:
[C] International Organization for Standardization,
"Information technology - Programming languages - C",
Edition 5, ISO/IEC 9899:2024, October 2024,
<https://www.iso.org/standard/82075.html>. Technically
equivalent specification text is available at
<https://web.archive.org/web/20181230041359if_/
http://www.open-std.org/jtc1/sc22/wg14/www/abq/
c17_updated_proposed_fdis.pdf>.
-->
19) <!-- [rfced] FYI - We updated the format of the entries under "List of
Figures" and "List of Tables".
-->
20) <!-- [rfced] Terminology
a) We note inconsistencies in the terms below throughout the text. Should
these be uniform? If so, please let us know which form is preferred.
Printf-style formatting vs. Printf-formatting
base32/hex vs. base32(/hex) vs. base32hex
base-ten vs. base10
b) In Table 2, would you like to lowercase "Base*" for consistency with usage
in the rest of the document? Or was the capitalization intentional here?
-->
21) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
RFC Editor/rv
Thank you.
RFC Editor/rv
On Feb 20, 2025, at 10:39 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/02/20
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9741.xml
https://www.rfc-editor.org/authors/rfc9741.html
https://www.rfc-editor.org/authors/rfc9741.pdf
https://www.rfc-editor.org/authors/rfc9741.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9741-diff.html
https://www.rfc-editor.org/authors/rfc9741-rfcdiff.html (side by side)
Alt-diff of the text (allows you to more easily view changes
where text has been deleted or moved):
https://www.rfc-editor.org/authors/rfc9741-alt-diff.html
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9741-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9741
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9741 (draft-ietf-cbor-cddl-more-control-08)
Title : Concise Data Definition Language (CDDL): Additional Control
Operators for the Conversion and Processing of Text
Author(s) : C. Bormann
WG Chair(s) : Christian Amsüss, Barry Leiba
Area Director(s) : Murray Kucherawy, Orie Steele
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
