Subject: Re: [idn] Re: 7 bits forever!

From: "John Stracke" <[email-masked]>
Date: Tue, 2 Apr 2002 16:27:19 -0500

>Again you have fallen into the common underestimation of the upgrade work
>required for ACE to work perfectly (including display).  What I see is 
that
>applications are already having some trouble going from ASCII and local
>encoding to UTF.  ACE in essence requires the conversion from local 
encoding
>toUTF first and then toACE.  I see trouble here...

Yeah, but I suspect it's smaller than you think; once you've got UTF-8 in 
place, adding the UTF-8/ACE conversion would be a lot simpler.  In any 
case, I don't think we can do without ACE, at least as a transition, which 
means that a later transition from ACE to UTF-8 wouldn't reduce the 
complexity much (you'd still need to talk to ACE-based servers).

/===============================================================\
|John Stracke                    |Principal Engineer            |
[email-masked]   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|If you're going to walk on thin ice, you might as well *dance*!|
\===============================================================/

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 2 Apr 2002 16:27:10 -0500

----- Original Message -----
From: "John Stracke" <[email-masked]>
> complexity much (you'd still need to talk to ACE-based servers).
There are no ACE-based servers.  the current servers can already handle ACE!
that is the good thing about ACE!  I believe it makes sense to go with ACE
as a transition, but I dont think there needs to be an ACE server.  Servers
should be upgraded to UTF8 directly.  They will continue to accept ACE even
without requiring to do anything special because ACE is simply an English
domain name.
Edmon

---

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Tue, 2 Apr 2002 17:39:45 -0500

> complexity much (you'd still need to talk to ACE-based servers).

That's all the points there, once we've got UTF8 in place, so if we have
UTF8 in place then we only need the ACE as a transition, then we can slowly
phase out ACE later, and be able to use UTF8.

That's what me and Edmon has been talking about all the time, we need ACE as
transition and move to UTF8 as smooth as we can. So an internet draft for
this transition is needed, we will be posting a draft about this soon.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 3 Apr 2002 12:36:26 +0200 (CEST)

> this transition is needed, we will be posting a draft about this soon.

Instead of a brand new proposal I'd be more interested in finding out
how you can address the DNSSEC issues I pointed out in
draft-hall-dm-idns-00.txt and how you would be different than the techniques
in that draft.

   Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 03 Apr 2002 12:25:32 -0600

Erik Nordmark wrote:

> draft-hall-dm-idns-00.txt

The DNSSEC problem is hard, for multiple reasons. Some zones can sign
dynamically, some can't. The state of the delegation parent also affects
the negotiation. The solution to this problem will be multi-faceted. The
OPT-IN work can probably help solve part of it. Small changes to DNSSEC
may be required to solve other parts of it. One of the changes I am
planning to make (and would encourage substitutes to use) is EDNS RCODE
responses in OPT RRs, such that each transaction in the query operation
has a distinct code for fallback purposes, and this will help with part of
the problem too.

Essentially, one RCODE value could be used whenever fallback processing
has occurred (the cache/server/whoever tells the client: "I am falling
back to legacy mode"), and this will reset the query timer on the client.
This means that queries can fallback as neeeded multiple times, without
triggering the client's query timer. This would also mean that DNSSEC can
be preserved if the final data has been signed in UTF-8 form, even if the
immediate parent is only ACE.

Another RCODE value could be used for "cannot fallback" and couldd occur
for any (valid) reason. Implementations would have to be prohibited from
refusing to fallback because ~"I don't want to", but they could refuse to
do it if they are under heavy load, if a configuration error prevents it,
or if DNSSEC prevents it, such as a delegation NS RR only being available
in ACE, and it is signed. In such an event, the resolver would report
"cannot fallback" and the original client would have to reissue the query
in ACE in order for the query to succeed.

Anyway, there are several angles to pursue here. I'm not really sure that
any of this can be done until DNSSEC stabilizes some. Frankly, I'd rather
somebody else try to solve this problem.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Edmon Chung" <[email-masked]>
Date: Wed, 3 Apr 2002 18:22:11 -0500

----- Original Message -----
From: "Eric A. Hall" <[email-masked]>
> in ACE in order for the query to succeed.

These are good ideas and should work well. But for a quicker and dirtier
way, we could simply continue to let the client do all the heavy lifting, as
is mandated by IDNA anyway, by failing the request anytime it hits a node
that does not support UTF8 form and force the client to fallback to ACE
resolution.  This way, the servers dont even need to know how to do ACE
conversions at all!

Edmon