Subject: i18n name badges

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Nov 2003 10:23:59 -0600

Proposals for making email addresses fully internationalized were a hot 
topic in Minneapolis. I'd like to suggest a more modest reform: fully
internationalized IETF name badges. IETF 59 might be a fine venue for
rolling those out...

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Nov 2003 09:03:53 -0800

Peter,

PSA> Proposals for making email addresses fully internationalized were a hot
PSA> topic in Minneapolis. I'd like to suggest a more modest reform: fully
PSA> internationalized IETF name badges. IETF 59 might be a fine venue for
PSA> rolling those out...

 I think that enhanced character sets is a perfect topic for having the
 IETF eat its own dogfood.  Just dealing with the details of the name
 tags might well prove instructive to us, nevermind the basic politeness
 it offers to attendees.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Nov 2003 13:07:37 -0500

--On Wednesday, November 19, 2003 09:03 -0800 Dave Crocker
<[email-masked]> wrote:

> Peter,
> 
> PSA> Proposals for making email addresses fully
> internationalized were a hot PSA> topic in Minneapolis. I'd
> like to suggest a more modest reform: fully PSA>
> internationalized IETF name badges. IETF 59 might be a fine
> venue for PSA> rolling those out...
> 
> 
>  I think that enhanced character sets is a perfect topic for
> having the  IETF eat its own dogfood.  Just dealing with the
> details of the name  tags might well prove instructive to us,
> nevermind the basic politeness  it offers to attendees.

If we are really going to eat our own dogfood, we should also
(or exclusively) print punycode on the badges and then everyone
can carry a ToUnicode converter on his or her laptop or PDA :-(

    john

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 19 Nov 2003 19:49:52 +0100

There is a better solution. I've seen already IPv6 enabled badges !

We used it in one of the IPv6 Forum conferences ... last June in San Diego.

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; "Peter Saint-Andre" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 19, 2003 7:07 PM
Subject: Re: i18n name badges

> can carry a ToUnicode converter on his or her laptop or PDA :-(

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2003 14:12:34 -0500

> Proposals for making email addresses fully internationalized were a
> hot topic in Minneapolis. I'd like to suggest a more modest reform:
> fully internationalized IETF name badges. IETF 59 might be a fine
> venue for rolling those out...

I'd love to see an Internet-Draft on the topic.  For instance, should
the badges be able to list multiple versions of a person's name and
affiliation?  How many versions?

That, and it seems appropriate to demonstrate running code.
Set up a web form where an attendee can type in his own names and
affiliations and have the backend generate a file to be printed out.

---

From: Fred Baker <[email-masked]>
Date: Wed, 19 Nov 2003 11:15:00 -0800

>internationalized IETF name badges. IETF 59 might be a fine venue for 

No problem, as long as nobody expects anyone in particular to actually be 
able to *read* the name badges. I don't read Han (simplified or 
traditional), Korean, Kanji, Cyrillic, Arab (either alphabet) or a variety 
of other alphabets. I manage with umlauts and such, because I can make a 
noise and the other person can say "yes, that's me, the way you pronounce 
my name is...". But I have no clue how to start in a non-ascii-like 
alphabet, and frankly with tonal languages such as Chinese my western mouth 
is likely to injure the person's name trying to get it out.

Aside: I had a Taiwanese employee once who would periodically give me 
lessons on how to say her name. It sounded to *me* like I was pronouncing 
it her way. One can only wonder what she was hearing...

Just speaking for myself, one of the things I really like about name badges 
is being able to determine, upon inspection, what to call the person 
standing in front of me.

BTW, while I understand that many Asians can read each other's writing, I 
don't think that implies they can read Cyrillic or Arab either. They're in 
a similar boat, if not the same one.

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.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 19 Nov 2003 21:07:52 +0100

Keith,

I'm not sure if you are joking, but I think is an excellent idea ...

A badge communication protocol ... if you start with the draft, I will be happy to contribute !

Regards,
Jordi

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Nov 2003 15:26:29 -0500

--On Wednesday, November 19, 2003 11:15 -0800 Fred Baker
<[email-masked]> wrote:

>> Proposals for making email addresses fully internationalized
>> were a hot  topic in Minneapolis. I'd like to suggest a more
>> modest reform: fully  internationalized IETF name badges.
>> IETF 59 might be a fine venue for  rolling those out...
> 
> No problem, as long as nobody expects anyone in particular to
> actually be able to *read* the name badges. I don't read Han
> (simplified or traditional), Korean, Kanji, Cyrillic, Arab
> (either alphabet) or a variety of other alphabets. I manage
> with umlauts and such, because I can make a noise and the
> other person can say "yes, that's me, the way you pronounce my
> name is...". But I have no clue how to start in a
> non-ascii-like alphabet, and frankly with tonal languages such
> as Chinese my western mouth is likely to injure the person's
> name trying to get it out.
> 
> Aside: I had a Taiwanese employee once who would periodically
> give me lessons on how to say her name. It sounded to *me*
> like I was pronouncing it her way. One can only wonder what
> she was hearing...
> 
> Just speaking for myself, one of the things I really like
> about name badges is being able to determine, upon inspection,
> what to call the person standing in front of me.
> 
> BTW, while I understand that many Asians can read each other's
> writing, I don't think that implies they can read Cyrillic or
> Arab either. They're in a similar boat, if not the same one.
> 
> 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. 

Fred, this is exactly what I was suggesting, only partially in
jest.  Native character set, plus punycode, which is much more
precise than a transliteration.  If we don't like the punycode
form,  we probably need to think about what we are doing to
users in the absence of a serious presentation layer.

     john

---

From: Leif Johansson <[email-masked]>
Date: Wed, 19 Nov 2003 21:35:30 +0100

JORDI PALET MARTINEZ wrote:
| Keith,
|
| I'm not sure if you are joking, but I think is an excellent idea ...
|
| A badge communication protocol ... if you start with the draft, I will
be happy to contribute !
|

bcp?

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2003 16:31:05 -0500

> A badge communication protocol ... if you start with the draft, I will

I'm working on lots of other things, and somehow I suspect that others
are more qualified than I am to get this rolling.

The point is that both defining how this should work and writing
proof-of-concept code are things that don't need to involve the 
secretariat.   It makes more sense for the secretariat to take this on
after we're sure we know what we want and it's been demonstrated to work
well, than to impose another vaguely specified burden on a secretariat
that is already quite busy.

Keith

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Wed, 19 Nov 2003 14:44:09 -0800 (PST)

If we do this, it should be WE (the IETF engineers) that do it and NOT
another thing we request the secretariat to do. We should eat our own
dogfood by writing, testing and then GIVING an implementation that is
compatible with the current label making system to the secretariat.

It's probably not too hard to do, given how the pre-reg badges are
produced (I am guessing), but may be much harder for the on-site badges
that are made using those little thermal printers.

From experience I can tell you that even adding the 3 extra characters we
have in Scandinavian can cause all sorts of interesting problems when
mixed with different output equipment. Add multi-byte characters and you
may see line-printers shutting down and opening their lids indicating
"paper out" or generating spurious form-feeds. OK, so we don't use
line printers any more, but you get the idea :-) [If anyone still
remembers how to make a line printer attached to an IBM 370 do this by
sending just the right sort of code, you get extra points].

