Dear colleagues, I mentioned that I would request some feedback about draft-liman-tld-names-00.txt from the idnabis WG participants. I got some remarks, off-list and not about the particular BiDi issue I was wondering about, from John Klensin. He told me he doesn't have time to engage here, but told me to feel free to pass along his comments. Any mistakes in the statement of his position are mine, and I apologise in advance if I don't get this right. Nevertheless, I think he has a point worth considering.
John's view is that the original "alphabetic restriction" in 1123 was indeed intended as a restriction, and that top-level labels were in fact intended only ever to be characters of the ASCII alphabet. He argues that it is a good idea to be as restrictive as possible in the top level, and that therefore it would be a wise idea to broaden the "alphabetic restriction" as little as possible. His suggestion is to re-iterate the alphabetic-only criterion, except to allow one extension to permit A-labels conforming to IDNA2008 (which work, note, is not yet complete). In addition, I think he believes that the document should also require that any U-label that is to correspond with an A-label that is added to the root zone must _also_ be alphabetic. The reasoning behind this is that the root zone occupies a very sensitive place in the tree, and therefore technical specifications around what is allowed in it should be very conservative. The above outline gives the minimum change to permit IDNs in the top level, without also leaving room for any other innovation in the labels allowed. It is worth noting that, since there are many commercial interests at stake here, one must suppose that anything that _might_ be possible in the root will be tried by someone. If that's right, then one can argue on prudential grounds that 1123 needs to be modified as little as possible to permit exactly the change we wish to enable, and no other. I will say that I am (personally, no hats) uneasy importing to the technical constraints on top level labels what seem to me to be policy considerations. Such policy considerations seem to me to be the sort of thing that ought to be handled in policy-making bodies set up for the purpose. At the same time, I accept the argument that there are strong technical reasons to minimize the changes to rules about the root zone, since we know there are many DNS-using systems in the world built around fragile readings of various RFCs. So I'm of two minds about the position I've laid out above. Best regards, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
