Subject: [xml2rfc-dev] xml2rfc would not be able to render RFC 7997

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2019 08:58:05 +0200

So,

RFC 7997 is "The Use of Non-ASCII Characters in RFCs". In
<https://www.greenbytes.de/tech/webdav/rfc7997.html#rfc.section.3.2> it
says:

> Example Acknowledgements section:
>
> OLD:
>
> The following people contributed significant text to early versions of this draft: Patrik Faltstrom, William Chan, and Fred Baker.
>
> PROPOSED/NEW:
>
> The following people contributed significant text to early versions of this draft: Patrik Fältström (Faltstrom), 陈智昌 (William Chan), and Fred Baker.

However,
<https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#appendix-A.1>
states:

> A.1.  <u>
>
>    In xml2rfc vocabulary version 3, the elements <author>,
>    <organisation>, <street>, <city>, <region>, <code>, <country>,
>    <postalLine>, <email>, <seriesInfo>, and <title> may contain non-
>    ascii characters for the purpose of rendering author names,
>    addresses, and reference titles correctly.  They also have an
>    additional "ascii" attribute for the purpose of proper rendering in
>    ascii-only media.
>
>    In order to insert Unicode characters in any other context, xml2rfc
>    vocabulary v3 requires that the Unicode string be enclosed within an
>    <u> element.  The element will be expanded inline based on the value
>    of a "format" attribute.  This provides a generalised means of
>    generating the 6 methods of Unicode renderings listed in [RFC7997],
>    Section 3.4, and also several others found in for instance the RFC
>    Format Tools example rendering of RFC 7700, at https://rfc-
>    format.github.io/draft-iab-rfc-css-bis/sample2-v2.html.
>
>    The "format" attribute accepts either a simplified format
>    specification, or a full format string with placeholders for the
>    various possible Unicode expansions.
>
> A.1.1.  Expansion of simplified <u> format specifications
>
>    The simplified format consists of dash-separated keywords, where each
>    keyword represents a possible expansion of the Unicode character or
>    string; use for example "<u "lit-num-name">foo</u>" to expand the
>    text to its literal value, code point values, and code point names.
>
>    A combination of up to 3 of the following keywords may be used,
>    separated by dashes: "num", "lit", "name", "ascii", "char".  The
>    keywords are expanded as follows and combined, with the second and
>    third enclosed in parentheses (if present):
>
>       "num"    The numeric value(s) of the element text, in U+1234
>                notation
>
>       "name"   The Unicode name(s) of the element text
>
>       "lit"    The literal element text, enclosed in quotes
>
>       "char"   The literal element text, without quotes
>
>       "ascii"  The value of the 'ascii' attribute on the <u> element
>
>    In order to ensure that no specification mistakes can result for
>    rendering methods that cannot render all Unicode code points, "num"
>    MUST always be part of the specified format.
>
>    The default value of the "format" attribute is "lit-name-num".

So, unless I'm missing something, the only way to get non-ASCII
characters into regular prose is using <u>, and using <u> implies
automatic expansion of characters to numerical representations of the
codepoints.

Possible solutions:

1) In RFC 7997bis, remove the suggestion to allow non-ASCII names in
Acknowledgements etc.

2) Relax the requirements for <u> so that it doesn't *need* to be used
in prose.

3) Relax the requirement about output formats for <u>.

My preference would be 2) or 3).

Best regards, Julian

PS: tracked for now at
<https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/416>

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 15 Oct 2019 11:35:29 -0700

> On Oct 14, 2019, at 11:58 PM, Julian Reschke <[email-masked]> wrote:
> 
> So,
> 

I agree that 1) is not ideal - won’t go that route.

I like 3) over 2) because the point of <u> is to help be clear in text that might be semantically important for the spec about what characters are being used. If we just say “any prose”, I feel like that might open us up to the confusion we’re trying to avoid. Does that make sense?

I haven’t added <u> to the 7991bis doc. I’m currently looking at reverting <seriesInfo> as per https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/7, so I’m not far away from <u>. 

-Heather

> _______________________________________________
> xml2rfc-dev mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 15 Oct 2019 14:51:14 -0400

If you’re to change the use of non-ascii characters in RFCs, there’s been many requests for unicode math symbols in paragraph text.

I feel like someone is going to shoot me for saying this but really, it’s 2019. We should be able to do ≤ instead of <=

Tom

