Hi Madison, I believe that the citation to RFCYYY1 should be informative, not normative. I corrected that in my version but I guess I forgot to flag it. Paul, co-authors, any objections?
-Ekr On Fri, Dec 5, 2025 at 2:16 PM Madison Church <[email protected]> wrote: > Hi Eric, > > Thank you for the updated markdown file! We have incorporated your edits > into the document. Upon further review, we have also updated the term > "Shared Mode" to follow the same pattern as "Split Mode" (uppercase on > first use and in titles, lowercase otherwise). Please let us know any > objections. Additionally, we will update the WHATWG reference per our > discussion during formatting. Aside from the updates mentioned, we have no > further questions/comments at this time. > > Please review the contents of the document carefully. Contact us with any > further updates or with your approval of the document’s contents in its > current form. 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. > > 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 > > Markdown file: > 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 (comprehensive > diff) > https://www.rfc-editor.org/authors/rfc9849-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9849-auth48diff.html (diff > showing AUTH48 changes) > 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 > > Thank you, > Madison Church > RFC Production Center > > > > On Dec 4, 2025, at 7:12 PM, Eric Rescorla <[email protected]> wrote: > > > > Here is an updated markdown file with the fixed width adjustments. > > > > > https://raw.githubusercontent.com/tlswg/draft-ietf-tls-esni/refs/heads/auth48/rfc9849.md > > > > -Ekr > > > > > > On Wed, Dec 3, 2025 at 9:49 AM Eric Rescorla <[email protected]> wrote: > > > > > > 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]
