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

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 8 Oct 2020 14:45:22 +0200

Hi John,

On 2020-10-07 21:18, John Levine wrote:
> In article <[email-masked]> you write:
>>[I was really trying to send this to rfc-interest, but that doesn’t seem to take.]
> 
> Moved there now.
> 
>>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?
> 
> Because the <contact/> element was added to the grammar without any
> review.

That's incorrect.  There was both discussion and review.

> We don't know whether it's for ASCII versions of non-ASCII
> names, Latin versions of non-Latin names, or tagging every time a
> person's name appears. The RSOC is setting up a small ad-hoc group to
> review XML changs and I'll put this on the list. Until we do, please
> do not make any changes to what it does, even if that currently seems
> wrong.
> 
> Looking at RFC 7997, when it says ASCII, it really means ASCII.

It did, yes.

> At the
> time there were still some systems that only spoke ASCII, and more
> importantly tools like grep that only worked with single-byte
> characters.

As I recall it, that wasn't the main reason for the ASCII limitation,
although it may have been mentioned.  It had more to do with being
cautious in moving forward, and gaining experience with permitting non-
ASCII in selected elements before opening up for wider use of non-ASCII.

And post-7991/7997, there was discussion about permitting Latin names in
some contexts not permitted by 7991, and the change was approved by the RFC
Editor, Heather.

> In retrospect, that was a mistake since every current
> display device can display anything, and text handling software now
> deals with locales and UTF-8 pretty well. 

You are simplifying the reasoning behind the restriction to ASCII
substantially here, and I disagree about it being a mistake.  I think
it was the right decision at the time, and it has permitted us to move
forward in a controlled manner, without being challenged by Unicode
issues in all possible contexts at the same time we had a major schema
change.

> I think we should update 7997 to say that Unicode is allowed anywhere
> it visually makes sense, and the style guide can say what to do with
> non-Latin names, but again it's not something we can do unilaterally.

I don't think Unicode anywhere is right for a standards publication in
English; the reason to require <u> to be used, and expanded to reflect
the exact code point values of a string, is just as valid now as when
the limitation was put in place.

For an illustration of how easily things can go wrong without the kind of
support that <u> offers, 7997 itself mentions U+2206 ("INCREMENT") but actually
shows the character with code point U+0394, "GREEK CAPITAL LETTER DELTA"
as if it was U+2206.

Permitting Unicode anywhere makes it pretty near impossible to catch such
mistakes with tooling, and will not substantially improve authoring.

Permitting Latin script, rather than ASCII, for an English-language standards
publication can be defended, I think, but not Unicode straight up.

Ack on this not being anything we can do unilaterally, though.

	Henrik

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest