(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
msg03852/pgp00000.pgp
Description: PGP signature
