[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>> 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).
That's the point convincing all users to use a client is not easy to deploy,
so why IDNA with ACE??
>> - ACE requests will yield Both an ACE response + an IDN(UTF8)/EDNS
>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....
Hmm... talking about DNS packet that wont fit... so how about DNSSEC, their
packets are large as well...
>> - IDNA clients continue to send in ACE but will start to see UDNA
>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
>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
If any *entity* along the path that is not capable, I think the last current
capable *entity* will down version the protocol and not sending the new
>> 3. IDN(UTF8)/EDNS for clients & everywhere
>> - IDNA clients begin to obsolete, new versions of application
>> comes with IDN(UTF8)/EDNS built in.
>Which will be slower than you might think..
Is there any indication above to state how fast we think this maybe?! I
guess you must be good in mind reading in order to see that we are thinking
this deployment is fast!!
>> - 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
>It's this "might continue to see ACE leakage" that's a major problem...
bq--RACE.com is a IDN is not a problem... it is just some sort of alternate
representation of characters on the UI... I can now read bq--3cmzs3rp.com as
"hongkong".com : )
>> 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
>> 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
>> 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....
So that's why servers need to be upgraded to be capable to handle the new
protocol first before the users need to know, or else the pain will come out
when they realized that IDN is not the real IDN and is just buying another
ASCII names, so what not have a system that just maps IDN to existing
domains just like internet keywords?