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]
