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]

Reply via email to