Hi Authors, This is a friendly weekly reminder that we await answers to the followup questions/comments below and your review of the document before continuing with the publication process. For details of the AUTH48 process in kramdown-rfc (including the two-part approval process), see: https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc.
Thank you! Madison Church RFC Production Center > On Nov 25, 2025, at 8:34 AM, Madison Church <[email protected]> > wrote: > > Hi Eric, > > Thank you for your reply! We have updated the document as requested and have > two followup items for your review, which can be viewed in the AUTH48 thread > below or in the updated markdown file marked with "rfced". > >> On Nov 20, 2025, at 10:33 PM, Eric Rescorla <[email protected]> wrote: >> >> Update: I fixed my affiliation. >> >> >> >> On Thu, Nov 20, 2025 at 8:23 PM Eric Rescorla <[email protected]> wrote: >> Thank you. I am editing this in GitHub. I merged in your proposed changes >> except >> for those I think are inadvisable, which I reverted. I answered your >> questions inline. >> >> You can find the latest markdown file here (also attached): >> https://raw.githubusercontent.com/tlswg/draft-ietf-tls-esni/refs/heads/auth48/rfc9849.md >> >> -Ekr >> >> >> >> On Fri, Nov 14, 2025 at 10:53 AM <[email protected]> wrote: >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the source file. >> >> 1) <!-- [rfced] References >> >> a) Regarding [WHATWG-IPV4], this reference's date is May 2021. >> The URL provided resolves to a page with "Last Updated 12 May 2025". >> >> Note that WHATWG provides "commit snapshots" of their living standards and >> there are several commit snapshots from May 2021 with the latest being from >> 20 >> May 2021. For example: 20 May 2021 >> (https://url.spec.whatwg.org/commit-snapshots/1b8b8c55eb4bed9f139c9a439fb1c1bf5566b619/#concept-ipv4-parser) >> >> We recommend updating this reference to the most current version of the >> WHATWG >> Living Standard, replacing the URL with the more general URL to the standard >> (https://url.spec.whatwg.org/), and adding a "commit snapshot" URL to the >> reference. >> >> Current: >> [WHATWG-IPV4] >> WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May >> 2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>. >> >> EKR: Per MT, WHATWG has asked us not to do that. We should leave >> this as-is and change the date to December 2025. > > 1) For context, we reached out to WHATWG in September about a format for > references to their standards (see: > https://github.com/whatwg/meta/issues/363). The proposed update below for > this reference reflects the approved format. It would be helpful for the RPC > to know what WHATWG has asked authors to not do so that we can reach out for > clarification and update our recommended citation if necessary. With this in > mind, let us know if any updates need to be made. > > Perhaps: > [WHATWG-IPV4] > WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, > <https://url.spec.whatwg.org/#concept-ipv4-parser>. > > Commit snapshot: > > https://url.spec.whatwg.org/commit-snapshots/1b8b8c55eb4bed9f139c9a439fb1c1bf5566b619/#concept-ipv4-parser > > Regarding the date, we don't recommend using a future date for a reference as > it doesn't reflect the date for a currently published work (unless there is > an anticipated update to the WHATWG specification in December 2025). > >> d) FYI, RFCYYY1 (draft-ietf-tls-svcb-ech) will be updated during the XML >> stage. >> --> >> >> >> 7) <!-- [rfced] We note that the following terms use fixed-width font >> inconsistently. Please review these terms and let us know how we should >> update >> or if there are any specific patterns that should be followed (e.g., >> fixed-width font used for field names, variants, etc.). >> >> accept_confirmation >> cipher_suite >> ClientHello >> ClientHelloInner >> ClientHelloOuter >> ClientHelloOuterAAD >> config_id >> ECHClientHello >> ECHConfig >> ECHConfig.contents.public_name >> ECHConfigContents >> ECHConfigList >> EncodedClientHelloInner >> inner >> maximum_name_length >> outer >> payload >> public_key >> ServerHello.random >> zeros >> —> >> >> EKR: Thanks. Fixed width should be used for field names and other PDUs. >> >> I notice that some of these are regular words (zeros) so you have to >> determine from context whether it's referring to some protocol element or >> just to the concept "carries an encrypted payload" versus "the payload >> field". Do you want to take a cut at changing as many of these as make sense >> and then I can review, or would you prefer I make the changes? >> One question is what to do in definition lists. My sense is that the list >> heds should be non-fixed-width but maybe you have a convention. > > 2) Thank you for offering to make changes. Please feel free to attach an > updated markdown file containing the changes for terms using fixed-width font. > > For definition lists, we typically leave this up to the authors to determine > how they would like the terms to appear for consistency. For an example of > terms in a definition list using a fixed-width font, see: > https://www.rfc-editor.org/rfc/rfc9623.html#section-5.1.1. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9849.txt > https://www.rfc-editor.org/authors/rfc9849.pdf > https://www.rfc-editor.org/authors/rfc9849.html > https://www.rfc-editor.org/authors/rfc9849.xml > https://www.rfc-editor.org/authors/rfc9849.md > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9849-diff.html > https://www.rfc-editor.org/authors/rfc9849-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9849-auth48diff.html > https://www.rfc-editor.org/authors/rfc9849-auth48rfcdiff.html (side by side) > > Markdown diffs: > https://www.rfc-editor.org/authors/rfc9849-md-diff.html > https://www.rfc-editor.org/authors/rfc9849-md-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9849-md-auth48diff.html > https://www.rfc-editor.org/authors/rfc9849-md-auth48rfcdiff.html > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9849. > > We will await approvals from each author prior to moving forward with > formatting updates. For details of the AUTH48 process in kramdown-rfc > (including the two-part approval process), see: > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. > > Thank you! > > Madison Church > RFC Production Center -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
