Hi Carsten, Thank you for the reply! We have updated the document accordingly (see list of files below). All of our questions have been addressed.
For the paragraph about key words, we follow the exact wording in RFC 8174. The author of RFC 8174 was clear about his choice to refer to [RFC2119] and [RFC8174] rather than [BCP14], and it was confirmed with the IESG. Although referencegroup is now supported, we do not modify this prescriptive text. — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc9741.xml Updated output files: https://www.rfc-editor.org/authors/rfc9741.txt https://www.rfc-editor.org/authors/rfc9741.pdf https://www.rfc-editor.org/authors/rfc9741.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9741-auth48diff.html https://www.rfc-editor.org/authors/rfc9741-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9741-diff.html https://www.rfc-editor.org/authors/rfc9741-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9741-alt-diff.html (diff showing changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9741 Thank you, RFC Editor/rv > On Feb 27, 2025, at 1:56 AM, Carsten Bormann <c...@tzi.org> wrote: > > Hi Rebecca, > > thank you for this update. > > While skimming rfc9741.pdf for the table legend solution (see below), I > noticed that you have reverted the way we reference BCP 14 to the > pre-<referencegroup situation. The way of referencing that was recommended > in RFC 8174 was written at a time when we didn’t have <referencegroup support > in RFCXML. This is now available and supported by bib.ietf.org, and I much > prefer to use it for BCP and STD references. I believe we should follow the > solution we found in RFC 9595 for making these references in a way that is > very close to the spirit of RFC 8174, which I tried to emulate in the > approved I-D. > > (Full diff review and full reread coming up.) > > On to your questions/comments: > > On 2025-02-27, at 07:25, Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > >> […] We also have a few followup questions/comments: >> >> A) >>>> 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? >>> >>> A legend (at the end of the table) would be fine, this is what I attempted >>> to do with putting the information in the title attribute (I usually add a >>> few U+2028 which also could be <br> if not for a lingering limitation of >>> kramdown-rfc). Is there a better place to do this in rfc2xmlv3? >>> >>>> 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). >>> >>> In prose, I’d probably talk about “the column marked c”… >>> >>>> Or (add legend after table): >>>> t - target type (left-hand side) >>>> c - controller type (right-hand side) >>> >>> This is pretty much what I tried to put there (with a dash instead of an >>> equals sign, which is probably less techy). If rfc2xmlv3 is able to >>> capture such a legend, that would be optimal. >>> (A legend should visually be part of the table, which title captions are.) >> >> We can use <dl> after the table for the legend, but that may not align with >> your preference for it to be visually be part of the table. We've included >> both the prose and the <dl> options in the updated files so you can see what >> both look like. Let us know which you prefer, we’ll remove the other. > > I still believe that including the legend in the <name element of the table > as in the approved I-D is the best way to show it within the limited table > support that RFC7991+ provides. > Between the two choices you included, the “prose” (at the place of > referencing Table 1) is much better than the isolated (and somewhat > disconnected/orphaned) <dl list. > > Given that RFCXMLv3 forces the presence of table numbering, I’d further: > > OLD: > applicable control operators. In the table below, the column marked > NEW: > applicable control operators. In Table 1 below, the column marked > >> B) >>>> 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]: >>>> --> >>> >>> Such an addition seems necessary, but Section 8 of RFC 8949 does not >>> mention RFC 9285 (obviously). >>> >>> Maybe: >>> 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]. >>> For the representations defined in [RFC4648], this specification uses names >>> as inspired by Section 8 of RFC 8949 [STD94]: >>> >>> (I struggle with putting in the reference to Table 2, but maybe that >>> remains clear from the context.) >> >> We updated as you suggest above. However, if you want to include a reference >> to Table 2, perhaps it could appear at the end of the first sentence as >> below. Let us know your thoughts. >> >> Perhaps: >> 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]. > > Very good, thank you. > > Note that the current version misses the word “Section”: > OLD: > defined in [RFC4648], this specification uses names as inspired by 8 > of RFC 8949 [STD94]: > NEW: > defined in [RFC4648], this specification uses names as inspired by Section 8 > of RFC 8949 [STD94]: > > Which I think is currently represented in RFCXML as: > OLD: > specification uses names as inspired by <xref target="RFC8949" > section="8" sectionFormat="bare"/> of RFC 8949 <xref target="STD94"/>: > NEW: > specification uses names as inspired by Section <xref target="RFC8949" > section="8" sectionFormat="bare"/> of RFC 8949 <xref target="STD94"/>: > >> C) >>> The term of art “opinionated” in its current sense entered the area of >>> software engineering about 20 years ago. The text here uses the term to >>> explain that the selection of operators provided is frugal, based on >>> opinions about what the preferred (and likely) usage scenarios will be. >>> >>> Read more at: >>> https://medium.com/@stueccles/the-rise-of-opinionated-software-ca1ba0140d5b >>> https://basecamp.com/gettingreal/04.6-make-opinionated-software >>> https://medium.com/@ayaan-javed/opinionated-software-and-why-you-should-care-about-it-f63510eafeca >>> https://stackoverflow.com/questions/802050/what-is-opinionated-software >>> https://medium.com/codex/about-opinionated-software-guidance-vs-freedom-2bd66de304fe >>> >>> We had a brief discussion about the term “opinionated” in this technical >>> meaning during IESG processing of this document [1]. >>> >>> [1] <https://mailarchive.ietf.org/arch/msg/cbor/DYfBZ-xRjUuPmAQ8jVK_PGGHIS8> >>> >>> Unfortunately, I didn’t find a good single stable reference that defines >>> this term, and I didn’t want to create a forest of links like the one >>> above, so I went with John’s alternative to leave as is. >> >> Thank you for the helpful information regarding the term “opinionated”. This >> term of art has not been used in an RFC before and was new to us (and at >> least one of the ADs per the discussion you linked to). Perhaps a brief >> description of this term could be added to the Terminology section? >> >> Perhaps (using your description above): >> The term "opinionated" is used in this document to explain >> that the selection of operators provided is frugal, based on >> opinions about what the preferred (and likely) usage scenarios >> will be. >> > > Maybe expand this to: > 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. > >> D) >>>> base32/hex vs. base32(/hex) vs. base32hex >>> >>> »base32(/hex)« is meant as a shorthand for »base32 or base32/hex« >>> Maybe we should use this shorthand right after the table to get rid of one >>> variant: >>> >>> OLD: >>> Note that this specification is somewhat opinionated here: It does >>> not provide base64url, base32, or base32hex encoding with padding, or >>> NEW: >>> Note that this specification is somewhat opinionated here: It does >>> not provide base64url or base32(/hex) encoding with padding, or >>> >>> Now the remaining problem is that Base32/hex looks like an alternative. >>> >>> Maybe: >>> >>> OLD: >>> | .h32 | Base32/hex alphabet, | Section 7 of [RFC4648] | >>> NEW: >>> | .h32 | Base32 with "Extended Hex" alphabet, | Section 7 of >>> [RFC4648] | >> >> Should "base32/hex” in the sentence below also be updated to "base32(/hex)”? >> >> Current: >> 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. > > We could change this into > > Maybe not: > Note that the present specification is opinionated again > in not specifying a sloppy variant of base32(/hex), as no > legacy use of sloppy base32(/hex) was known at the time of writing. > > But that would miss out on the (implicit) explanation of what we mean by > base32(/hex), i.e., both base32 and base32/hex. > > I’m starting to believe that the slash we included in our spelled out name > might be confused with the expression of an alternative, and we should stick > with “base32hex” (possibly in title case) as proposed in Section 7 of RFC > 4648. We then could simplify “base32(/hex)” into “base32(hex)”: > > OLD: > Note that this specification is somewhat opinionated here: It does > not provide base64url, base32, or base32(/hex) encoding with padding, > NEW: > Note that this specification is somewhat opinionated here: It does > not provide base64url or base32(hex) encoding with padding, > > OLD: > 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. > NEW: > 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. > > Thank you! > > Grüße, Carsten > > >> — FILES (please refresh) — >> >> Updated XML file: >> https://www.rfc-editor.org/authors/rfc9741.xml >> >> Updated output files: >> https://www.rfc-editor.org/authors/rfc9741.txt >> https://www.rfc-editor.org/authors/rfc9741.pdf >> https://www.rfc-editor.org/authors/rfc9741.html >> >> Diff files showing all changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9741-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9741-auth48rfcdiff.html (side by side) >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9741-diff.html >> https://www.rfc-editor.org/authors/rfc9741-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9741-alt-diff.html (diff showing >> changes where text is moved or deleted) >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9741 >> >> Thank you, >> RFC Editor/rv >> >> >> >>> On Feb 22, 2025, at 5:32 AM, Carsten Bormann <c...@tzi.org> wrote: >>> >>> Dear RFC-Editor, >>> >>> I will start by answering your questions and then continue with reviews of >>> changes and a full reread. >>> >>> On 2025-02-21, at 07:51, rfc-edi...@rfc-editor.org wrote: >>>> >>>> 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? >>> >>> A legend (at the end of the table) would be fine, this is what I attempted >>> to do with putting the information in the title attribute (I usually add a >>> few U+2028 which also could be <br> if not for a lingering limitation of >>> kramdown-rfc). Is there a better place to do this in rfc2xmlv3? >>> >>>> 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). >>> >>> In prose, I’d probably talk about “the column marked c”… >>> >>>> Or (add legend after table): >>>> t - target type (left-hand side) >>>> c - controller type (right-hand side) >>> >>> This is pretty much what I tried to put there (with a dash instead of an >>> equals sign, which is probably less techy). If rfc2xmlv3 is able to >>> capture such a legend, that would be optimal. >>> (A legend should visually be part of the table, which title captions are.) >>> >>>> --> >>>> >>>> >>>> 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 >>>> --> >>> >>> No, the parentheses are not needed. Thank you for pointing this out. >>> >>>> 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? >>> >>> The intention was that Tables 2 to 6 should all have the same structure >>> (they are essentially a big table split up into Tables for different >>> subsections). >>> >>> The reference column is most important for Table 2. >>> >>>> 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. >>>> --> >>> >>> The intention is that the registry points to this RFC, and this RFC points >>> to the relevant base specifications as well as contains information on how >>> to make the base specification fit. So the indirection is indeed >>> intentional. >>> >>>> >>>> 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]: >>>> --> >>> >>> Such an addition seems necessary, but Section 8 of RFC 8949 does not >>> mention RFC 9285 (obviously). >>> >>> Maybe: >>> 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]. >>> For the representations defined in [RFC4648], this specification uses names >>> as inspired by Section 8 of RFC 8949 [STD94]: >>> >>> (I struggle with putting in the reference to Table 2, but maybe that >>> remains clear from the context.) >>> >>>> 5) <!-- [rfced] The following sentences include "specification is >>>> opinionated". As a specification cannot be opinionated (a person can), >>> >>> Actually, that is an interesting opinion (which I do not share, at least >>> not when we are discussing the technical term for the area of software >>> engineering). >>> >>> The term of art “opinionated” in its current sense entered the area of >>> software engineering about 20 years ago. The text here uses the term to >>> explain that the selection of operators provided is frugal, based on >>> opinions about what the preferred (and likely) usage scenarios will be. >>> >>> Read more at: >>> https://medium.com/@stueccles/the-rise-of-opinionated-software-ca1ba0140d5b >>> https://basecamp.com/gettingreal/04.6-make-opinionated-software >>> https://medium.com/@ayaan-javed/opinionated-software-and-why-you-should-care-about-it-f63510eafeca >>> https://stackoverflow.com/questions/802050/what-is-opinionated-software >>> https://medium.com/codex/about-opinionated-software-guidance-vs-freedom-2bd66de304fe >>> >>> >>> We had a brief discussion about the term “opinionated” in this technical >>> meaning during IESG processing of this document [1]. >>> >>> [1] <https://mailarchive.ietf.org/arch/msg/cbor/DYfBZ-xRjUuPmAQ8jVK_PGGHIS8> >>> >>> Unfortunately, I didn’t find a good single stable reference that defines >>> this term, and I didn’t want to create a forest of links like the one >>> above, so I went with John’s alternative to leave as is. >>> >>>> 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..."). >>> >>> That would not be quite right (I do have my own opinions, but those the WG >>> adopted are of interest here). >>> >>>> 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, >>>> --> >>> >>> This loses the aspect that the decisions made here weren’t arbitrary, but >>> that they reflect a selection based on current views about good usage (and >>> that, if we missed out on something important, there is no fundamental >>> reason they cannot be amended by adding in further operators later). >>> >>>> 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]. >>>> --> >>> >>> “after" is fine, as is “following”. >>> >>> Maybe: >>> 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 text that follows 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]. >>>> --> >>> >>> YANG-JSON is the shorthand term that is now widely used (with YANG-XML >>> [RFC7950] and YANG-CBOR [RFC9254]; a quick check finds 11 I-Ds [plus some >>> 25 duplicates for different revisions] that use the term YANG-JSON — >>> interesting that this document appears to be the first one to make it to >>> AUTH48). >>> >>>> 8) <!-- [rfced] We believe "next section" here refers to Section 2.3. May >>>> we >>>> update accordingly? >>> >>> Yes, please. >>> >>>> Also, we see "conversion" and "hex" in Section 2.3 >>>> but not "octal" or "binary". Will this cause any issues for readers? >>> >>> Readers will most likely be familiar with the widely used printf syntax. >>> The text in 2.3 only mentions differences, and there are none in %x, %o, %b >>> (hex, octal, binary) — the syllable hex occurs in an example. >>> >>> But you are on to something here! >>> >>> %b wasn’t in the original 1970s' C library and, after being widely >>> available in implementations for a long time, was only finally added to the >>> formal standard in C23 (and in C++23). >>> Since we reference the C standard ISO/IEC 9899 for details, the reference >>> needs to go to ISO/IEC 9899:2024 (C23), preferably via the non-paywalled >>> N3220 final working draft [c23], and not to ISO/IEC 9899:2018 (C17) to >>> actually include this. >>> >>> So, in Section 2.3: >>> OLD: >>> Section 7.21.6.1 of [C] >>> NEW: >>> Section 7.23.6.1 of [C] >>> >>> We maybe also should include a note: >>> >>> OLD: >>> Section 7.21.6.1 of [C] >>> NEW: >>> Section 7.23.6.1 of [C]; note that the “C23" standard includes %b and %B >>> for formatting into binary digits >>> >>> [c23]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf >>> >>> If you don’t trust the longevity of the above, maybe use: >>> >>> https://web.archive.org/web/20250212071536/https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf >>> >>>> 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. >>>> --> >>> >>> Probably. Please use <tt for the operator names in this case. >>> >>>> >>>> 10) <!-- [rfced] Should "printf" in these sentences be updated to either >>>> "Printf" >>>> (capitalized) or ".printf" (prefaced with dot)? >>> >>> When we talk about the C language library function, it needs to be “printf” >>> (lower case, just the name). (This is true in general for languages that >>> are case-sensitive, as most modern languages are.) >>> >>>> Also, in the first >>>> sentence, will "that is given" be clear to readers? >>> >>> Hmm. >>> >>>> 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. >>> >>> Maybe: >>> 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. >>> >>> Slightly twisted, but putting “as arguments” at the end leads to stack >>> overflow. >>> >>>> 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])? >>> >>> Actually, this construct is intended to be parallel to “From the four >>> cakes, we ate the two middle ones”. >>> “Per” would be wrong because what follows is how *we* treat the subset just >>> imported. >>> “Out of” might work if we had a collective name for the features only part >>> of which we import. >>> >>>> We believe the specific paragraphs mentioned in >>>> this text are from Section 7.21.6.1 of [C]. >>> >>> (Now 7.23.6.1.) >>> >>>> We can only view the web >>>> archive link provided in the reference entry and that section uses >>>> "fprintf" (rather than "printf"). >>> >>> Right. In ISO/IEC 9899, printf is treated as just an abbreviated form of >>> fprintf, which is used to introduce the meat of its specification: >>> >>>>> 7.23.6.3 The printf function >>>>> says: […]Synopsis[…] >>>>> The printf function is equivalent to fprintf with the argument stdout >>>>> interposed before the arguments to printf. >>> >>> Implementers will generally refer to the whole family as “printf” (pars pro >>> toto), so it would be a bit weird to shorten the indirection by referring >>> to “fprintf-style formatting”. >>> >>>> 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. >>> >>> Maybe: >>> Out of the functionality described for printf formatting in >>> Section 7.21.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. >>> >>>> --> >>>> >>>> >>>> 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. >>>> --> >>> >>> We didn’t write any because these two lines should be self-explanatory in >>> this context. >>> >>>> 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. >>>> --> >>> >>> Better! >>> >>>> 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. >>>> --> >>>> >>> >>> The hyphenated usages in 9485 are adjective usages (for libraries, >>> dialects). >>> The one here is a noun and would not normally be hyphenated. >>> >>>> 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.) >>>> --> >>> >>> Much better. >>> >>>> >>>> 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. >>>> --> >>> >>> Well, it was useful at least during the review stages. >>> >>> I heard the recommendation from IANA in its early stages; it was based on >>> the assumption that a new format for these references would emerge soon. >>> >>> They have not changed for half a decade. It is hard to imagine a reason >>> why they should change, even with a new overall format is finally being >>> created. >>> >>> Note that a fragment identifier doesn’t “break” when the target document >>> changes and no longer has an anchor for it at all — the reference just >>> becomes less specific (pointing to the whole document — exactly what >>> preemptively removing the fragment identifier does, but that is proactive >>> without need). >>> >>> Anyway, I’m writing this so you know why we ignore the IANA recommendation >>> in the draft stage (the link just is very practical!), and you of course >>> need to follow the style guide, even if it is nonsensical in this specific >>> case. >>> >>>> 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. >>>> --> >>>> >>> >>> Better. >>> Not important: I’d probably do this the other way around: >>> >>> Maybe: >>> 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. >>> >>>> 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? >>> >>> (Yes, see above) >>> >>>> If so, is the web archive link provided in the >>>> annotation element still applicable? >>> >>> See [c23] above. >>> >>>> If we update to a new version, >>>> please verify that "Section 7.21.6.1 of [C]” >>> >>> (See above) >>> >>>> and the paragraph pointers >>>> in Section 3.3 are still correct. >>> >>> (2.3) >>> Yes, the paragraph pointers are. >>> (That is one *long* paragraph 8 we are referencing, but there doesn’t seem >>> to be any substructure we could reference.) >>> >>>> 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 >>> OLD: >>>> <https://web.archive.org/web/20181230041359if_/ >>>> http://www.open-std.org/jtc1/sc22/wg14/www/abq/ >>>> c17_updated_proposed_fdis.pdf>. >>> >>> NEW: >>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf>. >>>> --> >>>> >>>> >>>> 19) <!-- [rfced] FYI - We updated the format of the entries under "List of >>>> Figures" and "List of Tables". >>>> --> >>> >>> Thank you, that is good input! >>> (These lists are a new feature of kramdown-rfc, and I am going to adapt >>> this feature to what you come up with for the final form of these lists.) >>> >>> Maybe: >>> OLD: >>> <section numbered="false" anchor="list-of-tables-TEST6”> >>> NEW: >>> <section numbered="false" anchor="list-of-tables”> >>> >>> Importing the whole title for Table 1 doesn’t work well (which is one >>> reason the authoring tool does the importing now), but item (1) above is >>> likely already solving this. >>> >>>> 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 >>> >>> The latter only occurs in the text and caption of Table 4 and probably also >>> should be »Printf-style formatting«. >>> >>> There is one "Printf-formatted” in Table 1, for which the abbreviated form >>> probably still is better. >>> >>> This makes me think about the capitalization; title-case Printf maybe makes >>> sense for section titles and table captions, but in the running text of the >>> abstract and Section 2.3 not so much. >>> >>> So I’d suggest: >>> >>> (Abstract) >>> OLD: >>> applicable control operators for text conversion (bytes, integers, >>> Printf-style formatting, and JSON) and for an operation on text. >>> NEW: >>> applicable control operators for text conversion (bytes, integers, >>> printf-style formatting, and JSON) and for an operation on text. >>> >>> (Section 2.3) >>> OLD: >>> represented in Printf-style formatting strings as they are used in >>> the C language (see Section 7.21.6.1 of [C]). >>> >>> 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 >>> NEW: >>> represented in printf-style formatting strings as they are used in >>> the C language (see Section 7.21.6.1 of [C]). >>> >>> 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 >>> >>> >>>> base32/hex vs. base32(/hex) vs. base32hex >>> >>> »base32(/hex)« is meant as a shorthand for »base32 or base32/hex« >>> Maybe we should use this shorthand right after the table to get rid of one >>> variant: >>> >>> OLD: >>> Note that this specification is somewhat opinionated here: It does >>> not provide base64url, base32, or base32hex encoding with padding, or >>> NEW: >>> Note that this specification is somewhat opinionated here: It does >>> not provide base64url or base32(/hex) encoding with padding, or >>> >>> Now the remaining problem is that Base32/hex looks like an alternative. >>> >>> Maybe: >>> >>> OLD: >>> | .h32 | Base32/hex alphabet, | Section 7 of [RFC4648] | >>> NEW: >>> | .h32 | Base32 with "Extended Hex" alphabet, | Section 7 of >>> [RFC4648] | >>> >>> >>>> base-ten vs. base10 >>> >>> base10 should exclusively be used for the name of the control operator (in >>> all cases with a leading dot and in typewriter font, except for the last >>> sentence of 2.2 — but I think we should go to .base10 there as well (see >>> (9) above). >>> >>> OLD: >>> contrast is somewhat reinforced by spelling out "base" in the name >>> base10 as opposed to those of the byte string operators. >>> NEW: >>> contrast is somewhat reinforced by spelling out "base" in the name >>> .base10 as opposed to those of the byte string operators. >>> >>> (…where the .base10 is in <tt). >>> >>> Base-ten or base-ten is used in the prose defining what .base10 is, >>> referring to the well known base-ten version of the positional numeral >>> system that we all learned around the age of 6. >>> We moved to this instead of »decimal« because a lot of people think that >>> decimal is a shorthand for »decimal fraction«, and .base10 is about >>> integral and not fractional numbers. >>> >>>> 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? >>>> --> >>> >>> The cells in Table 2 to 6 are meant to use sentence case (we missed this in >>> Table 6). >>> >>> OLD: >>> | .join | concatenate elements of an array | — | >>> NEW: >>> | .join | Concatenate elements of an array | — | >>> >>>> 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. >>> >>> We had this style guide in mind (note the “blank space” for what has often >>> been termed “white space”) and are not aware of any further changes needed. >>> >>> Thank you! >>> >>> Grüße, Carsten >>> >>> >>>> >>>> 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
