Re: [idn] Re: 7 bits forever!

(trimming main IETF list off the cc:)

On Tue, 02 Apr 2002 10:29:00 EST, Edmon Chung said:
> 1. IDNA clients
>     - the client does ACE and display it properly for the user
>     - servers (including DNS and mail and http, etc.) does NOT upgrade for
> ACE.  Even administration side is kept as is, allowing leakage
>     - IDNA clients MUST also be able to decode IDN(UTF8)/EDNS responses
This makes the rather rash assumption that the clients will be upgraded
to support a *future* feature.  You're also assuming that there will be
a way to test/debug IDN/EDNS responses when there are none actually being
seen "in the wild".

Re-work the model, assuming that (a) 50% of the people won't upgrade until
the new feature is *usable*, (b) 10% of the clients *wont* upgrade, and
(c) there will be at least 2 or 3 show-stopper bugs found in the EDNS
handling when it starts being widely used.

You'll never get widespread deployment of a feature that is both not usable
and untested (because there's no use of it).

> 2. IDN(UTF8)/EDNS DNS Server upgrade
>     - DNS servers will now accept both ACE (as usual) and IDN(UTF8)/EDNS
> requests
Are there any hidden gotchas here?  Are there any changes needed to BIND
to allow it to process a UTF8 zone file?  Are there any "bad news" characters
that might cause parsing problems?

Again - what happens if not everybody upgrades?

>     - ACE requests will yield Both an ACE response + an IDN(UTF8)/EDNS
> response
Here there be dragons.  Do a 'dig aol.com mx', and ask yourself what
happens to performance if that doesn't fit into one DNS packet anymore,
and as a result a resolver has to drop back to TCP (instead of one packet
each way, you're now up to a 3-packet handshake, the data, and the FIN
packets) - and note that the TTL on the AOL.COM SOA is 3600....

What happens to an ACE-based client that receives an EDNS response that it's
not able to parse?

>     - IDNA clients continue to send in ACE but will start to see UDNA
> responses
This is a can of worms - how does the server know for sure that the client
is upgraded and is able to parse a UDNA response?  Remember - the client
is probably *NOT* asking directly.  If I've upgraded example.com's DNS
to be UDNA ready, how do I know it's safe to send a UDNA response to a query
from foo-bar.com (since it's quite possible that the *USER* has upgraded,
but the sysadmins have NOT upgraded the DNS that's recursing the query for
the user....

> 3. IDN(UTF8)/EDNS for clients & everywhere
>     - IDNA clients begin to obsolete, new versions of application software
> comes with IDN(UTF8)/EDNS built in.
Which will be slower than you might think..

>     - In case DNS servers are not upgraded yet, clients will continue to use
> the IDNA client, thereby also creating an incentive for server side to
> upgrade
OK.. How does my client tell that a DNS server in Zimbabwe is or is not
upgraded?  Remember - DNS is *distributed*, and just because YOUR DNS
server is upgraded doesn't mean that the one actually providing an
authoritative answer has been upgraded...

>     - Other applications/servers upgrade to IDN(UTF8)/EDNS to accept UTF8
> domains, administrators might continue to see ACE leakage if the client
> still uses IDNA to send requests, but UDNA requests will be managed in UTF8
It's this "might continue to see ACE leakage" that's a major problem...

> 4. IDN(UTF8)/EDNS
>     - Slowly but certainly, we will move towards full UTF8 because
> administrators will likely want to deal with UTF8 than ACE, especially for
> say those admins in China who are dealing with IDNs frequently.  Added to
> the urge from the user community to upgrade the server as they upgrade their
> clients to IDN(UTF8)/EDNS.
Just remember the pain felt by *both* 50%s when 50% of the users had
MIME-aware MUAs, and 50% didnt....

-- 
                                Valdis Kletnieks
                                Computer Systems Senior Engineer
                                Virginia Tech

pgpq6VLuRln3n.pgp
Description: PGP signature