> On Oct 15, 2019, at 2:35 PM, Heather Flanagan <[email-masked]> wrote:
> 
> 
> 
> I haven’t added <u> to the 7991bis doc. I’m currently looking at reverting <seriesInfo> as per https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/7 <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/7>, so I’m not far away from <u>. 
> 
> -Heather
> 
>> 
>> Best regards, Julian
>> 
>> PS: tracked for now at
>> <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/416 <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/416>>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/xml2rfc-dev <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 15 Oct 2019 11:57:36 -0700

Hi Tom,

> On Oct 15, 2019, at 11:51 AM, Tom Pusateri <[email-masked]> wrote:
> 

Sure. I don’t mention math symbols explicitly in 7997; do you think they need separate handling from other non-ASCII characters? Or does 7997 need a special section just on Math?

-Heather

> 
> Tom
> 
>> On Oct 15, 2019, at 2:35 PM, Heather Flanagan <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>>> On Oct 14, 2019, at 11:58 PM, Julian Reschke <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> So,
>>> 
>>> <https://www.greenbytes.de/tech/webdav/rfc7997.html#rfc.section.3.2 <https://www.greenbytes.de/tech/webdav/rfc7997.html#rfc.section.3.2>> it
>>> says:
>>> 
>>> <https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#appendix-A.1 <https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#appendix-A.1>>
>>> states:
>>> 
>>>> A.1.  <u>
>>>> 
>>>>  Format Tools example rendering of RFC 7700, at https://rfc- <https://rfc-/>
>>>>  format.github.io/draft-iab-rfc-css-bis/sample2-v2.html <http://format.github.io/draft-iab-rfc-css-bis/sample2-v2.html>.
>>>>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 15 Oct 2019 21:07:30 +0200

> I like 3) over 2) because the point of <u> is to help be clear in text that might be semantically important for the spec about what characters are being used. If we just say “any prose”, I feel lik…

The problem here is that if you relax the requirements on <u> too much,
it looses its function.  It's current function is exactly to permit
insertion of non-ASCII in prose, but only if there is an expansion that
guarantees that the resulting specification always is explicit.  If it's
possible to use <u> to insert arbitrary non-ascii without expansion,
you're effectively back at no limitations on non-ascii at all.

I'm very strongly against removing the restriction on <u>.  In that case
it's better to permit any unicode in prose in general, and just drop <u>.

For the specific purpose of permitting non-ascii names in acknowledgements,
I'd like to suggest that we consider approaches that build on the current
<author> entry instead.  For author, we already have well-defined handling
of ASCII and non-ASCII parts that we can build on. Some possible variations:

 * Add a role="contributor" to <author>, and automatically generate a
   contributors section.

 * Add a role="contributor" to <author>, and make it possible to use <xref>
   to pull in contributor names at selected points in prose

 * Add a role="contributor" to <author>, and add a new <aref> element that
   lets you reference (insert names from) such entries in prose.

 * Permit insertion of <author> entries in prose directly.

Regards,

	Henrik

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 15 Oct 2019 15:11:25 -0400

I don’t think math needs separate handling. It is just an example of why you would want non-ASCII characters in paragraph text.

But as I was recently told during IESG review, it’s currently not allowed and that is unfortunate when all the work is being done to allow non-ASCII characters in other parts of the document.

Thanks,
Tom

> On Oct 15, 2019, at 2:57 PM, Heather Flanagan <[email-masked]> wrote:
> 
> Hi Tom,
> 
>> On Oct 15, 2019, at 11:51 AM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 15 Oct 2019 21:16:08 +0200

> But as I was recently told during IESG review, it’s currently not allowed and that is unfortunate when all the work is being done to allow non-ASCII characters in other parts of the document.

I'm in favour of being able to use math (both symbols and equations) better
than today.  In the upcoming -10 of the implementation draft I've written a bit about that.

	Henrik

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 15 Oct 2019 15:30:35 -0400

Henrik,

It's not just contributors, but general acknowledgements as well, such as
the example in Julian's email that kicked off this thread. Why not just
allow non-ASCII everywhere? That solves Tom's problem as well.

Cheers,
Andy

On Tue, Oct 15, 2019 at 3:07 PM Henrik Levkowetz <[email-masked]>
wrote:

