Looks good! I approve publication. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com
On Tue, Jun 10, 2025 at 2:33 PM Alice Russo <aru...@staff.rfc-editor.org> wrote: > > 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
