Hi, Thanks for the reminder! I'm happy to answer the questions, I was just out of town for the holiday. Will get on it after the day's meetings have concluded.
Alexis On Tue, Dec 2, 2025 at 6:53 AM Kaelin Foody <[email protected]> wrote: > 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 > >> > > > > > > -- > 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]
