Re: [gnso-idn-wg] Issues list item
Dear Avri Doria and others, 2007/1/31, Avri Doria <avri@xxxxxxx>:
I think the issue of "confusingly similar" test could be regarded as one of these attempts because it seems to be an effort of the existing gTLD registries to extend its "rights" scope even into non-ascii name space by exploiting the notion of "confusingly similar" Obviously, this issue shed some lights on important aspects of IDN particularly when homographics problem is to be taken into account. However, the problem of homographics has already been well known even in its earlier date when punycode scheme had been adopted as IDN standard. And what we learn from homographics case is just warning to typographical similarity in IDN labels. To avoid typographical similarity is not the same as ensuring any rights of the existing gTLD labels. - that governments should not be in the position of deciding on the appropriateness of an application for IDN TLD or SLD This is very good point. And basically I agree to that. But I should say that specific IDN TLDs should serve the specific language script sharing community and therefore, those IDN TLDs should get some support from the script community. As you know, in its origin, IDN has been developed from the demand of language script community. While gTLDs have a community of interest depending on its TLD string related concerns, IDN TLD should primarilty respond to the language script community's need. Accordingly, to answer to the question what label strings should be selected or who should operate its registry, we should primarily take into accout the script community's concerns. Probably, governments as one part of the language community could have some role in this process. But I think each government's role could be different depending on each country's linguistic environment or specific language's geographical pervasiveness. That leaves the idea of the language community having some say. but the notion of language commnuinty is still somewhat unclear to me if we remove all notions of sovereignty. Not only does ICANN not have a construct, similar perhaps to constituencies, to cover language communities, but I know of no way of defining membership in a community (e.g. questions such as: is speaking enough, or reading, or writing? does someone need to be a native speaker/reader/writer? does the inability to read preclude membership? if one emigrates from the predominant land of the language do they lose their membership in the community? does learning a language bring one into the linguistic community? if so how much does one need to learn to gain entry into the language community? if a company hires someone who is a meber of the linguistic community do they gain 'rights' within that linguistic community?). I wonder if the term of sovereignty is appropriate here. Rather, as Mawaki Chango described, the notion of cultural identity seems to be more relevant. You know, IDN started from this cultural identity concerns. And naturally cultural identity has some relations with specific community - here it is the language script community. One of flaws of the notion - language community is that it seems to be too abstract as you appropriately pointed out. However, if LIC(local internet community) in ccTLDs as refered to as such in RFC1591 is also very abstract notion, but it is useful and practical. We frequently say that internet has overthrown national borders. But even in internet date, language barrier (or border if we can use the term) obviously exists. Therefore, language community is one important element in internet sphere. I think it may be valuable to think over how we can make some linkage of IDN TLD with language script community. It could be tough job, but Unicode repertoire has also been developed by those language community's positive participation. The quandary I find myself stuck in is finding a balance that protects the potential (developing nation) registrant from exploitation, without developing/supporting notions of linguistic sovereignty or investing new levels of authority on ICANN processes.
|