Re: i18n name badges

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(_at_)pobox(_dot_)org(_dot_)sg> 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>