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
