Benchmarks for drafting the Status Report regarding CCNSO ISSUES PAPER Selection of IDN ccTLDs associated with the ISO 3166-1 two letter codes.
I. Drafting the answers by ALAC Liaison and Members (Siavash, Hong, Veronica, Mohammed) by July 22Four of us are going to answer these questions and present the reasons. I suggest we divide the work as follows:
______________________
Siavash: Question 1-3
Q.1: Which ‘territories’ are eligible for an IDN ccTLD?
Despite its problems, the ISO-3166 two-letter code list is the least controversial definition of cc available. So we believe that this list should serve for the moment until consensus on another definition is reached. This does not mean that ALL those listed need to implement IDNs.
Q.2: Should an IDN ccTLD string be "meaningful"?
The word 'meaningful' should be interpreted to mean describing the territory, economy or country specified by the two-letter code. In this narrow sense the answer should be yes. We are not referring to acquired secondary, often commercial, meanings attached to certain ccTLDs not describing the intended territory.
Q.3: How many IDN ccTLDs per script per territory?
One should aim for just one IDN string per per script per territory at the first stage in order to get the project moving. There may be cases where different languages within a given territory use the same script and have different representations for the territory name in that script. In such cases, if there is demonstrated demand for more than one IDN, one possibility is to 'bundle' the various representations as one IDN ccTLD. This would involve having more than one representation in the root but should solve the local problem.
______________________________
Hong Question: 4-6
Q.4: How many scripts per territory?
The number should eventually be decided by the local Internet Community through sufficient, transparent and multi-stakeholder consultation mechanism. IDNs are designed to serve the people who use the specific scripts other than ASCII. Without prejudice to the ICANN IDN Guidelines on technical constraint, non-ASCII script users should have the freedom to decide whether to reflect thier native scripts in the DNS. However, realization of this final and idealistic solution will be a long process involving complicated technology and policy development. Given that non-ASCII users have been waiting too long for IDN deployment, it is suggested to adopt a fast-track experimental solution in the short term. Under this short-term solution, the Internet community in each ccTLD territory may choose only one IDN script for deployment. The one script chosen should be out of genuine consensus of the local community, carefully defined in terms of variants or homographs.
Q.5: Number of characters in the string?
This question is correlated to Q.2. Although ccTLDs in ASCII are expressed in two-letter codes listed in ISO 3166, the number of charaters in IDN ccTLDs cannot and should not be pre-defined. A ccTLD will be meaningless if it cannot reflect the link with a certain territory. However, many ccTLDs, once expressed in the non-script scripts, cannot reflect the territory links in two-letter format. Forced abbreviations could cause confusion or even distortion. Therefore, the number of characters in the IDN string should be decided by the local Internet community and technically subject to the IDN guidelines.
Q.6: Are there any ‘rights’ attached to a given script?
New Answer:
IDNs are not only online identifiers but non-English speaking people's culture expression on the Internet. In IDN implementation, social responsibility should outweigh commercial interests. In the long run, any selection of IDN scripts or operation should be subject to the language community's self-determination. Some language community has already been well-organized, which defeats the suspicion that local community cannot be defined. However, for the purpose of the fast-track experimental deployment, some fast-track consultation mechanism may need to be created, such as object or appeal system.
If the question means whether any priority right should be given any language group where the script set is shared by several languages, no rights or priorities should be given to any one language group using the script. Where possible, variants of a script should be treated as separate scripts to avoid this problem, but then IDN implementation would require measures to combat homographs and phishing.
CCTLDs-even IDN ccTLDs-should maintain the linkage with specific territories and may well restrict registrations outside the territories. Thus, it should be the language community within the territory of a ccTLD that are consulted for the IDN ccTLD matching to that ccTLD. Given the unique territorial nature of CCTLDs, even in share-script circumstance, IDNs for ccTLDs should not be a big problem among the language communities that share some scripts in different ccTLD territories because their IDN ccTLDs must be in different stings anyway. What's important that one ccTLD should not be entitled to interfere the selection of IDN ccTLD in another territory that use the same scripts or share some scripts
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
References:
This is not a real question. What should be asked is whether an IDN deployment has the responsibility to the internet community that use the script. The answer is yes. IDNs are not only online identifiers but non-English speaking people's culture expression on the Internet. In IDN implementation, social responsibility should outweigh commercial interests. In the long run, any selection of IDN scripts or operation should be subject to the language community's self-determination. Some language community has already been well-organized, which defeats the suspicion that local community cannot be defined. However, for the purpose of the fast-track experimental deployment, some fast-track consultation mechanism may need to be created, such as object or appeal system.
****Comment by Siavash: I'm a little confused by the answer above. First of all I think the original question is a meaningful question. The same script may be used by several languages, so a question may be whether one language group can claim 'rights' or 'priorities' to that script? This can become a very sensitive question because the same representation can mean different things in different languages. My answer would be that a priori no rights or priorities should be given to any one language group using the script. Where possible, variants of a script should be treated as separate scripts to avoid this problem, but then IDN implementation would require measures to combat homographs and phishing.*
**Comment by Hong: I assume either the expression of the question is not clear or I misunderstood it. If the question has the perception that IDN ccTLD implementation may be severed from a given language community, then the answer is no. If the question means, as you paraphrased, whether any priority right should be given any language group where the script set is shared by several languages, then I agree with your judgement.
**********Comment by Siavash: Just to clarify for myself, it seems to me that there are two ways the question may be interpreted, and I'll try to proceed by examples:
Version 1. There may exist a large Japanese community somewhere outside Japan who use Japanese script in their written communication. Should the Japanese community within Japan have prior rights to Japanese script because they are in Japan? As long as we're dealing with one ccTLD string, this problem is moot, but when it comes to gTLDs this may be a more difficult problem.
Version 2. There is a script called Arabic that is used not only by Arabic language, but by a number of other languages distinct from Arabic. Should Arabic language community have prior rights to this script just because the language and the script have the same name? This can be a difficult problem even if one string per ccTLD is considered. The existence of variants of this script with different unicodes enables one to differentiate between the strings and call them by different names, but the problem of homographs persists and here's where technical measures(such as bundling) need be implemented.
******Comment by Hong: As for Version 1, I assume the question is much more relevant to gTLDs than to ccTLDs. CCTLDs-even IDN ccTLDs-maintain the linkage with specific territories and may well restrict registrations outside the territories. Thus, it should be the language community within the territory of a ccTLD that are consulted for the IDN ccTLD matching to that ccTLD.<BR>As for Version 2, there shouldn't be any priority right to choose IDN strings, whatsoever, between ccTLD territories. Even in share-script circumstance, IDNs for ccTLDs should not be a big problem among the language communities that share some scripts in different ccTLD territories because their IDN ccTLDs must be in different stings though in same or similar scripts. What's important that one ccTLD should not be entitled to interfere the selection of IDN ccTLD in another territory that use the same scripts or share some scripts.
__________________________________
Veronica: Question 7-9
Q.7: Should a list of IDN ccTLD strings be mandated?
Reviewed Answer on Q7:Should a list of IDN ccTLD strings be mandated? - based on the comments from Siavash and Hong:
A universal mandating should not be implemented at the initial stage. Users have the right to use IDNs rather than a duty to do so. Neither the automatically converting ISO 3166 into an IDN list solution is far from being realistic: this would impose some ccTLDs that have no demand for IDN use to implement them, which is obviously contradictory to the purpose of IDNs. Also, compiling a mandatory list would slow down the IDN development process. The crucial question at this stage is how the local community consensus can be reached in case IDN implementation is necessary.
One solution to that is the proposal by APTLD, which states that it is important to allow each interested existing ccTLD to propose ONE string and provide six months for Internet community at Large including the ‘affected’ Communities and Governments to voice possible objections and/or comments. If no serious reservations are aired then the string may go into the root. However, even though a list of IDN ccTLD can be complied through the one-string-one-ccTLD approach it cannot be a final solution, and if made mandatory, it will cause serious rivalry between different script users in one ccTLD territory. Issues related to that include: What makes one script may be chosen over others in a multiple-script ccTLD territory? Is this reflected in the local cultural or social policy/strategy? How those minority script users can protest against this and will they protest?
>>>>>>>>
>>>>>>>>
^^^^ Orignal Answers and Comments
At the initial stage of this project, it is important to have the list of IDN ccTLD strings mandated. Not having a mandated list can lead to important process/concept related problems/issues. One way to do it is to apply the same methodology applied for the ASCII case, in which the ccTLDs are mandated based on the ISO 3166 list, but as ISO has declined such role, the list of IDN ccTLD strings can be mandated by another body, which would mandate ccTLD string in the certain characters to represent each territory.
On the other hand, the simplest way not the easiest though, is to have ccTLDs/ISO 3166 list automatically become the mandated list of IDN ccTLD – under the clear monitorisation of an authoritative body. If this new project requires to be implemented under a certain policy, then it is mandatory that ccTLD community is consulted for this purpose. The input of the ccTLD community should be based on the inputs of the users of those communities and a Needs Assessment should be carried at the community/country level prior to that. The Needs Assessment should reflect the readiness of the community to implement IDN ccTLD in the first place, as well as the Needs Assessment report should provide clear recommendations vis-a-vis the ways of implementation, etc.
*****Comment by Hong: People have the right rather than the duty to use IDNs. This is also true to IDN implementation. Automatically converting ISO 3166 into an IDN list would force some ccTLDs that have no demand for IDN use to implement them, which is obviously contradictory to the purpose of IDNs. On the other hand, compiling such a list-let alone making it mandatory-would not only slow down the IDN development by driving it into a who-and-how-to-do maze but also need the "God feeling" to anticipate all the possible demand for IDN scripts in all the ccTLD territories as well as all the possible IDN strings used in these territories. It seems this is totally a task impossible.
******Comment by Siavash:Of course not all ISO-3166 cc's require IDNs, so a question of universal mandating need not be addressed at least at this time. But where IDN implementation is necessary or desirable, the question remains how the local community consensus should be obtained or identified. A proposal by APTLD is to allow each interested existing ccTLD to propose ONE string and provide six months for Internet community at large including the affected communities and governments to voice possible objections and/or comments. If no serious reservations are aired then the string may go into the root.<br> *******Comment by Veronica:* I agree with your comments. And I am aware of the consequences of having the ISO 3166 convert into a IDN list. This was something that seemed after me, to be the quickest way to have the list of IDN ccTLD strings be mandated. In other case, the process will just simply last for years .... To Siavash's comment on "A proposal by APTLD is to allow each interested existing ccTLD to propose ONE string and provide six months for Internet community at large including the affected communities and governments to voice possible objections and/or comments" - what happens if the deadline is not met my hte Internet Community? How can the process be run efficiently? How do you think this can be achieved?
Also, "the affected communities" _ Siavash, please, kindly provide some details on this definition/term. Thanks!
***********Comment by Siavash: It is not really possible to come up with a pre-defined notion of 'Affected communities or people'. The idea is to allow comments by anyone concerned and let some kind of consensus emerge within six months. 'Six months' was seen as a practical length of time, not too short to be missed and not so long to be forgotten. After six months, some body like ccNSO working group or IDNs or a joint ccnso-gnso-iana-... body should be able to rule on the result of the comment period in each case.
**************Comment by Hong: As early as 2001, CNNIC made a comprehensive policy proposal for IDN implementation to the first ICANN IDN WG chaired by Mr. M. Katoh. Its IDN ccTLDs part is very similar to the present APTLD proposal but more detailed. As the primary drafter of CNNIC proposal, I can surely see the merit and advantage of APTLD proposal. However, even though a list of IDN ccTLD can be complied through the one-sting-one-ccTLD approach (I originally proposed for that as well), it cannot be a final solution, and if made mandatory, it will cause serious rivalry between different script users in one ccTLD territory. We've already heard the question from CCNSO WS: why one script may be chosen over others in a multiple-script ccTLD territory? Is this consistent with the cultural or social policy? Will those minority script users strongly protest against this?
******************Comment by Siavash: I understand this concern. That's why in my answer to Q.3 I tried to provide room for exceptions.
**Q.8: Who picks a string for a territory in the absence of a mandated list?
Reviewed Answer on Q 8: Who picks a string for a territory in the absence of a mandated list? - based on the comments of Siavash and Hong
As stated in the Q7, each existing ccTLD should be allowed to propose one string and to provide six months for the Internet Community at Large to express their views/concerns/comments. It is mandatory to include the local community in the consultation process in deciding the string. Public review/objections regarding the proposed ccTLDs strings should be opened and transparent.
>>>>>>>>>>
>>>>>>>>>>
^^^^ Original Answers and Comments
The previous answer states that the IDN ccTLD strings should be mandated. In case this approach is not implemented, the selection, validation and allocation of IDN ccTLD will be made on a proposal basis, submitted by the TLD community representative (e.g. current national registry operator) of the certain region, «territory». As stated in the answer above, a local Needs Assessment shall be carried out, and based on its results the proposal shall be elaborated. Ultimately, the proposal is submitted to the "body" in charge of IDN ccTLD strings and is reviewed by its commission according to its requirements.
Important notes:
1)There should be clear criteria and policies to determine who can submit a request for the designation of an IDN ccTLD – this will be done with the consultations of the TLD Community;
2)The criteria and policies should be clearly stipulate the competing requests and foresee solutions for situations in which 2 "territories" might be eligible for the same strings for IDN ccTLD.
************Comment by Hong:infra Q.7
*************Comment by Siavash:Please see my comment on.7
***************Comment by Hong:see above Q.7
Q.9: What coordination should exist between the different actors?
There is no doubt that coordination of the main issues related to IDN ccTLD strings is needed. One of the most important aspects in this coordination process would be a proper balance between the general rules vs. level of autonomy at the "territory" level. At the initial stage, there can be implemented a bottom-up vs. informal coordination model, which based on the Lessons learned vs. Good models would further develop into more global/formal coordination model if needed.
___________________________________
Mohammed: Question 10-12
Q.10: Who can apply to have the IDN ccTLD delegated or to be the delegate for that ccTLD and,who decides on the delegation? <br> A. ccTLD Manager ( Sponsoring Organization ) should have the right to apply for a delegation of IDN ccTLD, ICANN should ensure that the local internet community has been consulted and that a local multi-stakeholder agreement have been reached on the IDN ccTLD Delegation and the public policies issue related to IDN ccTLD.
Q.11: Should there be an agreement between ICANN and the IDN ccTLD operator on the operation of the IDN ccTLD string?<BR>* A.This Question looks simple but represent a very complex and sensitive issue, IDN ccTLD operators should agree to a set of rules and operational guidelines to be followed inorder to insure stability and interoperability of the DNS .
This agreement on those set of rules should be a “consensus agreement” between ICANN and IDN ccTLD operators .
* *****Comment by Siavash This issue is more sensitive than it sounds. There is a distinction between 'agreement with ICANN' and 'coordination with IANA'. It is the latter that speaks to stability and interoperability issues; the former is regarded by many ccTLDs as political or having other implications as evidenced by the small number of ccTLDs having formal contracts with ICANN. Even an 'accountability framework' between certain ccTLDs and a corporation governed by California law may be illegal by US law and/or the laws of the other country.
* **********Comment by Hong: I share the same concern with Siavash.<BR>*
* *************** Comment by Mohamed : i totally agree this is a very complex question, Agreement dose not need to be in the form the current ccTLD MOUs or Accountability framework, the IDN guidelines could form a base of agreement and consent between ICANN and IDN ccTLD, this quidelines are obligatory to gTLD operators planning to introduce IDNs it.
Q.12: Is the operation and management of an IDN ccTLD different to that of an existing ccTLD&lt;BR&gt;such that there be specific global technical requirements related to running the IDN ccTLD?<br><br> A. Due to the Language and cultural sensitivity, in both Technical and administrative aspects the operation of an IDN ccTLD might be slightly different from the management of existing ccTLD, inorder ensure consistency and stability the preference should be that the existing ccTLD operator could be the new IDN ccTLD operator unless the local internet community have objections on the current ccTLD operator and requested a delegation of IDN ccTLD to a new sponsoring organization .
II. Completion of the draft answers by August 5
See the comments below the answers.
III. Public consultation through IDN-WG list by August 17
On August 5, email sent to the idn-wg@atlarge-lists.icann.org.
IV. Revsion of the answers, August 31
V. Public Consultation through RALOs, September 28
VI. Revision and completion of draft report, October 13
VII. Public Comments , October 20
VIII. Completion of final report, October 25
The only comment I have is regarding Q 3-5.
If we use Japan as an example of where more than one typeset may be used (hiragana, katakana, kanji, romanji). I think this situation should be a consideration, but delegated to the respective ccTLD managers so long as we provide them with the ability to do so.
Randy Glass
A@L
contributed by Guest User on Aug 7 7:09pm
Comments on Q3
One IDN ccTLD per script per territory is a good way to get things moving. In the cases of the same script has different representations for the territory name, it's suggested that the different representations(variants) should be treated as one IDN ccTLD. However, it should be carefully reviewed.
Comment by Siavash: I'm not sure I really understand how you want to treat the variants as ONE ccTLD. Do you mean to use a 'bundle' to automatically identify the two? Please look at the revised answer to Q.3 and see if that answers the problem.
Comments on Q11
Agree with what the three editors said. Just another thought, the "agreement" may not be an agreement between ICANN and ccTLD manager in any form, but instead, it can be an "consensus agreement" between a specific ccTLD manager and the global DNS/Internet community which states that as an IDN ccTLD manager, we should agree or abide to such set of technical and administrative principles in operating IDN ccTLDs. It's very much like a ccTLD manager saying that it will conform with a RFC.
That way, the stability and security of the DNS is ensured in a written way and it should enable ccTLD managers to avoid unnecessary political complexity.
Comments on Q12
Sorry, but I don't think the answer is what the question is asking for.
IDN TLDs, due to its language and culture sensitivity, in both technical and administrative aspects, may require slightly different approach in operation and management. However, how different should that be is up to the ccTLD manager and local community to decide. The multi-stakeholder model should be implemented, and the basic set of principle should be followed in the process.
Howard Li
CNNIC
contributed by Guest User on Aug 13 7:41pm
Comment by Vittorio
- Is a two-track approach appropriate?
It seems to me that IDN ccTLDs are (if done in a certain way) less
problematic than IDN gTLDs. Given that the new TLD process won't be in
operation before the second half of 2008 at the earliest, possibly a
quick round of IDN ccTLDs could be useful to be responsive to the demand.
It is true that current gTLD operators are not so happy, because ccTLD
operators will be able to start selling IDN.IDN names well ahead of
them, thus occupying the market. But I think that - as long as the new
TLDs are actual ccTLDs, i.e. are meant to represent the country's name
and to become the counterpart of the existing ASCII ccTLD - these
communities have a right to get an IDN TLD started as soon as possible,
and I think that an IDN ccTLD is a reasonable starting point.
- Should the current ccTLD operators be the operators of the new IDN ccTLDs?
The operator of the new IDN ccTLD should be picked with the agreement of
the government and of the current ccTLD operator. If they disagree, then
it is up to them to agree. In case of competing proposals, ICANN should
stop the quick process for that TLD, and defer it to the full process.
- How many IDN TLDs?
Personally, I do not really see the reason why to limit the creation to
one per ccTLD. If some countries use several languages / scripts, they
should be able to start their IDN ccTLD in all of them at the same time
if they wish. The limit should just be on the semantics, i.e. on the
fact that all these strings must represent the country's name. Also, I
would still keep a limit of one TLD per (language, script) couple.
- Should there be a mandated list of IDN ccTLD strings?
This is a crucial issue. If you decide that you need an equivalent of
the ISO 3166 list in each (language, script) couple, then IMHO you are
headed for disaster. According to staff, it will take 2 to 5 years to
get these lists prepared and approved by ISO; also, it will bring ICANN
into the role of drafting these lists, something that brings political
problems with it, and that ICANN has always avoided; also, it will
create the problem of who is authorized to pick the representation of
country X in language Y and script Z - i.e., who is the authority for
this language and script? I would rather - especially for an interim
phase - let existing ccTLD operators propose strings that they think
could work, and just employ third party linguistic/cultural know-how to
judge whether such strings actually reflect the country's name in some way.
I would anyway suggest that ICANN asks proponents to harmonize the
strings chosen for the same (language, script), if more than one appears
in the same round. E.g. let's say that we get more than one ccTLD
proposal for (Arabic, Arabic); then ICANN should encourage the proposers
to agree on similar ways to format the strings, so that we don't have,
for example, an abbreviation for one country but a full name for another
country, which would look confusing (as if, in ASCII ccTLDs, we had .tn
for Tunisia but .egypt for Egypt - is it clear what I mean? it'd be
better if people agreed to have, in the same language/script couple,
either all abbreviations of the same type, or all full names; though
different languages or scripts might make other choices).
- What kind of agreement with ICANN should IDN ccTLD operators sign?
I agree with Siavash, the issue is very sensitive. Many ccTLDs don't
like the idea of signing contracts with ICANN, often for political
reasons (e.g. not to recognize the special USG role in the oversight of
the root zone, or to claim full sovereignty on the TLD policies). On the
other hand, there is the need for ICANN to be able to enforce certain
global policies when they are necessary to preserve the global stability
of the Internet (for example, what if certain TLDs started to employ
practices that are commonly considered harmful, e.g. wildcards?). Also,
the gTLD registries and registrars - which pay ICANN fees - are afraid
of a situation in which ccTLDs could host the vast majority of
registrations, yet not be subject to appropriate fees for the
maintenance of ICANN (even if ccTLDs already pay ICANN fees).
Personally, I would think that ccTLDs should sign something that at
least commits them to follow consensus policies decided by the ccNSO,
and to pay some kind of fees to ICANN. But this issue is very difficult,
so I don't have a strong opinion.
contributed by hongxueipr on Aug 27 6:25am
