Re: [idn] proposed i18n naming rules

["Eric A. Hall" <ehall@ehsco.com>]

Mark.Andrews@isc.org wrote:

>         Shall I put it in ASCII terms.

Whatever works

>         Now lookup "foo.ExAmPlE.com" for both TXT and A records.

I assume you mean "using dig or some other application which doesn't have
a specific <protocol> usage for the entry it's requesting."

From <200111220358.fAM3wVo45784@drugs.dv.isc.org>:

> You can't have labels undergoing different transformations
> depending upon what is being looked up.

My argument at this point is that the transformations can/should occur
based on what is doing the lookup. I agree from your point above that this
isn't always viable either.

> The only thing that can change between a IHN and a IDN is
> that IDNs that are not IHNs should be rejected by the
> lookup tools.  Similarly the zone maintence tools should reject
> (by default) IDNs that are not IHNs when used in a context that
> requires a IHN.

It may be that the only way to completely and totally solve this problem
is to put case-neutral comparison back into the servers. Dan Oscarson has
been arguing for this and you may have made his case for him. This is
pretty complex due to several reasons but it may be the only way to
ultimately resolve this.

Another possibility is to fix the protocol usages like I've been arguing,
and do something with the generic tools such as dig. Note that the legacy
tools aren't affected because those tools don't have access to native IDNs
and case-neutral comparisons have to be performed for ASCII alpha in IDNs,
so a "fix" for those tools would only apply to the i18n compliant
versions. This could be something stupid (I beat you to it) like a "-ce"
switch for "case-exact" and downcase everything else.

As for rejecting entries in the zone, has this proven to work? Is there
sufficient experience with this to say with high certitude that RR
collisions are rare and avoidable? EG, nobody tries to add an A RR to an
existing TXT RR, so this would work? Also, has the userbase rebelled on
this feature to any great extent?

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