Re: [idn] Re: 7 bits forever!

["Edmon Chung" <edmon@neteka.com>]

Its so great to at least have some response.  ;-)
I have said that there will be holes in my initial proposal, but this is a
good start.  Lets work on ironing out the pathway.

> 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".

The assumption is no different than assuming clients will upgrade to ACE.
If we can assume that clients will be willing to upgrade to IDN then, there
is no reason to think that implementations would not include both ACE and
IDN(UTF8)/EDNS if IDN so specifies.

> > 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?

This is an application implementation issue, NOT a protocol issue.  If BIND
doesnt implement it well, there will be other software vendors that will
make it work as "specified".

> >     - 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....

I dont understand.  If you do a dig with any non-upgraded clients, then you
will be only digging for English domains.  If you are using an upgraded
client then you will be able to parse the packet.  Also, for most cases I
would imagine it will still fit in one packet.

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

That, as specified in 1. is not possible.  ALL ACE implementations MUST also
implement IDN/EDNS.  That is why the discussion should start NOW! Finally
someone realizes my point on why we need to discuss this now and not after
we have done the ACE part :-)

> >     - 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....

I see your point.  What if ACE requests will receive only ACE results, while
UDNA requests will get both the ACE and the UTF result.  This way, we know
for sure that the inquirer knows UDNA if they initiated it first.

> > 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..
>

Not much slower than what you should expect if you go for "ACE everywhere"

> >     - 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...

First of all, the EDNS migration path will be expected.  Then, if the
Zimbabwe DNS operator wishes to offer IDNs, they would upgrade to IDN/EDNS.
If they do not provide IDN resolution service, then IDNs wont work anyway.

> >     - 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...

Clients that do not upgrade will eventually be obsoleted.  At least we know
that.  Also, if the admin is so desparate to know what the ACE is, s/he
could always use other conversion tools to view it.  But as the core app,
ACE need not be done.  That's the beauty of ACE, isnt it?

> > 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....

Precisely why we should plan ahead better this time.


Edmon