Hi Kaelin,

I approve the formatting, looks great!

Alexis

On Mon, Dec 15, 2025 at 8:02 AM Kaelin Foody <[email protected]>
wrote:

> Hi Martin, Eliot, all,
>
> Martin: Thanks for your formatting approval -- we have marked it on the
> AUTH48 status page. We have also updated the SVG reference as requested.
>
> Eliot: Thanks for your message. Two rounds of approvals are needed for
> documents that have been edited in kramdown-rfc (one round to approve the
> document’s content and a second round to approve the document’s output
> files/formatting). We have received all content approvals but await a
> second (and final) round of formatting approvals from Alexis, Jean, and
> Nevil.
>
> For more information, please see <
> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown
> >.
>
> Outstanding approvals can be tracked on the AUTH48 status page: <
> https://www.rfc-editor.org/auth48/rfc9896>.
>
> — 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)
>
>
> Thanks,
>
> Kaelin Foody
> RFC Production Center
>
>
> > On Dec 14, 2025, at 4:55 PM, Martin Thomson <[email protected]> wrote:
> >
> > 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]

Reply via email to