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

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 03 Apr 2002 18:37:28 -0600

[ietf removed from cc list]

Edmon Chung wrote:

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

There are multiple "clients" in the process. The application client
shouldn't have to mess with fallback unless there is a really good reason
for it (a cache being unable to convert an ACE-only DNSSEC answer being
one of them). In those cases, an EDNS RCODE is a workable way to tell the
application that the original query needs to be reissued in ACE form if it
wants an answer.

For other situations, such as circumnavigating old servers which only
support ACE-ified i18n domain names, letting a resolving/caching server do
the convolutions makes some sense, since those boxes can cache the
canonical UCS answer and referral data, which will help future queries.

I guess what I'm saying is that forcing the application client to pick up
resolver and caching duties doesn't make a lot of sense to me personally
since it will preclude the benefits of caching data.

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 4 Apr 2002 09:06:55 -0500

----- Original Message -----
> application that the original query needs to be reissued in ACE form if it

I meant the application client.  That is right.

> canonical UCS answer and referral data, which will help future queries.

However, there is advantage for not having the nameservers do any ACEing.
It should make the phasing out of ACE faster.

> since it will preclude the benefits of caching data.

But we are anticipating that this be a "transitional" phase only.
Eventually, IDN/EDNS will be common place.

Edmon

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 04 Apr 2002 09:45:46 -0600

> > support ACE-ified i18n domain names, letting a resolving/caching
> > server do the convolutions makes some sense, since those boxes can
> > cache the canonical UCS answer and referral data, which will help
> > future queries.
> 
> However, there is advantage for not having the nameservers do any
> ACEing. It should make the phasing out of ACE faster.

What is your reasoning for this?

Also, would you have the client perform all recovery operations, such as
retransmitting the original UTF-8 query once a problematic delegation
server had been gotten around? These will still result in caches being
updated but it will essentially result in each application implementing
its own full-service resolver.

> Eventually, IDN/EDNS will be common place.

I agree that the end-result will be an EDNS-majority, but I think it will
take so long that it is better designed as a coexistence than transition.
In the end, we want it to be transitional, but for the next 10+ years it
will be coexistence, IMO.

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 4 Apr 2002 12:03:52 -0500

----- Original Message -----
> its own full-service resolver.

The client app probably wont do any proactive recovery, but when the user
initiates another query, it would try th UTF8 again, and fallback only if
the request fails again.  In the meantime, the cache server will have ready
the ACE respond already.  The cache resolver still performs its usual job,
not the client app.  The client app is only responsible for the fallback
mechanism.

The reason really for this proposal is to make sure that DNSSEC works within
the architecture.  If the resolver does any conversion, DNSSEC would have to
be changed.  But if the client falls back, the origination of the request as
well as the authoritative response is not changed throughout the resolution
path.

Edmon

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 04 Apr 2002 11:29:41 -0600

Edmon Chung wrote:

> The client app probably wont do any proactive recovery, but when the
> user initiates another query, it would try th UTF8 again, and fallback
> only if the request fails again.  In the meantime, the cache server
> will have ready the ACE respond already.  The cache resolver still
> performs its usual job, not the client app.  The client app is only
> responsible for the fallback mechanism.

All of that is true for both models. The difference is that if the cache
handles the non-fatal cases, then the application doesn't have to deal
with minor burps, and instead only has to deal with fatal failures.

> The reason really for this proposal is to make sure that DNSSEC works
> within the architecture.  If the resolver does any conversion, DNSSEC
> would have to be changed. But if the client falls back, the origination
> of the request as well as the authoritative response is not changed
> throughout the resolution path.

This is also true for both models.