Subject: [rfc-i] Unicode names in RFCs and xml2rfc

From: "Martin Thomson" <[email-masked]>
Date: Wed, 04 Dec 2019 13:31:15 +1100

I'm reading the code in xml2rfc to work out how it is intended to work and finding it extraordinarily difficult to achieve a relatively modest goal: putting a person's name into the document.

My requirements are simple: acknowledge contributions using a person's preferred name.  More concretely, I see no value in expanding ø or ü, but I would however like to provide ASCII analogues of the Japanese names in the list.   This goal seems consistent with the text in RFC 7997:

   Person names may appear in several places within an RFC (e.g., the
   header, Acknowledgements, and References).  When a script outside the
   Unicode Latin blocks [UNICODE-CHART] is used for an individual name,
   an author-provided, ASCII-only identifier will appear immediately
   after the non-Latin characters, surrounded by parentheses.  This will
   improve general readability of the text.

I'm talking about acknowledgments, so the list appears in a <t> element.  The intent is to render the list of names in an ordinary paragraph, with commas separating each.

None of the elements that permit Unicode text fit in this context.  I realize that I could use <artwork> for this, but that's clearly an abuse of that element; more so because it renders very differently depending on context (I could probably do something with SVG, now that I think of it...).  

<u> is singularly unsuitable for this purpose.  It insists on - at a minimum - including the U+NNNN notation for every character.  If I could use format="char" or format="char-ascii" it might be acceptable.  Assuming that I have properly understood the code.  The <u> element is not documented in RFC 7991.

I appreciate the value in having a clear signal from the author that a block of text is intended to include Unicode.  Unicode tends to lead to all sorts of inconvenient inconsistencies, like multiple different dash and hyphen styles, quoting variations, and other such oddities.  I can (grudgingly) accept that some sort of indication is appropriate so that what should be relatively uncommon text usage can be scrutinized additionally.

It shouldn't be this difficult to acknowledge someone using their name.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 4 Dec 2019 05:45:45 +0000

I couldn't agree more with what Martin Thomson writes below. This must 
be an oversight somewhere, and hopefully can be fixed quickly.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 Dec 2019 06:48:28 +0100

> It shouldn't be this difficult to acknowledge someone using their name.

This has been raised as
<https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/416> (end of August).

Best regards, Julian

PS: it seems that the issue tracker actually is unmaintained; tons of
tickets are in the "New" state, although some of the issues apparently
have been addressed. Is there a better place to raise issues?
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 4 Dec 2019 10:54:50 +0100

Hi Martin,

I agree with what you say.  And a different mechanism than <u> is indicated.

I'd love to make it possible to use a <contributor> element with the same
child elements as <author> in text, to achieve rendering of contributors
in the same format as authors, with the same provisions for both ASCII and
non-ASCII content.  However, accomplishing any changes to the schema which
the design team didn't envision has been hard; so hard, actually, that I've
had to step back and mostly stop engaging on the xml2rfc-dev list.

Regards,

	Henrik

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 04 Dec 2019 21:20:10 +1100

> had to step back and mostly stop engaging on the xml2rfc-dev list.

In this case, where I'm looking for acknowledgments only, a <contributor> element wouldn't help.  I'm just looking for a name, not something equivalent to an author block.

In this case, it's the requirement to include 'num' in the format for <u> that is a little over-constraining.  A generic "this is unicode" element is fine, but coupling that to a particular output is what I'm finding problematic.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 4 Dec 2019 11:34:23 +0100

Hi Martin,

On 2019-12-04 11:20, Martin Thomson wrote:
> In this case, where I'm looking for acknowledgments only, a
> <contributor> element wouldn't help.  I'm just looking for a name,
> not something equivalent to an author block.

There are several possible renderings for an author block, depending on
context.  Making it possible to control this for a contributor entry would
make sense.

> In this case, it's the requirement to include 'num' in the format for
> <u> that is a little over-constraining.  A generic "this is unicode"
> element is fine, but coupling that to a particular output is what I'm
> finding problematic.

You're trying to use the <u> entry for something it very explicitly wasn't
designed for.  A <contributor> entry would not only be able to give you the
output you want, it would also provide the correct semantic labelling in the
XML file.

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 Dec 2019 11:53:25 +0100

> In this case, it's the requirement to include 'num' in the format for <u> that is a little over-constraining.  A generic "this is unicode" element is fine, but coupling that to a particular output…

+1

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 Dec 2019 11:58:17 +0100

On 04.12.2019 10:54, Henrik Levkowetz wrote:
 > ...

+1, which is exactly what I proposed in
<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/81>.

If we do this, calling it "<contact>" actually might be better.

> ...

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Dec 2019 12:00:22 +0100

Hi Henrik,

On Dec 4, 2019, at 11:34, Henrik Levkowetz <[email-masked]> wrote:
> A <contributor> entry

Where can I read up on this?
Already checked RFC 7991 and draft-levkowetz-xml2rfc-v3-implementation-notes.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 Dec 2019 12:00:34 +0100

> context.  Making it possible to control this for a contributor entry would

That's a possibility, but IMHO that just makes things more complicated
than needed. Sometimes a string is just a string.

> ... > You're trying to use the <u> entry for something it very explicitly
wasn't
> output you want, it would also provide the correct semantic labelling in the

What would that labelling be used for? Not every name mentioned in an
RFC necessarily refers to a contributor, after all.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 4 Dec 2019 12:03:21 +0100

Hi Carsten,

> Already checked RFC 7991 and draft-levkowetz-xml2rfc-v3-implementation-notes.

This is a proposal I'm making now, which has grown out of previous
discussions around the subjects.  It's gradually come together in my
mind as a reasonable approach to what is clearly an issue experienced
by document authors.

Best regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 4 Dec 2019 12:06:14 +0100

> Already checked RFC 7991 and draft-levkowetz-xml2rfc-v3-implementation-notes.

A proposal is over here:
<https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.contributor>

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 6 Dec 2019 16:49:55 +0100

> mind as a reasonable approach to what is clearly an issue experienced

OK, I see <https://trac.tools.ietf.org/tools/xml2rfc/trac/changeset/3490>.

1) I agree and like the addition of <contact> as block-level element.
This solves the "how to style the contributors section" question we've
ignored for years.

2) Adding "<contact>" as phrase-level element: IMHO not a good idea.

2a) ...because allowing elements to appear both in block context and
flow context is asking for trouble. For instance: what if the <contact>
element inside <t> contains actual postal information?

2b) As I said before, there are more reasons to use non-ASCII than names
of contacts. For instance, what if I want to refer to the title of a
book? I know that this isn't currently mentioned in RFC 7997, but I
think wiring this into the grammar is the wrong approach.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Dec 2019 18:53:04 +0100

On Dec 6, 2019, at 16:49, Julian Reschke <[email-masked]> wrote:
> 
> As I said before, there are more reasons to use non-ASCII than names

We just haven’t had the first RFC yet that needs to discuss Mößbauer spectroscopy.
Or maybe a Schrödinger equation (or Schrödinger’s cat).
How about Ångström?  (Fortunately, that is not an SI unit, but André-Marie Ampère gave his name to the ampere.)
And I’m still using 50 Ω coax and PCB traces that are some µm thick.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Dec 2019 08:26:46 +1300

There is indeed a smörgåsbord of possibilities. We would have to open this
up as a consensus discussion, I think, but it seems that a little more
flexibility is needed in the rules.

Regards
   Brian