Ah I see now. Yes, there is leakage in Punycode now and will be for a while. It is not "nice" but I couldnt think of any encoding which wont leak. (UTF-8 will give you gibberish if client are not UTF-8 aware or with the right fonts). Same arguments we have in IDN WG many years ago.
We want to put punycode on the badge so that "eat our own dogfood", then yes, maybe we should. But given the space constraint on the badges, I rather put something more meaningful, like an .PNG of the person name.
-James Seng
John C Klensin wrote:
James,
My apologies for being a bit cryptic -- I hoped people would understand the issues well enough by now to get the point. The difference between the design of --and hopes for-- IDNA and what is happening is something the community needs to understand and be better informed about. The design of Punycode was for machine-to-machine communication, as you point out. It was never really intended or expected to "leak" into use environments. Indeed, it was chosen, in preference to some other options, on the grounds that
* it could be deployed quickly,
* applications could (and would) be speedily updated to
support it and provide proper "native" character set
presentation to users,
* when it did leak, users would find that acceptable
because they could always convert to and from
native/local characters with cut and paste and
readily-available tools.
The reality so far is different. The IDN browser world has turned into one of conflicting plug-ins, apparently none of which are fully satisfactory. For other applications, the conversion/ upgrade rate has been low and most estimates seem to point to its being at least 18 more months before we see significant progress in applications that have really wide deployment (and estimates that optimistic often depend on other conditions or contingencies that might or might not happen). So IDNA/punycode is leaking a lot, and can be expected to leak a lot for the next several years, at least. And that implies that the IETF community should probably understand what it looks like and what the issues are in converting to and from it, including the fact that, for expression of "names", nameprep is a lossy conversion. And that is precisely the "eat our own dogfood" point. More important, we need to think about --and probably experience-- that point as we consider approaches for email local parts, which more often contain names about which people are _really_ sensitive.
john
--On Thursday, 20 November, 2003 11:05 +0800 James Seng <jseng@xxxxxxxxxxxx> wrote:
I think having the punycode form have no "value" on a name badge. Punycode, as it is designed, is meant for machine-to-machine communication.
But I like the idea of allowing participation to put their own native names together with their ASCII version on the name badge especially for the next IETF.
But...
1. What if the person don't have ASCII only name? (e.g. Patrik Fältström)
2. What if the person have a name which the computer cant be printed? (Maybe it is not in ISO 10646, maybe it is but there is no fonts, maybe the fonts is there but the rendering is wrong?)
Since we are on the topic of the name badge, it is possible to somehow tag the family name of the person? (e.g. underline? bold? captialized?) Not everyone follows the <Last Name> <First Name> convention. In fact, the concept of "First and Last" name is quite alien to me.
-James Seng
Dave Crocker wrote:
Fred,
FB> What I would suggest, if we do this, is writing the person's name *twice*: FB> once in their native character set, and once in a form that an FB> 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.
/d -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg InternetWorking <www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>