Hi Martin, Eliot, all, Martin: Thanks for your formatting approval -- we have marked it on the AUTH48 status page. We have also updated the SVG reference as requested.
Eliot: Thanks for your message. Two rounds of approvals are needed for documents that have been edited in kramdown-rfc (one round to approve the document’s content and a second round to approve the document’s output files/formatting). We have received all content approvals but await a second (and final) round of formatting approvals from Alexis, Jean, and Nevil. For more information, please see <https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown>. Outstanding approvals can be tracked on the AUTH48 status page: <https://www.rfc-editor.org/auth48/rfc9896>. — FILES: — XML file: https://www.rfc-editor.org/authors/rfc9896.xml XML diff: https://www.rfc-editor.org/authors/rfc9896-xmldiff1.html Output files: https://www.rfc-editor.org/authors/rfc9896.html https://www.rfc-editor.org/authors/rfc9896.pdf https://www.rfc-editor.org/authors/rfc9896.txt Diff of changes made in AUTH48: https://www.rfc-editor.org/authors/rfc9896-auth48diff.html https://www.rfc-editor.org/authors/rfc9896-auth48rfcdiff.html (side by side) Diff of all changes: https://www.rfc-editor.org/authors/rfc9896-diff.html https://www.rfc-editor.org/authors/rfc9896-rfcdiff.html (side by side) Thanks, Kaelin Foody RFC Production Center > On Dec 14, 2025, at 4:55 PM, Martin Thomson <[email protected]> wrote: > > LGTM. > > You could probably set a date for the SVG reference. The spec is dated and > 04 October 2018 works. > > On Sat, Dec 13, 2025, at 09:10, Kaelin Foody wrote: >> Hi all, >> >> Nevil: Thank you for your approval of this document’s content. We have >> marked it on the AUTH48 status page for this document. >> >> Alexis, all: Thanks for your reply. As part of the RPC’s kramdown-rfc >> pilot, there is a two-part AUTH48 approval process (one round of >> approvals for content and a final round of approvals for formatting). >> >> We have received all necessary content approvals and have converted the >> document to RFCXML, with no major formatting changes to note. >> >> Please review the XML file/diff and the output files, and let us know >> if any additional formatting changes are required or if you approve the >> RFC for publication. We consider this your final assent that the >> document is ready for publication. To request changes or approve this >> RFC for publication, please reply all to this email. >> >> The AUTH48 status page for this document is available here: >> https://www.rfc-editor.org/auth48/rfc9896 >> >> For more information about the RPC’s kramdown-rfc pilot, please see: >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown. >> >> — FILES: — >> >> XML file: >> https://www.rfc-editor.org/authors/rfc9896.xml >> >> XML diff: >> https://www.rfc-editor.org/authors/rfc9896-xmldiff1.html >> >> Output files: >> https://www.rfc-editor.org/authors/rfc9896.html >> https://www.rfc-editor.org/authors/rfc9896.pdf >> https://www.rfc-editor.org/authors/rfc9896.txt >> >> Diff of changes made in AUTH48: >> https://www.rfc-editor.org/authors/rfc9896-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9896-auth48rfcdiff.html (side by side) >> >> Diff of all changes: >> https://www.rfc-editor.org/authors/rfc9896-diff.html >> https://www.rfc-editor.org/authors/rfc9896-rfcdiff.html (side by side) >> >> >> Thank you all for your time. >> >> All best, >> >> Kaelin Foody >> RFC Production Center >> >>> On Dec 12, 2025, at 4:21 PM, Alexis Rossi <[email protected]> wrote: >>> >>> Hi Kaelin, >>> >>> I think we have all of the approvals now, is that correct? >>> >>> Thanks, >>> Alexis >>> >>> >>> On Wed, Dec 10, 2025 at 7:51 PM Nevil Brownlee <[email protected]> >>> wrote: >>> Hi RFC Editor(s): >>> I approve the changes made, as reflected in this AUTH48 email. >>> >>> Cheers, Nevil Brownlee >>> >>> On Tue, Nov 18, 2025 at 7:50 PM <[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] Abstract >>>> >>>> a) The Abstract does not explicitly mention that this document obsoletes >>>> RFC >>>> 7996. See the checklist in the "Abstract" section of >>>> https://authors.ietf.org/required-content. Please review and let us know >>>> how >>>> you would like to update. >>>> >>>> >>>> b) This sentence mentions the RPC being responsible for implementation >>>> decisions. Other instances in the document mention the RPC being >>>> responsible >>>> for decisions about both tooling and implementation. Are any updates >>>> needed, >>>> or is the current okay? >>>> >>>> Original: >>>> It also makes the RFC Publication Center (RPC) responsible for >>>> implementation decisions regarding SVGs. >>>> >>>> Perhaps: >>>> It also makes the RFC Publication Center (RPC) responsible for >>>> decisions about SVG tooling and implementation. >>>> --> >>>> >>>> >>>> 2) <!-- [rfced] Abstract/Introduction: Is "sets" the best word choice >>>> here? Would >>>> "defines" or something else be better? Also, will all readers know what the >>>> "definitive versions of RFCs and relevant publication formats" are? Would >>>> adding a citation or clarification in the Introduction be helpful? If so, >>>> please provide the appropriate citation or text. >>>> >>>> Original: >>>> This document sets policy for the inclusion of SVGs in the definitive >>>> versions of RFCs and relevant publication formats. >>>> ... >>>> This document sets policy for the inclusion of SVGs (Scalable Vector >>>> Graphics) in the definitive versions of RFCs and relevant publication >>>> formats. >>>> --> >>>> >>>> >>>> 3) <!-- [rfced] Section 2: In the text below, how may we update "This >>>> includes"? >>>> It is not clear what "This" refers to. >>>> >>>> Original: >>>> * Images and diagrams in RFCs should be successfully rendered and >>>> understood by the widest audience possible. To that end, the RPC >>>> may prohibit the use of SVG features that are known to lack >>>> support on common devices, that do not render on small or low- >>>> resolution screens, or that could make diagrams less >>>> comprehensible for any significant readership. This includes: >>>> >>>> - SVGs must not contain pointers to external resources. >>>> >>>> - SVGs must not contain executable script. >>>> >>>> - SVGs should be as accessible as possible to people with visual >>>> disabilities, ... >>>> >>>> Perhaps: >>>> * Images and diagrams in RFCs should be successfully rendered and >>>> understood by the widest audience possible. To that end, the RPC >>>> may prohibit the use of SVG features that are known to lack >>>> support on common devices, that do not render on small or low- >>>> resolution screens, or that could make diagrams less >>>> comprehensible for any significant readership. In particular: >>>> >>>> - SVGs must not contain pointers to external resources. >>>> >>>> - SVGs must not contain executable script. >>>> >>>> - SVGs should be as accessible as possible to people with visual >>>> disabilities, ... >>>> >>>> Or: >>>> * Images and diagrams in RFCs should be successfully rendered and >>>> understood by the widest audience possible. To that end, the RPC >>>> may prohibit the use of SVG features that are known to lack >>>> support on common devices, that do not render on small or low- >>>> resolution screens, or that could make diagrams less >>>> comprehensible for any significant readership. For instance: >>>> >>>> - SVGs must not contain pointers to external resources. >>>> >>>> - SVGs must not contain executable script. >>>> >>>> - SVGs should be as accessible as possible to people with visual >>>> disabilities, ... >>>> --> >>>> >>>> >>>> 4) <!-- [rfced] Section 2: FYI, we have updated the sentence below to >>>> clarify that >>>> SVGs should be consistent with the content of the RFC (rather than the text >>>> output file of the RFC). >>>> >>>> Original: >>>> At minimum, SVGs should be consistent with the text. >>>> >>>> Current: >>>> At minimum, SVGs should be consistent with the descriptions >>>> in the text of the RFC. >>>> --> >>>> >>>> >>>> 5) <!-- [rfced] Section 2: This sentence mentions that decisions about SVG >>>> tooling and implementation are "made or overseen" by the RPC. The document >>>> mentions several times that the RPC is responsible for making decisions, >>>> but >>>> this is the only mention of "overseen" in the document. Please review and >>>> let >>>> us know if any updates are needed. >>>> >>>> Original: >>>> SVG tooling and implementation decisions are made or overseen by the >>>> RPC, and must adhere to the policy requirements in this document. >>>> --> >>>> >>>> >>>> 6) <!-- [rfced] Section 2: We updated "rfcxml" to "RFCXML" in the first >>>> sentence >>>> below per RFC 9720. Would it be helpful to also include a citation to RFC >>>> 9720 >>>> or other applicable reference here? >>>> >>>> Original: >>>> * Authors may include multiple versions of images or diagrams in >>>> rfcxml. Publication formats should present the versions best >>>> suited to each format. In many cases, that will be an SVG. >>>> >>>> Perhaps: >>>> * Authors may include multiple versions of images or diagrams in >>>> RFCXML [RFC9720]. Publication formats should present the versions >>>> best >>>> suited to each format. In many cases, that will be an SVG. >>>> --> >>>> >>>> >>>> 7) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>> online >>>> Style Guide >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>> and let us know if any changes are needed. Updates of this nature >>>> typically >>>> result in more precise language, which is helpful for readers. >>>> >>>> Note that our script did not flag any words in particular, but this should >>>> still be reviewed as a best practice. >>>> >>>> --> >>>> >>>> >>>> Thank you. >>>> >>>> Kaelin Foody and Rebecca VanRheenen >>>> RFC Production Center >>>> >>>> >>>> >>>> On Nov 17, 2025, at 10:45 PM, [email protected] wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/11/17 >>>> >>>> RFC Author(s): >>>> >>>> Your document has now entered AUTH48. >>>> >>>> The document was edited in kramdown-rfc as part of the RPC pilot test (see >>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). >>>> >>>> Please review the procedures for AUTH48 using kramdown-rfc: >>>> >>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown >>>> >>>> Once your document has completed AUTH48, it will be published as >>>> an RFC. >>>> >>>> >>>> Files >>>> ----- >>>> >>>> The files are available here: >>>> https://www.rfc-editor.org/authors/rfc9896.md >>>> https://www.rfc-editor.org/authors/rfc9896.html >>>> https://www.rfc-editor.org/authors/rfc9896.pdf >>>> https://www.rfc-editor.org/authors/rfc9896.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9896-diff.html >>>> https://www.rfc-editor.org/authors/rfc9896-rfcdiff.html (side by side) >>>> >>>> Diff of the kramdown: >>>> https://www.rfc-editor.org/authors/rfc9896-md-diff.html >>>> https://www.rfc-editor.org/authors/rfc9896-md-rfcdiff.html (side by side) >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9896 >>>> >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>> >>> >>> -- >>> ----------------------------------- >>> Nevil Brownlee, Taupo, NZ >>> >>> -- >>> RSAB mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
