Subject: Re: [xml2rfc] Dealing with IPv6 reverse DNS entries

From: Carsten Bormann <[email-masked]>
Date: Sun, 1 Nov 2020 09:01:30 +0100

On 2020-11-01, at 04:28, Brian E Carpenter <[email-masked]> wrote:
> 
> <artset>
> 
> <artwork align="left" type="ascii-art">
> <![CDATA[
> IPv6 PTR Records are too long for ASCII art.
> ]]></artwork>

I know you were just being silly, but for the benefit of onlookers let me opine	that this would be abuse of the artset feature and should never be accepted by the RFC editor.

(The artset feature of beta RFCXMLv3 was never subject to community review, so I think we never had this discussion.)

The only RFC with artset I can find is RFC 8899, which essentially sent their ASCII art through the “goat” tool to generate the HTML/PDF rendering (a feat that is also now directly supported by kramdown-rfc).  That is a sensible (if somewhat gratuitous) use of artset; the main problem for a proofreader is to check that the “ASCII” art and the SVG mean the same thing.

Let’s see

~~~ goat
IN PTR e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a.4.1.0.0.8.2.0.0.4.1.0.0.1.0.0.2.ip6.arpa.
~~~

sure works, but doesn't help with

  ** There is 1 instance of too long lines in the document, the longest one
     being 8 characters in excess of 72.

and the SVG is not scalable.

What was the trick you used to make that scalable?

Grüße, Carsten

---

From: Brian Carpenter <[email-masked]>
Date: Sun, 1 Nov 2020 21:52:30 +1300

Clearly it was partly a joke but there's a genuine problem when "plain"
text works in reasonable way in flowed html but incorrectly in txt.
My experience is that SVG scales correctly in the v3 html rendering iff
there is a viewbox element but no width & height elements. I assume there
is some CSS magic involved.
As for artset, what will we do about figures that simply cannot be
expressed in ascii art?

Regards
    Brian
    (via tiny screen & keyboard)

On Sun, 1 Nov 2020, 21:01 Carsten Bormann, <[email-masked]> wrote:

> I know you were just being silly, but for the benefit of onlookers let me
> opine that this would be abuse of the artset feature and should never be
> accepted by the RFC editor.
>
> (The artset feature of beta RFCXMLv3 was never subject to community
> review, so I think we never had this discussion.)
>
> The only RFC with artset I can find is RFC 8899, which essentially sent
> their ASCII art through the “goat” tool to generate the HTML/PDF rendering
> (a feat that is also now directly supported by kramdown-rfc).  That is a
> sensible (if somewhat gratuitous) use of artset; the main problem for a
> proofreader is to check that the “ASCII” art and the SVG mean the same
> thing.
>
> Let’s see
>
> ~~~ goat
> IN PTR
> e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a.4.1.0.0.8.2.0.0.4.1.0.0.1.0.0.2.ip6.arpa.
> ~~~
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 1 Nov 2020 11:09:04 +0100

On 2020-11-01, at 09:52, Brian Carpenter <[email-masked]> wrote:
> 
> Clearly it was partly a joke but there's a genuine problem when "plain" text works in reasonable way in flowed html but incorrectly in txt.

Right.  At the moment, the “switch” between different inputs is based on formats, so we’ll need to invent another format (plain text, but doesn’t render in txt) to make this work.

> My experience is that SVG scales correctly in the v3 html rendering iff there is a viewbox element but no width & height elements. I assume there is some CSS magic involved.

Good to know.
So I could put in an option scale=“true” to delete width/height from the tool outputs.

> As for artset, what will we do about figures that simply cannot be expressed in ascii art?

Well, if they *cannot* be expressed, the RFC 1305 (1119/1129) exception applies.

I was talking about the case where that exception does not apply, but a malicious author doesn’t want to expend the effort (or, worse, wants to make a point by making the document unusable in .TXT).

(And, as usual on this list, this entire discussion belongs over at rfc-interest.)

Grüße, Carsten