Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())

[Nicolas Williams]

On Wed, Jun 16, 2010 at 09:28:34PM -0400, John C Klensin wrote:
> --On Wednesday, June 16, 2010 16:54 -0500 Nicolas Williams
> <Nicolas.Williams at oracle.com> wrote:
> > Makes you think that private DNS clouds with IDN rules other
> > than IETF Standards-Track IDNA rules are not desirable.  And
> > I'd agree.
> > 
> > What's the point of this post?  First: to note that private
> > DNS clouds with non-standard IDN rules are a big PITA since
> > right now they can only be supported by nodes that either
> > happen to implement those rules (and not IDNA) or which have
> > local configuration partitioning the DNS namespace by IDN
> > rulesets, and distributed configuration, though it could be
> > possible, would also be a PITA since stub resolvers would have
> > to get pretty smart.  Second: to outline a meta-IDN system
> > that could work if IDNA2008 should founder (but let's hope
> > not).  Third: I had to write this down :)
> 
> I think there may be a fundamental misunderstanding here.  If
> your point is that we have a mess on our hands, we already know
> that... and that is starting point for this document.

See "First: to note that...".  That is: I don't think DNS, much less
_application_ implementors can be expected to support private DNS clouds
with non-standard IDN rules.  It's just too big a PITA.

My point was definitely not that we have a mess on our hands, UNLESS we
want implementors to support private DNS clouds with non-standard IDN
rules.  But how can we?  If such rules are non-standard...

The only obvious non-standard rule that could "trivially" be supported
is "raw IDNs without regard to codeset; every node must run in the same
locale".  And even then, how would an implementation know when to apply
that rule versus IDNA?

> Could the mess have been avoided if the implications of the
> native UTF-8 (and other native encodings, such as direct use of
> 8859-1) had been known and analyzed when the IDNA work was being
> done?  Well, perhaps, but actually I have serious doubts.  The
> ...

That was not my point.  It's possible that my little straw man
multi-IDNA proposal could have been useful a decade ago.  Right now it's
just a device for reasoning around the exhortation I received earlier to
consider private cloud DNS with non-standard IDN rules.

> I suggest that, ultimately, the main purpose of the encoding
> document is to identify the problem(s), warn people to exercise
> caution, and to make a few suggestions that may help a bit.

Yes, and it's done that job.  I think it's time to standardize
getaddrinfo()/getnameinfo() behavior.

Nico
--