> 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. 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 thorhj@yahoo.com