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]
