Re: Further thoughts on preferred printable representations...

There are three ways of considering the problem we have to keep in mind and 
this thread underlines:
1. the proposition by a developpers team (in here) - let say IETF proposition
2. a consensus by opertors (what they now look for through tests) - let say 
ITU standardization
3. the real need of the users what will actually filter the above into what 
will develop.

I would say this translates into:
- internationalized names: the introduction of the Unicode character set 
into the Legacy name space
- multilingual names: the consideration of one name space per language (and 
country due to the way ccTLDs are organized)
- vernacular names: the way the users networks, applications developpers, 
states, etc. need them and will use them.

IDNs do not fit the whole job, but this is what we have at hand and it is 
urgent we start with them.

MDNs are to be organized in the quickest way so the network keep stability 
(national and lingual roots) . Obviously ICANN cannot manage it because 
this concerns the entire world beyong the Legacy borders. But it should 
share in it. However past focusing on "alt.roots" in a wrng way has not 
prepared ICANN and IETF and made them overlook the ICANN ICP-3 writer's 
call for experimentation and innovation. So we are late and unprepared to 
dialog with ITU and others (ITU Marrakech Resolution). But whatever the way 
we do it, our "I-Sector" must conduct this, not the T-Sector and UN.

E-Mail addresses are a free area for the users where he can indicate how he 
imagines Internet vernaculars. So, I think we should have an iterative 
process matching what James/Paul proposes, as well as Roy and Daniel. We 
only do it the other way around because WG-IDN was not permitted to carry 
its charter and to  investigate the users and the DNS Managers firts: what 
we must do now the standard is imposed.

- IDNA is here. It is raw material. There is a need. Let patch our 
imgination of the user's behavior: we will correct later on. Some proposes 
variants (a priori prevention), I propose context control (a postriori 
corection). Probably both are good and urgent. Let learn and proceed.

- Let help experience and real life operations. The best way is to develop 
the virtual zone concept (each domain name is attached a "context" 
parameter, i.e. the language of its registration contract). Let see what it 
comes from that and what we build on top (IMHO an architectural revolution 
but without discontinuity). This way operators will relax, be able to 
operate and to consider the WTO Services Round imlications (which IMHO 
might be major).

- let be innovative in the users usage area too. We are talking of business 
cards. Question: is it reasonable to still use XVIIIth century business 
cards and to force us to adapt to them? When you are going to buy potatoes 
the package will wear a chips with far more information than you have on 
your business card. Should we not consider smart business cards or simple 
cards with a magnetic strip? And see what the people actually do when the 
e-mail name becomes mainly something to see and not to type.

The same, would there not be time to slightly upgrade the mail system and 
adopt some very simple method simmilar to SSH: the first time I relate with 
another e-mail agent my agent asks it some information and I may add my 
ones. Simply look at lack of presentation services of the today major 
e-mail agents. Would someone develop an Outlook+Eudora enhancement 
including serious e-mail data base manament, most probably things discussed 
in here would be very different or non existing.

Please tell me what I gained in 26 years of e-mail usage? When I started I 
could sort my mails without reading them, encrypt them, store them in my 
database, etc. OK I was with the leading public network company and a major 
timesharing service with computer power ... but we were 8 bits at that time 
and core memore of 1 Meg was very big.

Would this vernacular need not be a good occasion/alibi for a general 
review of the mail system? I tend to feel it could be easier than DNS - if 
we add to and not replace. And a way to lead to a DNS revamp that everyone 
will accept and even want.
jfc

At 01:52 13/06/03, D. J. Bernstein wrote:
>Roy Badami writes:
> > The prefered printable representation[1] of an e-mail address is a
> > vital concept, as I argue in my previous message.
>
>One of the big flaws in IDNA is its failure to recognize this basic fact.
>As I wrote in http://cr.yp.to/djbdns/idn.html:
>
>    The value of a character-set expansion comes entirely from the
>    visibility of the additional characters to users. There is no point
>    in merely expanding the set of bytes allowed inside the computer; the
>    internationalized domain name {alpha}{beta}{gamma}.com must be
>    displayed with Greek letters on a typical user's screen.
>
>The same issue arises for any piece of text. There's nothing special
>about domain names, or mailbox names, or blah.html, or chat usernames,
>or whatever tomorrow's textual identifiers will be.
>
> > It is what I print on my business card.
>
>There's a difference between what should appear on a screen for users
>to see, and what should appear in print for users to type. As I wrote
>on the idn mailing list two and a half years ago:
>
>    Operating systems are all going to support direct input of Unicode
>    characters by number. The ISO standard method is Shift-Ctrl-222E for
>    character 222E.
>
>    People who put hard-to-recognize characters onto their business cards
>    are going to add a line giving the Unicode numbers, perhaps in boxes:
>
>       [email protected]            (with a contour-integral sign)
>
>                  +----+
>       postmaster@|222E|.cr.yp.to       (in smaller type)
>                  +----+
>
>    The second line won't distract the people in the intended audience who
>    recognize the contour-integral sign and have, say, Alt-S configured to
>    produce it.
>
>    End of problem. Notice that this doesn't require any extra DNS names.
>    The conversion of Shift-Ctrl-222E to \342\210\256 is isolated inside the
>    keyboard interface; other software doesn't have to worry about it.
>
>The ISO standard mentioned is ISO 14755. Notice that it works the same
>way for all text; it isn't something that has to be reinvented for
>domain names, mailbox names, etc.
>
>---D. J. Bernstein, Associate Professor, Department of Mathematics,
>Statistics, and Computer Science, University of Illinois at Chicago
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.483 / Virus Database: 279 - Release Date: 19/05/03