[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: > 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/
