Since this -rfc8447bis is in AUTH48 too can we do the following throughout:
s/RFC8447/RFC9847 Not sure where -rfc8446bis is in the process but can we also change that ref? spt > On Dec 2, 2025, at 09:58, 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]
