On Mon, Aug 25, 2008 at 04:24:08PM -0400, Andrew Sullivan <[EMAIL PROTECTED]> wrote a message of 61 lines which said:
> Moreover, it will aid interoperation and user experience if clients > can, in corner cases, learn what rules the server has in place so > that clients can perform mappings consistently. That's precisely a flaw of IDNAbis: it pushes (may be requires) client applications to get information about registry policies. (With registry != TLD.) Can you imagine what the DNS would look like if we had to look up AFNIC policy to make sense of foobar.gouv.fr? > I proposed to come up with a mechanism by which clients could query > the policies of a given registry Whatever the exact mechanism used (DNS + S-NAPTR, whois, HTTP, whatever), it will be brittle, it will require "due diligence" from registries (each time the policy is modified, do not forget to modify this file), it will raise issues of caching (and of availability if we do not use the DNS). These problems are quite similar to the various "suffix list" proposals. > One that has occurred to me is the S-NAPTR approach, as defined in > RFC 3958. I personnally do not have a problem with this technical choice. > I am aware that there are some who think non-delegation records in > zones at the top level at least are a really bad idea. I disagree with them. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
