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]
