Subject: [Tools-discuss] <contact/>: asciiFullname should be latinFullname

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Oct 2020 06:19:53 +0200

[I was really trying to send this to rfc-interest, but that doesn’t seem to take.]

I’m trying to use the contact element:

<contact fullname="トヨタ自動車株式会社" asciiFullname="Toyota Jidosha KK"/>

works, but that is actually a bad transliteration.

What it really should say:

<contact fullname="トヨタ自動車株式会社" asciiFullname="Toyota Jidōsha KK"/>

But that transliteration is not entirely ASCII, so I get this error:

foo.xml(76): Error: Found non-ascii content in <contact> attribute value asciiFullname="Toyota Jidōsha KK"

Why do we allow Latin names in contact names, but if we have a non-Latin name, then the transcription suddenly needs to be ASCII, not just Latin?

Grüße, Carsten

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 7 Oct 2020 02:51:27 -0400

> On Oct 7, 2020, at 12:20 AM, Carsten Bormann <[email-masked]> wrote:.
> 

Another related question:

How many times do we have to endure restrictions on UTF-8 characters in a UTF-8 document. Can we please just allow UTF-8 characters anywhere in a document?

It’s not like we don’t have multiple levels of an editor process to resolve any issues with incorrect use.

Tom

---

From: Julian Reschke <[email-masked]>
Date: Wed, 7 Oct 2020 09:54:14 +0200

Am 07.10.2020 um 08:51 schrieb Tom Pusateri:
> ...
> ...

Indeed.

We shouldn't need a phrase-level "contact" element in the fist place.

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 07 Oct 2020 20:17:23 +1100

I also agree with these fine folks.

There are reasons to show restraint.  And I thought that was what motivated very narrow rules.  For instance, we might not want quotes being anything other than '" because allowing variance leads to inconsistency.  Same for hyphen vs. en-dash and em-dash.  But the way to deal with that is to build tools that fix the issue one way or other.  xml2rfc is already aware of these problems and has some ability to manage that particular problem.  For instance, kramdown applies smart quotes from ", and then xml2rfc undoes that.

For the rest, a tool that highlights characters from outside a narrowly defined range (printable and whitespace ASCII for instance) would do wonders for ensuring that odd stuff doesn't creep in, like a BOM or a bunch of ZWNJ.  Beyond that, allowing people to have their names without having to resort to nasty hacks would be awesome.

On Wed, Oct 7, 2020, at 18:54, Julian Reschke wrote:
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Oct 2020 14:57:35 +0200

> We shouldn't need a phrase-level "contact" element in the fist place.

While this is true from a final form readable document generation point of view, marking people semantically does have some value.
Right now that only happens if somebody has a beyond-ASCII name; that outcome indeed does not make a lot of sense.

My proposal was trying to stay inside the current system and just fix the bug that transliterations cannot reasonably be limited to ASCII; I would like to get this fix done independently from any larger repertoire fixes to RFCXMLv3.

There is, of course, no need to actually change the attribute name; simply allowing Latin values for the attribute solves the problem.

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 7 Oct 2020 15:10:15 +0200

Hi Carsten,

On 2020-10-07 06:19, Carsten Bormann wrote:
> Why do we allow Latin names in contact names, but if we have a
> non-Latin name, then the transcription suddenly needs to be ASCII,
> not just Latin?

The original specification was strict ASCII.  After feedback on the list
about common practice for publishing houses we moved to permitting Latin
script in some places.  Not allowing Latin script in your case above is
a remnant of the original implementation; I see no reason not to move
in the direction of permitting Latin script here, too.

Best regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 7 Oct 2020 16:20:31 +0200

Am 07.10.2020 um 15:10 schrieb Henrik Levkowetz:
> ...
>
> The original specification was strict ASCII.  (...)

Pointer?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Oct 2020 16:32:01 +0200

>> The original specification was strict ASCII.  (...)

RFC 7991 Section 2.7.1-.3 (and a ton of “ascii” attributes patched into other places) says “ASCII”.  Not “strict ASCII”, but I don’t know the difference between the two.  RFC 7997 says ASCII or ASCII-only when it really is talking about “accessible to a reader familiar with the Latin writing system” (except maybe for Section 3.4); that is exactly the bug that I’m trying to address.

