Hi Carsten, We updated the link in the [C] reference entry and marked your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9741).
Thank you for your attention and guidance during the AUTH48 process. We will begin to prepare this document for publication. 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) Best regards, RFC Editor/rv > On Feb 28, 2025, at 9:10 PM, Carsten Bormann <c...@tzi.org> wrote: > > Hi Rebecca, > > On 28. Feb 2025, at 21:07, Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: >> >> It looks like the issue is still open: >> https://github.com/ietf-tools/xml2rfc/issues/1120 > > Oh. > >> For this document, what do you think about using the direct link rather than >> the archive link? We tested it out, and the spurious blank space doesn’t >> appear with the direct link. >> >> See: >> https://www.rfc-editor.org/authors/rfc9741-TEST.txt >> https://www.rfc-editor.org/authors/rfc9741-TEST.html >> https://www.rfc-editor.org/authors/rfc9741-TEST.pdf > > Good idea, this definitely works for me. > Many people will know how to use the wayback machine if the direct link > ceases to work at some point. > (If all else fails, they’ll find it through the Wikipedia page for C23…) > > I believe with this change RFC-to-be 9741 is now ready for publication. > > Grüße, Carsten > > >> Best regards, >> RFC Editor/rv >> >> >> >>> On Feb 28, 2025, at 7:32 AM, Carsten Bormann <c...@tzi.org> wrote: >>> >>> Hi Rebecca, >>> >>> thank you for the update and for explaining the RPC’s updated stance on BCP >>> 14 referencing. >>> >>> I have only one remaining problem: >>> >>> OLD: >>> equivalent specification text is available at >>> <https://web.archive.org/web/20250212071536/ >>> https://www.open- std.org/jtc1/sc22/wg14/www/docs/ >>> n3220.pdf>. >>> NEW: >>> equivalent specification text is available at >>> <https://web.archive.org/web/20250212071536/ >>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/ >>> n3220.pdf>. >>> >>> (Please remove the spurious blank space between open- and std.) >>> This problem only occurs in the plaintext form (although the HTML form also >>> does slightly surprising reformatting around this hyphen when the window >>> width is varied). >>> >>> I seem to remember we had received an xml2rfc fix for a similar problem >>> before, so I’m surprised at this spurious blank space (re-)occurring. >>> Unfortunately, my usual workaround (including a U+2028 at the start of the >>> annotation element) no longer seems to work with the plaintext form (which >>> is another bug that we now do not need to address). >>> >>> With this spurious blank space removed, I believe RFC 9741-to-be is ready >>> for publication. >>> >>> Thank you! >>> >>> Grüße, Carsten >>> >>> >>> >>>> On 28. Feb 2025, at 02:24, Rebecca VanRheenen >>>> <rvanrhee...@staff.rfc-editor.org> wrote: >>>> >>>> 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