> >>> The following people contributed significant text to early versions of
> this draft: Patrik Faltstrom, William Chan, and Fred Baker.
> >>>
> >>> PROPOSED/NEW:
> >>>
> >>> The following people contributed significant text to early versions of
> this draft: Patrik Fältström (Faltstrom), 陈智昌 (William Chan), and Fred
> Baker.
> >>
> >> However,
> >> <
> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#appendix-A.1
> >
> >> states:
> >>
> >>> A.1.  <u>
> >>>
> > I like 3) over 2) because the point of <u> is to help be clear in text
> that might be semantically important for the spec about what characters are
> being used. If we just say “any prose”, I feel like that might open us up
> to the confusion we’re trying to avoid. Does that make sense?
>
> > I haven’t added <u> to the 7991bis doc. I’m currently looking at
> reverting <seriesInfo> as per
> https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/7, so I’m
> not far away from <u>.
> >
> > -Heather
> >
> >>
> >> Best regards, Julian
> >>
> >> PS: tracked for now at

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 15 Oct 2019 15:37:48 -0400

> On Oct 15, 2019, at 3:07 PM, Henrik Levkowetz <[email-masked]> wrote:
> 

I’m in favor of permitting any unicode in the documents anywhere. Limiting it to specific sections or purposes just frustrates people and make the software more complicated. When the documents go through review, any objections can be raised there. The tools don’t need to try and keep up with moving goal posts.

Tom

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 15 Oct 2019 12:42:51 -0700

> On Oct 15, 2019, at 12:37 PM, Tom Pusateri <[email-masked]> wrote:
> 
> 
> 
>> On Oct 15, 2019, at 3:07 PM, Henrik Levkowetz <[email-masked] <mailto:[email-masked]>> wrote:
>> 

It is allowed, it’s just a question of [ if | how ] it’s tagged.

I feel like I might be missing a point here…

-Heather

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 15 Oct 2019 21:46:25 +0200

Hi Andy,

> allow non-ASCII everywhere? That solves Tom's problem as well.

From one point of view, that would certainly be the easiest.  However, it
also makes it essentially impossible to build tooling that checked that
the limitations of RFC7997 are followed.

With the current <u>, it is hard to violate 7997.  Without it, it is very
easy to do so, and very hard to separate valid and invalid use of non-ASCII.

If RFC 7997 changes and lifts the restrictions on non-ASCII, the need for
<u> becomes much less.

Till then, I'd very much prefer to make it possible to do exactly what 7997
permits, rather than generally lift the restriction on use of non-ASCII.

Best regards,

	Henrik

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 15 Oct 2019 15:50:46 -0400

> On Oct 15, 2019, at 3:42 PM, Heather Flanagan <[email-masked]> wrote:
> 
> 
> 
>> On Oct 15, 2019, at 12:37 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

I don’t want it to be tagged at all. I want it to be readable by humans without interrupting the thought being communicated.

Tom

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2019 21:52:14 +0200

On 15.10.2019 21:42, Heather Flanagan wrote:
>> I’m in favor of permitting any unicode in the documents anywhere.
>> Limiting it to specific sections or purposes just frustrates people
>> and make the software more complicated. When the documents go through
>> review, any objections can be raised there. The tools don’t need to
>> try and keep up with moving goal posts.
>>
>> Tom
>>
>

It's allowed by RFC 7997, but it doesn't work in practice (xml2rfc).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2019 22:00:37 +0200

On 15.10.2019 21:07, Henrik Levkowetz wrote:
> ...
> ...

<u> may be good for the actual technical specification. It's not that
great for other parts, such as Acknowledgements.

> it's better to permit any unicode in prose in general, and just drop <u>.

Well, <u> was added post-RFC7991, and it isn't yet in RFC7991bis. From
that point of view, that makes sense.

That said, I believe <u> is actually useful, we just need to be careful
with the details. And there are more issues with it that need to be
solved, such as the integration into the preptool, or the fact that
referencing an instance of <u> changes its rendering (which violates
multiple design principles, fwiw).

>   * Add a role="contributor" to <author>, and automatically generate a

That breaks existing code that handles <author> tags. Don't use <author>
for people who are not authors.

>   * Permit insertion of <author> entries in prose directly.

Almost. Just don't use <author>, but re-use the remainder of the content
model. That's good for what many have asked for in a contributors
section, but still doesn't *exactly* do what RFC 7997 gives as example.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Oct 2019 01:16:42 +0200

On Oct 15, 2019, at 20:51, Tom Pusateri <pusateri=[email-masked]> wrote:
> it’s 2019

+1.

We are seeing beyond-ASCII in at least three different usage modes:

(1) Proper attribution, acknowledgements etc.; talking about names of people and places.  Getting this right when reading is useful, but not usually essential; for non-english script providing ASCII fallbacks for people who can’t read the script in use is a useful service to the reader.

(2) Beyond-ASCII characters as the subject of the specification.  We need to make sure readers get these right, so putting in U+ explanations is mandatory.  This is where <u> shines.

