Donald, Thank you for your reply. We updated Section 4.5 per your reply to #5 and corrected one surname in the acknowledgements (to match https://datatracker.ietf.org/person/Daniel%20Kahn%20Gillmor).
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) This diff file shows only the changes since the last posted version: https://www.rfc-editor.org/authors/rfc9804-lastrfcdiff.html 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 Thank you. RFC Editor/ar > On Jun 9, 2025, at 3:24 PM, Donald Eastlake <d3e...@gmail.com> wrote: > > Hi Alice, > > See below. I deleted informational stuff and where we had agreed already. > > On Mon, Jun 9, 2025 at 2:58 PM Alice Russo <aru...@staff.rfc-editor.org> > wrote: >> >> Donald, >> >> Thank you for your reply; please see follow-ups inline below marked "AR:". >> ... >> >> 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 supp...@ietf.org 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/ > > It seems like a pretty obscure problem. I normally get AUTH48 emails > on my drafts. I suppose I'll ping support -- maybe there was some sort > of transient bouce from gmail... > >> Thank you. >> RFC Editor/ar >> >>> On Jun 8, 2025, at 11:01 AM, Donald Eastlake <d3e...@gmail.com> wrote: >>> >>> Hi, >>> > ... >>> >>>> 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 points, not ordinary body text. >> >> AR: Left them as they are. Understood regarding the asterisks. > > OK. > >>>> 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 examples in the reference RFC that >>> 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. > > 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. > > OK. Placement is 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]". > > Thanks. > >>>> 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. > > OK. > >>>> 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 remaining question is octet-strings. I would prefer to leave >>> it that was for consistency with the other terms and consistency >>> 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. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e...@gmail.com > >>>> 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. >>> >>> Thanks, >>> Donald >>> =============================== >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 2386 Panoramic Circle, Apopka, FL 32703 USA >>> d3e...@gmail.com >>> >>>> Thank you. >>>> RFC Editor/st/ar -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
