Hi Authors, Thank you for the updated XML files. The other document files have been updated accordingly.
We have made some additional updates: ) As Bernie and Alexey have indicated that they do not have a preference regarding the index, we have removed it per DKG’s suggestion. ) The most recently submitted XML file included instances of <spanx style=“verb”>, so we have updated these to <tt>. ) It also added <figure> elements around the test vectors. The document originally had 3 figures and was updated to have 108 figures. As the test vectors are not cited elsewhere in the text and the number of figures seems excessive, we have removed the <figure> elements from the test vectors. They have been left in for the 3 original figures. ) We would also like to clarify DKG’s note below. The artwork type="ascii-art" was not selected to be the same as the media type at <https://www.iana.org/assignments/media-types/text/vnd.ascii-art>. In fact, the RPC has been advised that type value can be applied even when the characters are not limited to ASCII (per previous discussion with RPAT (RFC Production Advisory Team)). That is, the artwork does not actually corresponding to that media type, and it is not limited to 7-bit ASCII, so the removal of the type attribute for artwork that includes non-ASCII characters is not necessary but the current XML file is acceptable. > I was inclined to mark all of these but the SVG UI rendering as > "ascii-art", but reading > https://www.iana.org/assignments/media-types/text/vnd.ascii-art makes me > realize that ascii-art is defined specifically as 7-bit clean. Given > that we're using some non-ASCII UTF-8 (particularly in the MIME tree > renderings), i'm now inclined to remove all mentions of "ascii-art" and > just let all artwork be included without a "type". > > I propose to leave the type="ascii-art" attribute on the three 7-bit > clean variants designed to substitute (in the .txt format) for the SVG > figures, but remove it from every other remaining <artwork>. — FILES (please refresh) — The files have been posted here: https://www.rfc-editor.org/authors/rfc9788.xml https://www.rfc-editor.org/authors/rfc9788.txt https://www.rfc-editor.org/authors/rfc9788.html https://www.rfc-editor.org/authors/rfc9788.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9788-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9788-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9788-auth48rfcdiff.html (AUTH48 changes side by side) https://www.rfc-editor.org/authors/rfc9788-lastdiff.html (last version to this one) https://www.rfc-editor.org/authors/rfc9788-lastrfcdiff.html (rfcdiff between last version and this) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9788 Thank you, RFC Editor/ap > On Jun 16, 2025, at 12:59 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> > wrote: > > On Mon 2025-06-16 15:16:07 -0400, Daniel Kahn Gillmor wrote: >> Hope this is helpful! I'll send along the test vector updates shortly. > > OK, attached is the updated XML that addresses the underlying questions > around the test vectors. > > The test vectors are generated by a script, and because they include > digital signatures and encryption, they can't be modified without > breaking the cryptographic guarantees. > > I've tried to address all the capitalization and terminology > improvements that the RFC Editor has provided, while providing valid > signatures and encryption on the messages as warranted. > > Most importantly, "the draft" (which was in the Body of several of the > sample messages) has been replaced by "RFC 9788". > > I'm happy to improve the text in the test vectors further, if the RFC > Editor has any particular feedback, even up to re-generating the test > vectors again :) And feel free can propose further changes related to > the XML structure around the sample messages, of course, without > breaking anything cryptographically. > > This updated XML file includes all the previous edits, including the > artwork and sourcecode cleanup and the minor revisions from my previous > e-mail messages. > > For those following along in git, i've been making updates on the AUTH48 > branch on https://gitlab.com/dkg/lamps-header-protection > > --dkg > > <rfc9788.xml> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
