Response to the call for public comments on the final report of the IDN implementation working team
Comments on the final report of the IDN Implementation Working Team Lyman Chapin Patrik Fältström John KlensinWe have reviewed the final report of the IDN-Implementation Working Team (http://www.icann.org/en/topics/new-gtlds/idn-implementation-working-team-report-final-03dec09-en.pdf ; hereafter "the Report"), and appreciate the opportunity to bring the following comments to the attention of the ICANN community. The Working Team considered both variant management and the three- character restriction in gTLDs; our comments are concerned only with the Report's conclusions and recommendations concerning variant management. 1. The Report begins with an assumption that we do not believe is well- founded: that we agree, as a community, on what "supporting variants in the root" means (or should mean). The Report's definition of "Variant Label" - "A Variant Label is resulting from the substitution of one or more characters in a Base IDN TLD Label with variant characters" - says nothing about the expected behavior of the DNS and other Internet systems when Variant Labels are encountered in domain names (either in isolation or embedded in URLs or other contexts). It appears to assume that the expected (desired) behavior is "the same thing happens regardless of which variant is used." Although this is a superficially appealing assumption, it is invalid. It is not clear that everyone agrees that "exactly the same" is the desired behavior for variants in the root. It is possible to imagine other behaviors that incorporate into the label some of the semantics of the thing labelled. For example, using the Traditional Chinese variant rather than the Simplified Chinese variant in a domain name might be interpreted by an application (e.g., a web browser) as a request that the content associated with the domain name be delivered in Traditional Chinese rather than Simplified Chinese. Overloading identifiers (labels) with content semantics is a well- known violation of basic system design principles. A familiar example is the use of a file name extension (e.g., ".txt") to "specify" the contents of the named file (e.g., "filethatmightcontainanything.txt"). In practical terms, continuing the Traditional Chinese and Simplified Chinese example, consider that although it may be "obvious" how to infer language and writing system from <http://simplified-chinese1.simplified-chinese2.simplified-chinese3 >, <http://traditional-chinese1.simplified-chinese2.simplified- chinese3> could be interpreted as a preference for Traditional Chinese (most specific label), but it could also indicate a preference for Simplified Chinese (two SC labels vs. one TC label), or it could actually *be* entirely SC because the characters in the label <traditional-chinese1> don't have Simplified Chinese equivalents. And of course <http://traditional-chinese1.traditional-chinese2.traditional-chinese3 > may not point to a Chinese site at all, but to a Korean or Japanese site. We recommend that ICANN explicitly declare that "supporting variants in the root" means finding a way to cause the DNS to interpret Variant Labels as having precisely the same semantics. 2. The report implies that it is technically possible to use existing DNS features to cause the DNS and other Internet systems to treat Variant Labels as if they were semantically identical "aliases." For example: "The team recommends that DNAME as a mechanism for variant delegation be systematically tested to formulate an appropriate solution for ensuring consistency when deploying variants in the DNS." This implication is dangerously misleading. It is not possible, without changing the design of the DNS and other Internet systems, to cause one label to behave as a perfect alias for another label (in the root or at any other level of the DNS). True alias behavior would require that the DNS (and other Internet systems) support multiple identifiers for the same node (as in the Multics file system, and some other hierarchical database and thesaurus systems). It does not. DNAME, for example, is a cross-tree pointer, not an alias. Even if the DNS were modified to support multiple labels for the same node, the HTTP/HTML URL-comparison rules would still specify that different URL strings are different, regardless of how their domain name components resolve in the DNS; and SMTP would still specify that if the domain names in two different address strings point to the same server, it's up to the server to determine whether they land on the same or different mailboxes. It is not technically possible to support Variant Labels as "aliases" without significant changes to the DNS and other Internet systems. Much of what has been written about "how to support variants" - including the Report - has overlooked this fact, so it is worth repeating: *It is not technically possible to support Variant Labels as "aliases" without significant changes to the DNS and other Internet systems.* 3. Although the DNS cannot support Variant Labels directly as aliases, we recognize that sufficiently rigorous alignment by registries and registrars of the subtrees beneath two separately delegated variant TLD labels could in principle produce the same behavior with respect to domain name resolution (although not, as we note in (2) above, in other Internet systems that use domain names). Second-level variants, for example, are already working well as separately-delegated labels in China and Taiwan. However, "rigorous alignment" requires absolute administrative control over every step in the domain name registration process. The Report suggests that this could be achieved through contracts or other agreements between ICANN and TLD registries: "The team concluded that if desired variants are to be delegated, certain conditions must be fulfilled (as detailed in the proposal below). These conditions would be included in an arrangement between ICANN and the TLD registry (i.e., gTLD contract, IDN ccTLD agreement, exchange of letters, application form terms and conditions)." The "proposal below" establishes the following conditions:"5. Desired Variant Labels may be delegated to the (same) applicant provided the following conditions are met: A. The applicant requests the Variant Label.B. The domains directly below the variant TLD are to be mapped exactly to the corresponding domains under the Base TLD. C. The applicant must demonstrate how this mapping is to be achieved, preferably by presenting earlier work on a testbed. D. The applicant must provide information on how it intends to inform its registrars/resellers/registrants about the correct set-up of name servers, and all other application servers that process domain names directly, so that end-user confusion can ideally be prevented, and at least held to an acceptable minimum. (This is discussed in further detail in Annex 3.) E. ICANN shall conduct periodic checks to ensure that the said mapping is in place. F. The delegation document for the Base IDN TLD Label (whatever form it takes: contract, MoU, accountability framework, ...) will commit the registry to the points above." It is extremely naive to imagine that ICANN will be able to monitor and enforce these conditions - which are, in any case, not stringent enough to ensure the alignment of delegated-variant subtrees. We therefore recommend that however ICANN decides to "reserve" variant forms of a base TLD label, they do not actually delegate (or commit to delegating) any variant label in the root until the consequences of doing so are well understood and clearly communicated to all parties. Attachment:
smime.p7s |