Whoa. I am unaware that because any of us as councilors raise questions, and ask for information, that means no testbeds. However, there may be political issues, Cary, even if some wish otherwise. Just spent three days at ITU. :-) Back to the point, it is good that we are asking questions and discussing these issues. Can we maintain a. Welcolming attitude so even I get brave enough to post my questions. :-) Marilyn -----Original Message----- From: Cary Karp <ck@nic.museum> Date: Sat, 04 Feb 2006 18:26:05 To:GNSO Council <council@gnso.icann.org> Cc:John Klensin <klensin@jck.com>, Patrik Fältstrom<paf@cisco.com>, Tina Dam <dam@icann.org> Subject: [council] Re: Regarding issues report on IDNs
The DNAME may be ok solution from a technical point of view, as each current TLD can have equivalent TLD domain names in ALL languages, IDNs in ALL languages pointing to English domain names, but would present a greater issue from a the perspective of policy, politics, control, competition etc.
Nobody has suggested that all TLD labels should/will/can be entered into the root in every language that appears elsewhere in the namespace. Nor is English the default language of the root. There is apparently also still a great deal of confusion about the distinctions between script and language, and between names and identifiers. Although it is certainly worth Council's time to delve adequately into such matters, the short path out of the present quandary is by noting that the potential number of non-ASCII labels that are likely to be suggested for inclusion in the root zone is utterly independent of the way in which those labels might ultimately be registered. As has already been pointed out in the present sequence of exchanges, an IDN TLD can be established either with conventional delegation records or with DNAME records. We can postulate the unsuitability of DNAME for that purpose (for which it was not initially intended), or we can postulate the opposite (if we feel like being reckless), or we can test them in the new context before proceeding any further in the discussion of their being an alternative to the current way of expanding the root (which might be reckless, anyway, but is an absolute necessity given the threat that our failure to do so represents to the single global namespace). The outcome of such a test will neither brake nor further the demand for including new scripts in the TLD repertoire. There will be situations where two TLD labels in different scripts are deliberately intended to be semantically equivalent (in two or more languages using those scripts), but are to be associated with separate name trees. There are also situations where the intention will be to attach the same name tree to different representations of the TLD ID. Both cases are fraught with political and IPR concerns, and both will be encountered in the gTLD and ccTLD spaces. The thing that DNAME brings to this -- the only thing -- is the possibility that it provides for injecting a weak modicum of referential integrity into a database environment that lacks any such native mechanism.
Does a DNAMES approach advance an extension of present Latin character gTLDs into non Latin character, but do not expand the underlying infrastructure competition. Or do more?
If the only means that were permitted for the registration of an IDN TLD were the assignment of a CNAME record to a pre-existing name tree, the effect on competition might be arguably different than would be the case if both forms of IDN TLD delegation were implemented. It would exclude transliterated and translated versions of pre-existing TLDs from delegation to separate operators, and there would be disputes about what might constitute adequate semantic differentiation for a new TLD label. If the only mechanism that were permitted for the registration of an IDN TLD were the conventional delegation of authority for a separate name tree, the potential for dispute would be significantly greater (to say nothing of the encumbrance to prospective name holders). This is not, I would have thought, something that the GNSO Council would wish to precipitate if there were any way to avoid it.
This creates BIG problems, a political one I must say, as for eg. US would have an equivalent in Chinese, Arabic, and others managed by Neustar. I am not sure if the Chinese or Arabs will like that. On the other hand - Iran and Syria will have a Hebrew TLD - I am note sure the Israelis would like that.
As long as we are immersing ourselves in policy details of the internationalization of the domain namespace, we would be well advised to think more than twice before making any statements that assume the legitimacy of the notion of language ownership. Which national government owns the English language? Which owns the Latin alphabet? Which owns Cyrillic? Are the Chinese language and script any easier? Arabic?
But, these are some of the problems I believe made DNAME unpopular, even if it is OK technically. As you have already said John, - all technologies have pros and cons (and we know them already...)
Finally, should NOT the above be one of the main reasons as to why the testbeds should be considered to be open for eveyone, as oppose to only existing TDLs? or even a consideration for entirely dropping it and go for policy making?
Made DNAME unpopular? For whom? In what context? We are talking about testing a new application. One informed expectation of its outcome is as good as another. I am amazed that Council seems to believe that its interests might be better served by that test not being made at all, as though it were an unnecessary impediment to the serious work of policy making. (But, of course, that's just my opinion. :-) ) /Cary Regards, Marilyn Cade