[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] proposed i18n naming rules
>
> 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."
In your world only "example.com" would be delegated. Every one
that wanted to lookup foo.ExAmPlE.com TXT would have to *manually*
normalise ExAmPlE.com -> example.com, then lookup foo.example.com.
Either that or you have to delegate/DNAME ExAmPlE.com in addition
to delegating example.com.
> >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.
It's *never* viable.
> > 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/
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org