On Wed, Dec 3, 2025 at 6:23 AM Madison Church <[email protected]> wrote:
> 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/ I think we are in agreement, then, thanks. -Ekr > > > 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]
