Hi Eric, Thank you for your reply! Please see inline.
> On Dec 2, 2025, at 1:38 PM, Eric Rescorla <[email protected]> wrote: > > Thanks. > > Re the questions and comments: > > * I will send a revised file with the fixed width issues fixed Noted! > * As I understand the WHATWG question, there are two distinct issues (1) > whether to reference a commit and (2) whether to reference fragments. I'm OK > with referencing a commit like this if that's what you agreed with WHATWG, > but I read this text as saying not to reference fragments unless we ensure > that the anchor is permanent https://whatwg.org/working-mode#anchors. Have we > done so for this one? Thank you for clarifying. We are unsure if the current anchor [1] is permanent, so we would recommend not using it and using the more general one [2]. However, if any other authors put in a request with WHATWG to make that anchor permanent, please let us know. [1] https://url.spec.whatwg.org/#concept-ipv4-parser [2] https://url.spec.whatwg.org/ Thank you! Madison Church RFC Production Center > -Ekr > > > On Tue, Dec 2, 2025 at 6:58 AM Madison Church <[email protected]> > wrote: > 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]
