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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 30 Jan 2021 11:06:38 -0500

On Sat 2021-01-30 07:22:43 +0200, Lars Eggert wrote:
> I think that would be excellent, but AFAIK Unicode can (still) only be
> used in contact names (see the recent "Unicode in xml2rfc v3" thread
> over on rfc-interest@). I really hope we can just get to an agreement
> to allow Unicode anywhere in the document.

whoops, i've been using unicode (in particular, the box-drawing
characters and a few fancy arrows) to pretty good effect (imho) in
several I-Ds already, for example:

    https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.html#name-multilayer-cryptographic-en

That document would be much harder to read and understand (and probably
much longer) without the compact representations of MIME message
structure.

Reading the thread you reference suggests that those characters are
probably acceptable within an "artwork" or verbatim block, but maybe not
in the regular text.

That would mean unicode *can* show up in other places in the .txt
versions of the RFC, which is the only context where --table-borders
really matters, afaict.  So it seems like the constraints on unicode in
the normal text shouldn't be any formal problem with the .txt
translation.  Does that seem like a plausible analysis?

Hopefully this change would just be a "simple matter of programming" in
xml2rfc itself, and not some sort of policy quagmire.

  --dkg

---

From: Lars Eggert <[email-masked]>
Date: Mon, 1 Feb 2021 16:53:33 +0200

>    https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.html#name-multilayer-cryptographic-en

Ah! You're right, in artwork, there is no issue.

I was trying to use Unicode in the text, which has the restriction I mentioned.

Lars

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Feb 2021 16:01:16 +0100

On 2021-01-30, at 17:06, Daniel Kahn Gillmor <[email-masked]> wrote:
> Signed PGP part

That is how xml2rfc is currently programmed.
This is fine for box-drawing, but not so great for α and β, which need to be referenceable in the text.

(A quick fix to get a preview of what will be possible with an updated policy is in http://www.tzi.de/~cabo/contact-hack.sh — you can simply reinstall xml2rfc if that screws up things for you.  This fix is necessary to build Lars’s 8132bis draft.)

> xml2rfc itself, and not some sort of policy quagmire.

I don’t think there is a change needed to support the artwork in the above-mentioned draft.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Feb 2021 15:52:54 +0100

> probably acceptable within an "artwork" or verbatim block, but maybe not

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").

> xml2rfc itself, and not some sort of policy quagmire.

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*).

Best regards, Julian

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Feb 2021 15:13:45 -0500

> recommendation might be "use SVG instead").

Use svg for a table?  Or for a linear, structured representation of a
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?

> document would be needed (and believe me, it was really hard to agree on

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.

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.

        --dkg

[0] https://datatracker.ietf.org/doc/draft-dkg-lamps-e2e-mail-guidance/

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Feb 2021 21:16:16 +0100

> current publication process doesn't block them, at any rate.

I don’t think anybody wants to turn the clock back on beyond-ASCII in artwork.

I do want to see some forward movement of the clock on beyond-ASCII in non-artwork text.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Feb 2021 22:03:55 +0100

> 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.

> 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.

> 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).

> current publication process doesn't block them, at any rate.

It might be blocked during AUTH48. Or not.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Feb 2021 22:18:30 +0100

> are the rules currently).

One of the qualifications for a German professor is that you need to be able to make up a valid argument for anything, in particular when talking to university administration (which is trained in making up arguments *against* anything).

In this case, of course, RFC 7997 does support this usage as it makes an allowance for the rules of a programming language [1].  The author clearly has defined a new (visual) programming language here and uses that in his artwork.

Grüße, Carsten

[1]: 3.6 code components:
https://tools.ietf.org/html/rfc7997#section-3.6