Dear colleagues, <background detail=long-winded>
In the IDNAbis working group, the current proposals alter the way IDN work. One important feature of this is a great deal more flexibility on what might be registered at any domain. Moreover, the current proposals allow for local mapping at the client side. Some of us are uncomfortable with this plan, but the reasoning behind it is to allow for flexibility in areas that have been controversial in the past (many of the controversies occur at layer 9), and to allow the new protocol not to break the existing "IDNA2003" behaviour. It is plain, however, that reasonable zone operators will have to implement several restrictions on what will be allowed to be registered. 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. (Otherwise, the risk is that different clients will map things differently and end up with results that are different in important respects, like resolving differently.) In what I am increasingly coming to think of as a moment of complete insanity, I proposed to come up with a mechanism by which clients could query the policies of a given registry (and remember "registry" doesn't always mean "TLD" or equivalent) to find out what the operator's policies are. That would allow the client to take meaningful advantage of the local-mapping capability. </background> To provide clients with a convenient way of learning about the policy statements, I think I'll need a facility that I can be fairly sure the client could use. One that has occurred to me is the S-NAPTR approach, as defined in RFC 3958. My model in that case is roughly that of IRIS. (A variant is the simpler SRV record, but the problem is the same.) 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. (There are obvious alternatives, of course, such as static lists compiled into clients, or a static site that is well-known where people can look up the policy.) If you have strong feelings about any of these approaches, and want to share them with me, I'd appreciate an email about it. Ideally off-list, I think, since I haven't actually put a real proposal together, so there are no real technical details to hash out. Best regards, and thanks for your indulgence, A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
