Document: draft-klensin-idn-tld-04.txt Review: Joel M. Halpern Date: 9 februari 2005 National and Local Characters for DNS Top Level Domain (TLD) Names draft-klensin-idn-tld-04.txt This seems to be nearly ready for publication as an informational RFC. Some text ought to be added to address an item that is either confusion on my part or a problem that needs to be recognized. I have one concern with this. This would appear to encourage systems to use local representations of DNS TLDs. The specific representation appears to be defined by the particular product being used. If users exchange DNS references (URLs, email addresses) in this representation, things could easily fail. In fact, given that this is a user presentation issue, it would seem that I could even get into trouble copying a user visible email address from Netscape to Eudora. (It may be that this is already addressed by the existing IDNA approaches. But something needs to be said.) Some minor questions do occur to this naive reader. In section 1.3.2 there is a discussion of alias names and why they don't work. A reader not conversant with DNS might well wonder why simply causing .foo and .bar to have the same delegation information is not sufficient. (It took me a bit to remember that the full DNS path to an entry is stored in that entry, so this simply will not do the right thing.) A sentence or so would dispose of that broken idea. Section 3.4 refers to a country maintaining the representation tables. Given that users are using software products on locally administered machines, and that this proposal does not introduce any new protocol, I have trouble seeing how a "country" could maintain such tables. In fact, the software vendors would have to extend their localization support to include such tables for each region that they provide localization support for. While still non-trivial, this is a lot more effort than is described in the document.