(3) Everyday beyond-ASCII, as part of English script:
(3a) Naïve… “smart quotes” — dashes ➔ arrows. 
(3b) ∀x∈ℕ: a²≥a.  Z₀ ≈ 376.73 Ω

In 2019, 3a is trivial (we expect readers will get this right).  3b is maybe more critical, as symbols such as ≤ may be used in a normative context, but, again, we’d expect readers to get this right in 2019.

So far, we have been addressing (1) (but we find out not really) and (2).
It is time to address (3).  Everyday beyond-ASCII is a no-brainer.
Math maybe is a special case, as people will want to author in a variety of formats, and we need a stable publication format (probably MathML).  But simply allowing beyond-ASCII can be a valid stop-gap that is not going to suffer from format wars, and is enough for discussing quantities such as λ and units such as Ω and µW without needless contortions.

Note that common beyond-ASCII characters hide in various places in the Unicode table, so unless you want to accidentally outlaw ×, mechanically limiting this to, say, a Math range, is counterproductive.  The Authors’ and Editors’ discretion can instead be used to minimize the gratuitous use of non-English script for (3) — e.g., maybe call a variable “rain” instead of 雨 :-).

Grüße, Carsten

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 15 Oct 2019 16:22:46 -0700

> On Oct 15, 2019, at 4:16 PM, Carsten Bormann <[email-masked]> wrote:
> 

I hear what you’re saying. Using most or all of the Latin blocks in Unicode without tagging them would probably work. Maybe. But I’d really like to kick the tires here cautiously (thus the limits originally defined in RFC 7997) before we expand. There were enough challenges with making sure all applications were able to see all glyphs from even the Latin blocks when I first wrote up RFC 7997 that I feel we should move at least a bit more cautiously than “sure all of them, anywhere, no tagging”.

-Heather

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Oct 2019 08:11:25 +0200

On Oct 16, 2019, at 01:22, Heather Flanagan <[email-masked]> wrote:
> 
> when I first wrote up RFC 7997 

Which was 5.5 years ago.

I think the point that Tom and I have been making is that the world has revolved some 2000 times since that debate was last held, and we should reconsider from the reality of 2019/2020.

Grüße, Carsten

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 17 Oct 2019 16:00:02 -0400

On Wed 2019-10-16 01:16:42 +0200, Carsten Bormann wrote:
> On Oct 15, 2019, at 20:51, Tom Pusateri wrote:
>> 
>> it’s 2019
>
> +1.

+1 also.

> (3b) ∀x∈ℕ: a²≥a.  Z₀ ≈ 376.73 Ω

You haven't mentioned tables or line art, which i think are also
pretty important.

I've been working with some folks on drafts that describe MIME
structures, and the structure of Henrik's message
<[email-masked]> as delivered to me
is much more legible when i can render it with proper BOX DRAWINGS
symbols:

    └┬╴multipart/mixed 16878 bytes
     ├┬╴multipart/signed 9843 bytes
     │├┬╴multipart/mixed 8533 bytes
     ││└─╴text/plain 7576 bytes
     │└─╴application/pgp-signature attachment [signature.asc] 833 bytes
     └─╴text/plain inline 144 bytes

Rendering this structure with plain ASCII characters is possible, but it
is definitely harder to understand visually:

    |__ multipart/mixed 16878 bytes
     |__ multipart/signed 9843 bytes
     ||__ multipart/mixed 8533 bytes
     |||__ text/plain 7576 bytes
     ||__ application/pgp-signature attachment [signature.asc] 833 bytes
     |__ text/plain inline 144 bytes

and xml2rfc 2.32.0 complains when i try to render the BOX DRAWINGS
variant to text with lots of messages like:

     Warning: Illegal character replaced in string: &#9516;

Is there any reason to think that readers would rather see this:

    &#9492;&#9516;&#9588;multipart/mixed 16878 bytes
    &#9500;&#9516;&#9588;multipart/signed 9843 bytes
    &#9474;&#9500;&#9516;&#9588;multipart/mixed 8533 bytes
    &#9474;&#9474;&#9492;&#9472;&#9588;text/plain 7576 bytes
    &#9474;&#9492;&#9472;&#9588;application/pgp-signature attachment [signature.asc] 833 bytes
    &#9492;&#9472;&#9588;text/plain inline 144 bytes

As opposed to having the non-ASCII UTF-8 characters show up in the .txt
variant?

        --dkg

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Oct 2019 20:26:10 +0000

>       └─╴text/plain inline 144 bytes

Wouldn't that be more useful for readers as real art instead of ASCII-plus-sybols art?

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Oct 2019 22:30:58 +0200

