Greetings, This is a friendly reminder that this document awaits author attention. Please see the document-specific questions in this email thread and let us know if we can be of assistance as you begin the AUTH48 review process.
The AUTH48 status page of this document is available at: http://www.rfc-editor.org/auth48/rfc9896 We look forward to hearing from you at your earliest convenience. Thank you, Kaelin Foody RFC Production Center > On Nov 25, 2025, at 6:32 PM, Sandy Ginoza <[email protected]> > wrote: > > Greetings Authors, > > This is a friendly reminder that we await your review. Please review the > questions below and let us know how to proceed. > > Thank you, > Sandy Ginoza > RFC Production Center > > > >> On Nov 17, 2025, at 10: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 >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
