Re: Just send UTF-8 with nameprep (was: RE: [idn] Reality Check)

[Keith Moore <moore@cs.utk.edu>]

> > It's painfully clear that we need an ACE format for IDNs to be used in
> > legacy appliactions, and that queries for ACE-encoded IDNs have to
> > work.
> 
> Yes.
> 
> > If people can make a good case that we also need to support queries
> > that use UTF-8 (or some other general purpose encoding of 10646),
> > more power to them.
> 
> Future applications will want to be totally internationalized from the
> ground up, without any legacy crap in the soup. 

No doubt about that at all.   I have some doubts about whether it will
really matter if they get it, but I don't doubt that people want it.

(I don't think it affects such applications in any significant way 
if they use ACE only under the hood in DNS queries. After all, the format 
of DNS names within queries is *already* very different than that used by 
applications, without the dots, with each label prefixed by a byte count,
with label compression, etc.  But very few apps need to care about this.)

> More to the point,
> however, it does not need to be "justified" if there is a sufficient
> amount of interest from knowledgable people, which there is.

Well, it still needs a cost-vs-benefit justification.  But perhaps those
knowledgable people can provide one.  

> And while it would be nice to have the just-send-UTF8 camp recognize the
> merits of ACE, it would also be nice to have the ACE-only camp recognize
> that many of their peers find some measurable amount of merit in UTF-8.

I doubt that anyone fails to see the merit in just-send-UTF-8 within 
applications, under some conditions.  It's the notion that it's always 
okay for applications to just-send-UTF-8 that seems to have little merit.

> > We can probably afford to have two ways of looking up IDNs.
> 
> There have been many proposals for a dual-mode approach, and this should
> illustrate that many folks recognize the merits of both camps already. And
> if it is done right, it doesn't suffer from compromise syndrome, since
> folks can deploy the one they wish without suffering any real penalties

That seems like a stretch.  But perhaps the proponents should go off and
work out the details for themselves.

I suggest some essential criteria for a dual-mode solution: 

- ACE lookups have to work from legacy apps for all ACE-encoded IDNs, 
  without additional support on the part of applications, hosts, caches, 
  resolvers, or servers.  

- Native lookups from IDN-aware apps have to work for all Native IDNs, 
  though it might be acceptable to impose some new requirements on 
  those applications, their hosts, caches, resolvers, etc.  

- ACE lookups and Native lookups have to produce results that are
  consistent with one another in both results and failure rates.

> If we can at least agree to work on a dual-mode approach -- even if we
> think the other half is nuts -- we will get the kinks worked out that much
> faster and to everyone's benefit.

Right.  But if we do this, working out the details of the native approach
should not hold back the ACE solution.

Keith

p.s. I still think the argument about what to send over the wire in DNS
is specious.  I get the strong impression that people who are arguing
in favor of using UTF-8 over the wire in DNS are really wanting to insist
that we use UTF-8 over the wire, immediately, in all applications - or
at least that this is the default behavior for all applications even if
a few applications make an exception to this rule.  I don't think this is
feasable, and even if it were, it's not within this WG's purview.

But if the proponents of UTF-8 over the wire in DNS can come up with a
sound proposal and make a good case for it, we ought to seriously consider
it.