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
