Dave Crocker wrote:
What I would suggest, if we do this, is writing the person's name
*twice*: once in their native character set, and once in a form that
an english-reader can read. The latter is an established interchange
architecture
I believe that was the intention in the proposal. List names in the
same way we always have, AND list them in their "native" form.
Whether it would helpful to provide a third form -- the ascii encoding
of the native form, as it would be seen in an email address header --
is a separate question.
It seems to me that this is really the heart of the matter. There are too
many encodings.
There are going to be *at least* three desirable encodings of a person's
identity -- the 'natural' encoding in the preferred/native charset of the
person's name, some kind of phonetic-ASCII encoding that tells non-natives
how to pronounce the name, and the email/idna encoding[s] that folks would
use to exchange mail.
Of the two 'name' forms, it might be possible for the protocol to choose
just one encoding based on the meeting context. For example, if the
meeting attendees are entirely (or mostly) native speakers of the same
language, then use the natural encoding for the names and just ignore the
phonetic ASCII entirely. If the meeting is heavily internationalized, then
the phonetic form is needed and the natural forms are less useful and can
be dropped. So, I would think that part of the protocol should look at
trying to determine the meeting context, choose the appropriate encoding,
and drop the other (contextually inappropriate) name representation. I
think that the default case for IETF meetings would probably be the
phonetic ASCII representation given the constituency, but the protocol
should still attempt to deliver on the right context even when we know
what the context will be for these particular meetings.
I would also suggest that if the meeting context is determined to be
mostly local, and the name is determined to use a natural encoding, then
any contact (email) data should also be provided in that encoding, since
it will be memorable to people who can understand the name context. If the
meeting context is mixed-international, then an ASCII representation
should be used. Whether or not the ASCII representation is IDNA or a
phonetic (pre-IDNA) address is up to the the person who provides that
data. Also, the designers should remember that there will be some cases
where meetings that prefer natural encodings will still have phonetic
contact addresses (pre-IDNA, again).
If done correctly, there would only need to be the two identifiers, and
they would only need to be provided in a single encoding each, determined
by the context of the specific meeting itself.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/