Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value?

[Julian Reschke <[e-mail]>]

Am 01.02.2021 um 21:13 schrieb Daniel Kahn Gillmor:
> On Mon 2021-02-01 15:52:54 +0100, Julian Reschke wrote:
>> Right. This is intended mainly for examples that require use of
>> non-ASCII characters, not for drawing symbols (for which the
>> recommendation might be "use SVG instead").
>
> Use svg for a table?  Or for a linear, structured representation of a

For a table, a table should be used. Not SVG, not artwork.

> MIME tree?  SVG won't be rendered at all in the text document, making it
> actively *less* useful and effective than the non-text variant.
>
> Is the goal to have improved legibility and ease of consumption in
> different formats, including plain text?  Or is the goal to drive people
> away from the plain text format entirely?

IHMO, if the plain text is in the way of progress, then yes, we should
drive people away from it.

>> It depends on how you read RFC 7997 - and yes, I believe it intends to
>> describe the *output* of the text generation step, thus a change of that
>> document would be needed (and believe me, it was really hard to agree on
>> *that*).
>
> It sounds to me like you're saying the existing drafts i've been working
> on (like [0]) are somehow skirting the IETF consensus on what makes a
> legitimate document by "abusing" the artwork mechanism.

IMHO: non-ASCII characters in artwork were allowed to express examples
where non-ASCII characters are *required*. This does not seem to be the
case here. See the rules in
<https://greenbytes.de/tech/webdav/rfc7997.html#n-rules-for-the-use-of-non-ascii-characters>.

(These are not my rules, and I might not even support them, but these
are the rules currently).

> I really hope that's not the case, as the documents would be
> significantly worse (and probably harder to maintain) if i had to revert
> to ASCII line art or convert to embedded SVG.  I'm grateful that the
> current publication process doesn't block them, at any rate.

It might be blocked during AUTH48. Or not.

Best regards, Julian