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/