Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())
Nicolas.Williams at oracle.com
Thu Jun 17 18:11:55 CEST 2010
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
More information about the Idna-update