> Wouldn't that be more useful for readers as real art instead of ASCII-plus-sybols art?

Good question.  For a CS guy, the indentation is actually all that is needed.
If you are more visual, Daniel’s form might help.  This is still text.
Going SVG means that the visualization becomes harder to maintain, copy&paste&derive, etc.

Grüße, Carsten

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 17 Oct 2019 16:33:10 -0400

> On Oct 17, 2019, at 4:00 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

This also goes for packet formats. The ASCII plus, dash, vertical bar symbols are not as nice as the box drawing symbols in a text only version.

Tom

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Oct 2019 22:34:13 +0200

> You haven't mentioned tables or line art, which i think are also

And — drum roll — message sequence charts.

(Tables are actually handled as such, so we don’t need Unicode Art for them.)

Grüße, Carsten

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 17 Oct 2019 20:23:13 -0400

> Going SVG means that the visualization becomes harder to maintain, copy&paste&derive, etc.

fwiw, i am a "CS guy" and i find the BOX DRAWINGS more useful than
indentation alone.  Maybe that means i'm not a "real" CS guy though :P

fwiw, i prefer text over SVG for these things because i like working in
a text editor, because diffs are clearer to read and understand, i can
automatically generate it with relative ease, etc.  I've got the whole
toolchain already there, and the only difference is the characters that
it appears i'm not supposed to use in a plain text document :/

If UTF-8-encoded text isn't allowed today in text/plain form, is there
some future time when we expect it to be allowed?  Or is there some
state of the world that we can test, and when it flips, then we'll be OK
with publishing it?  Or is the plain text format doomed to 7-bit "clean"
US-ASCII forever?

        --dkg

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Oct 2019 07:52:19 +0200

> with publishing it?  Or is the plain text format doomed to 7-bit "clean"

Please note that ASCII is UTF-8-encoded :-)

The funny thing is that beyond-ASCII is already allowed, but only in very specific places.
So we incur much of the costs of going from ASCII to Unicode.
Which is OK, because 2019 these costs are no longer high.

I think the 2013 sentiment was that more and more characters would eventually be permitted.
I believe this is highly misguided, because curating character sets is not something the RFCXMLv3 process should be engaging in.  Any hard boundaries being set up are quickly going to find a counterexample where they are unjustifiable.

Instead, we should make more use of editorial discretion.  Even with universal support of Unicode, there are concerns about readability and font availability of characters specific to non-English writing systems.  I think the RFC editor can make the case that numbers that are relevant for normative content should not be presented in Ottoman Siyaq Numbers, even without outlawing everything else.

We seem to work well with informally maintained, author-driven, fluid permitted lists in other places such as downref lists, mandatorily expanded abbreviations etc. — I think we don’t need to be more paternalistic with Unicode characters.  And, yes, I’d put U+25xy, with x from 0 to 7, on that no-problem list alongside U+0020 to U+007E…  Tooling (idnits?) that warns about characters in a manuscript that are not yet on that list might enable getting additions to that list early enough in the process.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Oct 2019 08:50:39 +0200

> As opposed to having the non-ASCII UTF-8 characters show up in the .txt

You can do this already by putting things into <artwork>, which is
needed here anyway (indentation, line breaks, monospaced font).

Best regards, Julian

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 18 Oct 2019 10:02:52 -0400

On Fri 2019-10-18 08:50:39 +0200, Julian Reschke wrote:
[dkg wrote:]
> needed here anyway (indentation, line breaks, monospaced font).

Hm, that's not what I'm seeing.  can you help me figure out what I'm
doing wrong?

With xml2rfc 2.32.0-1 (from debian unstable), source that contains this
block:

-----------
<figure><artwork><![CDATA[
└┬╴multipart/signed
 ├─╴text/plain
 └─╴application/pgp-signature
]]></artwork></figure>
-----------

produces output via the --text argument that contains:

-----------
   &#9492;&#9516;&#9588;multipart/signed
    &#9500;&#9472;&#9588;text/plain
    &#9492;&#9472;&#9588;application/pgp-signature
-----------

What should I do differently?

     --dkg

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Oct 2019 16:39:30 +0200

Hi Daniel,

> With xml2rfc 2.32.0-1 (from debian unstable), source that contains this

If you're seeing that, you probably haven't used the --v3 switch.

Best regards,

	Henrik

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 18 Oct 2019 14:51:17 -0400

> If you're seeing that, you probably haven't used the --v3 switch.

Thank you, Henrik!  That does the right thing for me, and produces much
nicer .txt output.

      --dkg