[rfc-i] open issues: character encoding of names
Iljitsch van Beijnum
iljitsch at muada.com
Thu May 31 12:44:28 PDT 2012
On 31 May 2012, at 19:58 , Tim Bray wrote:
> Yep, hard to argue with.
(If you had put the quote before the agreement we'd know what you are not arguing with.)
> I assume it would be optional, so if Sally
> Müller finds Mueller offensive, she doesn’t *have* to provide it.
You mean that the author is listed as Sally Müller only? Then what if someone reads the RFC on a terminal that can't display the ü character? Or a user wants to send Sally a message, but doesn't know how to type the ü character? (Obviously harder to type characters can be imagined.)
>> On 5/31/12 11:47 AM, Andrew Sullivan wrote:
>>> The argument for encoding author names with characters outside the
>>> ASCII range is that this allows us to spell people's names correctly.
Not that I'm necessarily against that, but let's not waste too much time on something that doesn't help us write better protocols.
>>> The argument against it is, apparently, that people who don't speak
>>> the language of the author won't be able to read the author's name.
>>> Therefore, a transliteration of the author's name into English is
>>> required. This is appropriate, it is argued, because the language of
>>> the IETF is English.
Language != script. There are many languages that use the latin script. All of the speakers of those languages can type English names, even if they can't pronounce them.
By definition, everyone participating in the IETF can use the latin script. Some participants know one, two or even three additional scripts, but each individual script is inaccessible to at least 50% and probably 90%+ of the IETF participants. As such, any text is any non-latin scripts can only be decoration and never be useful as an integral part of an RFC.
More information about the rfc-interest