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]
