[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