Hi DKG,
Here is a more detailed definition of ascii-art at
<https://authors.ietf.org/diagrams>:
1. ASCII-art. This artwork uses unicode characters rendered in a fixed-width
font to
produce a diagram. Any unicode character can be used, but the width
should be
less than 72 otherwise it cuts off in plaintext renderings.
We have updated the MIME tree structures and text-based sample UI renderings in
this document and RFC-to-be 9787 to have type=“ascii-art”.
— 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)
Thank you,
RFC Editor/ap
> On Jun 17, 2025, at 9:59 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net>
> wrote:
>
> Hi Alanna--
>
> Thank you for all this work! comments inline below:
>
> On Mon 2025-06-16 17:40:47 -0700, Alanna Paloma wrote:
>> ) As Bernie and Alexey have indicated that they do not have a
>> preference regarding the index, we have removed it per DKG’s
>> suggestion.
>
> this looks good, thanks.
>
>> ) The most recently submitted XML file included instances of <spanx
>> style=“verb”>, so we have updated these to <tt>.
>
> I agree with this change.
>
>> ) 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.
>
> I also agree with this change.
>
>
>> ) 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.
>
> Without being pointed to an exact definition for "ascii-art", i
> assume it means something like:
>
> - artwork rendered in UTF-8 text by using a fixed-width font, with
> explicit line-breaks (no automatic wrapping)
>
> I don't know how this is meant to interpret variant widths of individual
> characters (see
> https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms for more
> discussion), but given that the text we're working with in RFC 9787
> should all be of uniform width, i'm OK with ignoring that wrinkle for
> now.
>
> If this is accurate, i'd classify all of the artwork objects (excluding
> the SVG alternatives, of course) as ascii-art. none of the sourcecode
> objects should be classified in that way, of course.
>
> This means, we have ascii-art for:
>
> - MIME tree structures
> - text-based sample UI renderings
>
> Ideally, the MIME tree structures in RFC 9787 will be marked the same
> way as in RFC 9788, also.
>
> Does this seem reasonable?
>
> --dkg
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
