Subject: Re: [idn] WG last call summary

From: Keith Moore <[email-masked]>
Date: Mon, 18 Mar 2002 11:29:24 -0500

> In other words, the code re-write and upgrde is going to have to happen 
> sometime. 

right.  but it's not in our power to tell people when to do the rewrite
and upgrade.  and insisting that everyone upgrade all applications to
accept IDNs before anyone uses IDNs won't work.  there's too much demand
for IDNs right now, and people are already deploying it.  since we don't
have the luxury of upgrading everything first, we need a solution that
minimizes the harm when IDNs are used with legacy software.

Keith

---

From: Thor Harald Johansen <[email-masked]>
Date: Mon, 18 Mar 2002 18:38:57 -0800

> minimizes the harm when IDNs are used with legacy software.

This could be done by alternative means of accessing the sites the IDNs in
question are refering/pointing to. People who want IDNs also have the
responsibility of not forcing people to use these to access their servers.
IDNs in e-mails would pose no real problem, as anyone replying in a legacy
client to an account on an IDN adressed mail erver would see the
encapsulated encoding, and reply to the encoded address.

When he then upgrades his client, he would either change to typing the
addresses unencoded or just continue typing in the encoded IDNs (and the
new client would see this and refrain from doing any conversion).

The hypothetical Norwegian web page 'www.søråsen.no' could have an
alternate representation (a separate domain) of 'www.sorasen.no' or
'www.soeraasen.no' for people with old clients. The domain's owner could
also simply give the encoded address to the users of the site, and the new
clients would decode these. The user would then learn the easier way of
typing, or (if the IDN was in a non-latin alphabet and he would lack the
proper keyboard map to type it) just type in the encoded version.
-- 
Thor Harald Johansen
[email-masked]