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. --> 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: --> 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: --> 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" --> 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. --> 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. --> 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" --> 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. --> 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>. --> 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) --> 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. --> 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]. --> 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>. --> 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 --> 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 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 --> 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. --> Thank you. RFC Editor/st/ar On Jun 6, 2025, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/06/06 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/rfc9804.xml https://www.rfc-editor.org/authors/rfc9804.html https://www.rfc-editor.org/authors/rfc9804.pdf https://www.rfc-editor.org/authors/rfc9804.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9804-diff.html https://www.rfc-editor.org/authors/rfc9804-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9804-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9804 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9804 (draft-rivest-sexp-13) Title : Simple Public Key Infrastructure (SPKI) S-Expressions Author(s) : R. Rivest, D. Eastlake 3rd Area Director(s) : M. Kucherawy -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
