Donald, Thank you for your reply; please see follow-ups inline below marked "AR:". The revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9804.html https://www.rfc-editor.org/authors/rfc9804.txt https://www.rfc-editor.org/authors/rfc9804.pdf https://www.rfc-editor.org/authors/rfc9804.xml
This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9804-diff.html https://www.rfc-editor.org/authors/rfc9804-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9804-auth48diff.html https://www.rfc-editor.org/authors/rfc9804-auth48rfcdiff.html (side by side) We will wait to hear from you again and from your coauthor before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9804 Re: not receiving the mails, they appear in the archive [1] [2], and we will also forward these mails to you. Please contact [email protected] regarding this issue. Hopefully they'll be able to help diagnose the problem. [1] https://mailarchive.ietf.org/arch/msg/auth48archive/BK2hbO-u725k6C7tvNtpGJvkkCY/ [2] https://mailarchive.ietf.org/arch/msg/auth48archive/1s7Nswqm35fvUxoDevmgmjw-s9k/ Thank you. RFC Editor/ar > On Jun 8, 2025, at 11:01 AM, Donald Eastlake <[email protected]> wrote: > > Hi, > > (For some reason, although I am in the "to:" line below, as far as I > can tell, I did not receive this AUTH48 email. Ron Rivest forwarded me > the copy he got so I am responding to that.) > >> From: <[email protected]> >> Date: Fri, Jun 6, 2025 at 7:40 PM >> Subject: Re: AUTH48: RFC-to-be 9804 <draft-rivest-sexp-13> for your review >> To: <[email protected]>, <[email protected]> >> Cc: <[email protected]>, <[email protected]>, >> <[email protected]>, <[email protected]> >> >> Authors, >> >> While reviewing this document during AUTH48 >> (https://www.rfc-editor.org/authors/rfc9804.html and additional >> formats), please resolve the following questions, which are also in >> the XML file. >> >> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> > > Sexp > Sexpression > S-expression > >> 2) <!--[rfced] FYI, we updated this sentence to remove "and", >> as the phrasing "[A] specifies [B] and with the intent" reads oddly. >> The first sentence of the introduction has been updated as well. >> Please let us know if you prefer otherwise. >> >> Original: >> This memo specifies the data structure representation that was >> devised to support Simple Public Key Infrastructure (SPKI, RFC 2692) >> certificates and with the intent that it be more widely applicable. >> >> Current: >> This memo specifies the data structure representation that was >> devised to support Simple Public Key Infrastructure (SPKI) >> certificates, as detailed in RFC 2692, with the intent it be >> more widely applicable. >> >> Original: >> >> Current: >> --> > > I think your current version is better. > >> 3) <!-- [rfced] For clarity, what does "They" refer to? >> Perhaps "S-expressions"? (Preceding paragraph included for context) >> >> Original: >> The S-expressions specified herein are in active use today between >> GnuPG [GnuPG] and Ribose's RNP [Ribose]. Ribose has implemented C++ >> software to compose and parse these S-expressions [RNPGP_SEXPP]. The >> GNU software is here [Libgcrypt] and there are other implementations >> (see Appendix A). >> >> They are used or referenced in the following RFCs: >> >> Perhaps: >> S-expressions are also used or referenced in the following RFCs: >> --> > > Yes, that change is fine. > >> 4) <!-- [rfced] Regarding the sourcecode elements in Sections 2, 3, 4.2, 4.4, >> and 4.5, should any of these be formatted as lists? We ask because these >> elements appear to be lists rather than formal language or pseudocode. >> (See https://authors.ietf.org/rfcxml-vocabulary#sourcecode for more details >> on this element.) >> >> Current (Section 2): >> abc - as a token >> "abc" - as a quoted string >> #616263# - as a hexadecimal string >> 3:abc - as a length-prefixed "verbatim" encoding >> |YWJj| - as a base-64 encoding of the octet-string >> "abc" >> >> Perhaps: >> * abc - as a token >> * "abc" - as a quoted string >> * #616263# - as a hexadecimal string >> * 3:abc - as a length-prefixed "verbatim" encoding >> * |YWJj| - as a base-64 encoding of the octet-string "abc" >> --> > > Maybe there is some third way to do this but I would prefer that these > say as sourcecode elements. Making them lists, with these asterisks on > the lines in text mode, seems confusing. In fact, the first part of > the line, the "abc", #616263#, etc., are formal sequences of ASCII > character code poiints, not ordinary body text. AR: Left them as they are. Understood regarding the asterisks. > >> 5) <!-- [rfced] In Section 4.5, regarding this text: >> >> Base-64 encoding produces four characters of output for each three >> octets of input. If the length of the input divided by three leaves >> a remainder of one or two, it produces an output block of length four >> ending in two or one equals signs, respectively. >> >> Is the following accurate? >> * If the remainder is one, then it produces a block length of four >> with two equals signs. >> * If the remainder is two, then it produces a block length of four >> with one equals sign. >> We ask in order to verify the use of "respectively". >> >> Perhaps it would also be helpful to include an example of each >> instance? Please let us know if/how we may update. >> --> > > Yes, that is right. there are exmples in the reference RFC the > specified Base-64 so I am a little reluctant to add that here. I > suppose we could add something like > > <table> > <thead> > <tr><td>Text</td><td>Size</td><td>Base-64</td></tr> > </thead> > <tbody> > <tr><td>a</td><td>1</td><td>YQ==</td></tr> > <tr><td>ab</td><td>2</td><td>YWI=</td></tr> > <tr><td>abc</td><td>3</td><td>YWJj</td></tr> > </tbody> > </table> AR: The example has not been added. It's not our intention to override author preference. What do you think of updating the sentence as follows for clarity? PERHAPS: When the length of the input divided by three: * if the remainder is one, it produces an output block of length four ending in two equals signs. * if the remainder is two, it produces an output block of length four ending in one equals sign. > >> 6) <!--[rfced] We received guidance that, in general, "MIME types" should >> be referred to as "media types". May we update the text as follows? >> >> Original: >> Many of the MIME [RFC2046] types work here. >> >> Perhaps: >> Many of the media types [RFC2046] work here. >> --> > > I guess that change is OK. > >> 7) <!--[rfced] Section 4.6: We updated the text because non-ASCII >> characters can appear in RFCs. Please review and let us know if you >> prefer otherwise. >> >> Original: >> A display-hint that can be used for UTF-8 encoded text is shown in >> the following example where the octet-string is text saying "bob", >> with an umlaut over the central "o", followed by a smilie emoji. >> >> ["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA" >> >> Current: >> A display-hint that can be used for UTF-8-encoded text is shown in >> the following example where the octet-string is "böb☺", i.e., "bob" >> with an umlaut over the "o", followed by WHITE SMILING FACE (U+263A). >> >> ["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA" >> --> > > Not exactly. The octet string is a string of 8-bit quantities. An > octet is 8-bits; it is not a Unicode code point. However it could say: > > NEW > A display-hint that can be used for UTF-8-encoded text is shown in > the following example where the octet-string represents "böb☺", > that is, "bob" with an umlaut over the "o", followed by the Unicode > character WHITE SMILING FACE (U+263A). > > This might require adding an Informational Reference to Unicode. AR: Thank you for providing the new text. We have added the reference to Unicode; please let us know if you prefer other placement. > >> 8) <!-- [rfced] May this be rephrased as follows for clarity? >> >> Current: >> Every octet-string representation is either preceded by a single >> display-hint or not so preceded. >> >> Perhaps: >> Every octet-string representation may or may not be preceded by a >> single display-hint. >> --> > > I don't like "may" but "... is or is not preceded by ..." would be fine. > >> 9) <!-- [rfced] Regarding this reference, the C programming language standard >> is now an ISO/IEC standard: ISO/IEC 9899:2024 >> (https://www.iso.org/standard/82075.html). >> >> A technically equivalent specification is available from the C Programming >> Language working group (JTC1/SC22/WG14): >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf. >> >> May we update this reference as shown below or otherwise? >> >> Original: >> [C] Kernighan, B. and D. Ritchie, "The C Programming >> Language", ISBN 0-13-110370-9, 1988. >> >> Perhaps: >> [C] ISO/IEC, "Information technology — Programming languages — >> C", ISO/IEC 9899:2024, 2024, >> <https://www.iso.org/standard/82075.html>. Technically >> equivalent specification available here: >> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n3220.pdf>. >> --> > > Don't know about open-std but ISO standards tend to require payment > which is not good. Also, the Kernighan and Ritchie book is much more > common; many people have it on their shelves already. So I would > prefer to stick with Kernighan and Ritchie. Also, based on a comment > during IETF Last Call, I would prefer to the reference tag to be > [C88], not [C]. AR: Understood; reverted to "[C88]". > >> 10) <!-- [rfced] Regarding the [CANON] reference, we split it into >> two entries, as one is a Wikipedia article and the other is a >> GitHub repository. Please let us know if you prefer different >> symbolic names. >> >> Original: >> [CANON] Wikipedia, "Canonical S-expressions", >> <https://en.wikipedia.org/wiki/Canonical_S-expressions>. >> >> Grinberg, R., "Csexp - Canonical S-expressions", 24 March >> 2023, <https://github.com/ocaml-dune/csexp>. >> >> Current: >> [CANON1] Wikipedia, "Canonical S-expressions", >> <https://en.wikipedia.org/wiki/Canonical_S-expressions>. >> >> [CANON2] Grinberg, R., "Csexp - Canonical S-expressions", 24 March >> 2023, <https://github.com/ocaml-dune/csexp>. >> >> Please review the two instances where [CANON] was cited in the original >> and let us know if any updates are needed. FYI, we updated the second one >> to cite only [CANON2], as the former does not mention OCAML. >> >> Original: >> * Canonical S-expressions [CANON] (OCAML) >> >> Current: >> * Canonical S-expressions [CANON2] (OCAML) >> --> > > Those changes are good. > >> 11) <!-- [rfced] Regarding [LISP], we found the following URL from the >> Software >> Preservation Group of the Computer History Museum that provides an >> open-access to this reference: >> https://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf. >> >> Would you like to include this URL with the reference? >> >> Original: >> [LISP] Levin, M. and J. McCarthy, "LISP 1.5 Programmer's Manual", >> ISBN-13 978-0-262-12011-0, ISBN-10 0262130114, 15 August >> 1962. >> --> > > Sure, that seems good and long as the book information is also retained. > >> 12) <!-- [rfced] FYI, RFC 7259 (which was cited once in the original) has >> been >> obsoleted by RFC 8259, so we updated the informative reference accordingly. >> Please let us know if you prefer otherwise. >> >> Original: >> For implementors of new applications and protocols other technologies >> also worthy of consideration include the following: [XML], CBOR >> [RFC8949], and JSON [RFC7159]. >> >> Current: >> For implementors of new applications and protocols other technologies >> also worthy of consideration include the following: XML [XML], CBOR >> [RFC8949], and JSON [RFC8259]. >> --> > > OK. > >> 13) <!-- [rfced] FYI, for these 2 references, we were unable to confirm >> the dates provided in the original I-D, so we have updated to the >> dates as follows. Please let us know if you prefer otherwise. >> >> [RNPGP_SEXPP] updated to the most recent commit. (Note that >> the version has been updated from Version 0.8.7 to Version 0.9.2.) >> >> [SEXPP] updated to the most recent commit. >> >> >> Current: >> [RNPGP_SEXPP] >> "S-Expressions parser and generator library in C++ (SEXP >> in C++)", Version 0.9.2, commit 249c6e3, 22 March 2025, >> <https://github.com/rnpgp/sexpp>. >> >> [SEXPP] "SexpProcessor", commit a90f90f, 11 April 2025, >> <https://github.com/seattlerb/sexp_processor>. >> --> > > Those updates seem good. > >> 14) <!-- [rfced] FYI, this term was capitalized inconsistently. We changed >> the 3 instances of "S-Expressions" (in running text in Sections >> 1.1, 1.2, and 4.6) to the lowercased form, based on usage in the rest >> of the document. Please let us know if you prefer otherwise. >> >> S-expressions vs. S-Expressions >> --> > > Should be consistent, change to whatever is most commonly used unless > maybe it is in a section header in which case Expressions should be > capitalized. AR: Ack. 'S-expression' is used consistently in running text in the current document. > >> 15) <!-- [rfced] The following terms appear to be consistently hyphenated in >> this document, but in most RFCs, they are not hyphenated. Would you like to >> add a note to the beginning of the document about the reasoning as to why >> the hyphen is used in this document? Or would you like to update to no hyphen >> throughout? Please let us know any updates. >> >> byte-strings >> display-hint >> octet-strings >> simple-string > > Well, display-hint and simple-string are symbols that appear in the > ABNF in Section 7 so I would want them to remain the same. > > There seems to be exactly one occurrence of byte-strings so I think > OLD > These S-expressions are either byte-strings ("octet-strings") or > NEW > These S-expressions are either octet-strings or > > So the only remaing question is octet-strings. I would prefer to leave > it that was for consistency with with the other terms and consistence > with the original -00 (unposted) draft from 1997. > > I do not understand what benefit it would be to add a note about > this. I understand why you and the office of the RFC Editor are > interested in this but for almost all other readers, it would be > useless clutter since I don't think the hyphen has any affect on > understandability. AR: Ack; no update has been made besides the 'NEW' above. > >> Re: capitalization, should these terms always be lowercase? >> If so, we will lowercase them in the section titles, even >> when they appear at the start of the section title. Two examples: >> >> Original: >> 4. Octet-string representation types >> >> Current [title case]: >> 4. Octet-String Representation Types >> >> Perhaps: >> 4. octet-string Representation Types >> >> Original: 9.2.2. Octet-string with display-hint >> Current: 9.2.2. Octet-String with Display-Hint >> Perhaps: 9.2.2. octet-string with display-hint >> --> > > I think using initial caps in section titles is good so the "Current" > versions should stay. > >> 16) <!-- [rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> > > I think we are OK on inclusive language. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected] > >> Thank you. >> >> RFC Editor/st/ar >> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