Of course, the Relax-NG in RFC 7991 doesn’t enforce that textual mandate, so no schema change is needed to fix this bug.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 7 Oct 2020 16:40:32 +0200

> Of course, the Relax-NG in RFC 7991 doesn’t enforce that textual mandate, so no schema change is needed to fix this bug.

RFC 7991 Section 2.7 is about <author>.

What we are discussing here is using names in prose, that is not
described in 7991.

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

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

So the v3 RFCs indeed says that an ASCII-only identifier should be
present (I forgot about that). What RFC 7997 does *not* say is how the
XML for that is supposed to look. That's right because that's 7991's
job, and my recollection of the history of 7991 is that we did not feel
any special markup was needed for that.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 7 Oct 2020 17:01:42 +0200

Hi Carsten,

On 2020-10-07 16:32, Carsten Bormann wrote:
> RFC 7991 Section 2.7.1-.3 (and a ton of “ascii” attributes patched
> into other places) says “ASCII”. Not “strict ASCII”, but I don’t know
> the difference between the two. RFC 7997 says ASCII or ASCII-only
> when it really is talking about “accessible to a reader familiar with
> the Latin writing system” (except maybe for Section 3.4); that is
> exactly the bug that I’m trying to address.

Sorry for my linguistic mistake.  I was trying to say 'ASCII' in the
sense of strictly ASCII.

As for what 7991 is really talking about, interpreting 'ASCII' as
“accessible to a reader familiar with the Latin writing system”, rather
than strictly ASCII, I'll leave that interpretation as yours.  That's not
the understanding I got from 7991.

I indicated earlier that I thought expanding the use use of Latin to
the case you raised was reasonable, but it seems that response wasn't
enough for you, so now I have no idea of how to respond.

	Henrik

> Of course, the Relax-NG in RFC 7991 doesn’t enforce that textual
> mandate, so no schema change is needed to fix this bug.> 
> Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Oct 2020 17:39:48 +0200

Hi Henrik,

I was trying to respond to Julian here.

> On 2020-10-07, at 17:01, Henrik Levkowetz <[email-masked]> wrote:
> 

Me neither, in particular with the example in the companion 7997 that gave an ASCII-only “identifier” (cleverly avoiding the transliteration/transcription dilemma) for a Latin name.  However, it seems to me that it simply didn’t occur to the people involved in the process that led to RFC 799x that transliterations tend to use beyond-ASCII characters (or they considered pure-ASCIIness more important).

> enough for you, so now I have no idea of how to respond.

No, I totally agree with your response.  I just tried to answer Julian’s question.

So we do need a bit of a variance here from RFC 7991.  We could do that the same way all the other variances have been handled (such as introducing the <contact/> element that didn't exist in RFC 7991 either).  Or we could somehow convince ourselves this is suddenly a major change (e.g., because the attributes are called “ascii”something they really should stay ASCII-only).  I don’t think it is, but if I could post to the rfc-interest list, I would love to hear whether people there agree, too.

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 7 Oct 2020 18:02:41 +0200

Hi Carsten,

On 2020-10-07 17:39, Carsten Bormann wrote:
> Me neither, in particular with the example in the companion 7997 that
> gave an ASCII-only “identifier” (cleverly avoiding the
> transliteration/transcription dilemma) for a Latin name. However, it
> seems to me that it simply didn’t occur to the people involved in the
> process that led to RFC 799x that transliterations tend to use
> beyond-ASCII characters (or they considered pure-ASCIIness more
> important).
> 
>> I indicated earlier that I thought expanding the use use of Latin 
>> to the case you raised was reasonable, but it seems that response
>> wasn't enough for you, so now I have no idea of how to respond.
> 

Ah, ok.  Good then.

> So we do need a bit of a variance here from RFC 7991. We could do
> that the same way all the other variances have been handled (such as
> introducing the <contact/> element that didn't exist in RFC 7991
> either).

I think the decision to permit Latin script for names applies here.  I
don't see this as a new decision, but a matter of applying an already
settled question consistently.

Best regards,

	Henrik

> Or we could somehow convince ourselves this is suddenly a
> major change (e.g., because the attributes are called
> “ascii”something they really should stay ASCII-only). I don’t think
> it is, but if I could post to the rfc-interest list, I would love to
> hear whether people there agree, too.
> 
> Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Oct 2020 18:19:18 +0200

> settled question consistently.

+1

Grüße, Carsten