The good news is that modern operating systems (ahem) tend to have Unicode
and other nice support built-in, but this doesn't necessarily mean that
output is a breeze.

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Tel: +1 408-527-8972   GSM: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

<control>-L here:

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Nov 2003 15:56:11 -0800

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

---

From: [email-masked]
Date: Wed, 19 Nov 2003 21:51:45 -0500

> sending just the right sort of code, you get extra points].

The IBM 1403 printer (1200 lines per minute, print chain and hammers) could be
induced to do that fairly easily by specifying the right CCW (no, you
couldn't do with with a Fortran-style column-1-char trick).  You would
however get extra points for figuring out how to get HASP to put the CCW
into the spool file.  It was pretty trivial under VM/CMS however....

http://www.columbia.edu/acis/history/1403.html

(1403's could be induced to play music as well).

The IBM 3800 (20K lpm laser printer) - now if you managed to get THAT beast
to open its lid, that was impressive.

http://ukcc.uky.edu/~ukccinfo/ibm3800.html

---

From: James Seng <[email-masked]>
Date: Thu, 20 Nov 2003 11:05:37 +0800

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Nov 2003 11:48:09 +0100

> Punycode, as it is designed, is meant for machine-to-machine 

So why don't we come up with a machine-to-human transliteration 
mechanism? So if someone called Ζεὺς (trouble with spamcontrol 
again...) a translation table could turn this into Zeus and back again 
where appropriate. If the translation table doesn't know "Ζεὺς" this 
could be translated into ZITA-epsilon-ypsilon+grave-sigma, which isn't 
great but still much better than just numbers or base64 or whatever.

> names together with their ASCII version on the name badge especially 
> for the next IETF.

> 1. What if the person don't have ASCII only name?

I guess do the same thing as is being done today...

>     maybe the fonts is there but the rendering is wrong?)

Easy enough: allow people to supply a graphic.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 20 Nov 2003 08:07:56 -0600

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.
> 
> 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/

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 20 Nov 2003 10:12:50 -0800

>how to pronounce the name, and the email/idna encoding[s] that folks would

Folks: it has *not* been decided that there will be a different 
encoding for email. One such encoding has been proposed; other 
proposals have been made. This is being actively discussed, and there 
should be no assumption that the discussion will end with a new 
encoding.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: John C Klensin <[email-masked]>
Date: Sat, 22 Nov 2003 10:03:16 -0500

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 
<[email-masked]> 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...
>
> 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
>> --

---

From: Dave Crocker <[email-masked]>
Date: Sat, 22 Nov 2003 08:42:46 -0800

John,

JCK> The design of Punycode was for machine-to-machine communication, as
JCK> you point out. It was never really intended or expected to "leak"
JCK> into use environments.
...
JCK> Indeed, it was chosen, in preference to some other options, on the
JCK> grounds that
JCK> 	* it could be deployed quickly,
JCK> 	* applications could (and would) be speedily updated to ...
JCK> 	* when it did leak, users would find that acceptable ...

The ascii-encoding paradigm for incremental adoption is "expected" to
have four usage characteristics:

     1. It can be deployed usefully on an incremental basis, where
     "incremental" means that it becomes useful when very few people
     have adopted it -- for example, useful for the first two users that
     exchange it -- and is increasingly useful as more people adopt it.

     2. It is transparent to the transfer infrastructure

     3. When it shows up at an un-modified application, such as a mail
     user agent, it does not break the system.

     4. Data entry can be done in unmodified application, such as an
     email Reply command, albeit typing the string will probably not be
     an experience to savor.

Hence, #1 #2 mean it can be deployed quickly because it does not
require everyone to adopt it, before it is useful. This is in marked
contrast with any approach that first requires modifying the
infrastructure.
     
#2 and #3 clearly imply that end-users will see these strings. So,
leakage is entirely expected.  It is not desired, but it is expected.

The concern is not whether such leakage occurs or whether the string is
human-friendly.  The concern is whether anything breaks, when it does
show up, as we know it will.

And, indeed, Punycode does not break legacy software. So it satisfies
the requirements and expectations of this incremental adoption paradigm,
just fine.

JCK> The reality so far is different.  The IDN browser world has 
JCK> turned into one of conflicting plug-ins, apparently none of 
JCK> which are fully satisfactory.

Since I am far less than a diligent reader, I have not seen the
discussion of this, but I certainly would like to understand it better.
Any citations to material on this would be appreciated.

My sense of most adoption processes, for any interesting bit of
application technology, is that it has an ugly startup.

For example, the first interoperability test of TCP did not initially
work. Folks had read the spec differently for the checksum algorithm.
(And the way this was resolved was to look for the first pair of hosts
that could communicate and then retrofit the specification with whatever
algorithm they were using.)

Another downside of not being a diligent reader is that I do not recall
seeing discussion of interoperability testing for IDNA. Surely it has
been done? Should more events be scheduled?

JCK> For other applications, the 
JCK> conversion/ upgrade rate has been low and most estimates seem to 
JCK> point to its being at least 18 more months before we see 
JCK> significant progress in applications that have really wide 
JCK> deployment

Let's ignore that the RFCs were issued only in March of this year. Let's
use the IESG Last Call as the "release" date. That means May, 2002.

Starting from that milestone, and accepting your estimate of 18 months,
it means that IDNA will be significantly useful within 3 years of
completion.

Offhand, I'd say that matches the experience with MIME, and matches the
general expectations for adoption of a scheme that provides incremental
benefit. This is quite a bit shorter than the adoption times for an
approach that requires infrastructure change. (Even now, does anyone
really rely on email Delivery Service Notices working over the public
Internet? It had its last call in 1995.)

So, your assessment of the likely time it will take for IDNA to be
significantly useful strikes me as very good news, indeed.

JCK> the IETF community should probably understand what it looks like
JCK> and what the issues are in converting to and from it, including 
JCK> the fact that, for expression of "names", nameprep is a lossy 
JCK> conversion.  And that is precisely the "eat our own dogfood" 
JCK> point.    More important, we need to think about --and probably 
JCK> experience-- that point as we consider approaches for email 
JCK> local parts, which more often contain names  about which people 
JCK> are _really_ sensitive.

The question of lossiness does not have to do with the incremental
adoption paradigm. It has to do with problems in the details of the IDNA
mapping algorithm.

My own suspicion has been that it tries to do too much. That is
certainly my sense of the IMAA scheme. It needs to do less. It needs to
be more literal.

From a design standpoint, this is a matter of tuning the details, rather
than rejecting the paradigm.

d/

---

From: James Seng <[email-masked]>
Date: Sun, 23 Nov 2003 19:47:16 +0800

John,

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
> 
> 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
> 
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 23 Nov 2003 21:15:22 +0100

On 23-nov-03, at 12:47, James Seng wrote:

> 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.

This implies that the conversion must take place at the semantic level 
rather than the encoding level. This should result in converted 
representations that can be pronounced, remembered and recognized, at 
the cost of somewhat large translation tables.