• 举报邮箱:jubao@apac.cn
  • 举报电话:010-58813000
  • 举报平台:jubao.apac.cn
 
CNNIC多语种域名管理报告 (English)
发表日期: 2010-09-20
打印 文本大小:
 

MANAGEMENT ISSUES ON IDNS


THE PROSPECTIVE OF CNNIC

 

We noted the ICANN's announcement published on August 25, 2000. We agree with ICANN that it is very important that the Internet evolves to be more accessible to those who do not use English-language character sets.

We also noted the Status Report of ICANN IDN WG released on
June 1, 2001. According to the Report, respondents to the Survey launched by ICANN IDN WG, generally had a very positive attitude towards IDNs. They observed that most of the world's population does not use Latin script as its native script. IDNs, accordingly, will increase access to and use of the Internet. Additionally, IDNs will increase access to this population by businesses and organizations that now are constrained by Latin script domain names.

We agree the principle of development of IDNs that the internationalization of the Internet's domain name system be accomplished through standards that are open, non-proprietary, and fully compatible with the Internet's existing end-to-end model and that preserve globally unique naming in a universally resolvable public name space. A fundamental requirement in this work is to ensure that the DNS continuously allows any system anywhere to resolve any domain name, without disturbing the current use and operation of DNS.

We, however, worry that without proper IDN management policy, there is the danger of "balkanization" of Internet,hence to harm the stability of Internet. During the policy making process, we hope ICANN could enhance the harmonization with local Internet communities or specific language cooperative organizations that are interested in and influenced by IDNs.

We are of belief that the following points should be highly noted in developing IDNs.


1.    The development of MDN should not only ensure the stability and compatibility of the current Domain Name System, but also should guarantee the interests of those language users and respect the policy mechanisms of local society where majority specific language users live, such as politics, economy, legal system and culture.


2.    IDNs are not simply the issue of Technique, but more relevant to Management. Since the fundamental purpose of deployment of IDNs is to serve the demand for non-English speaking Internet communities, IDN management should not be fully controlled by commercial interests. When making the policy of IDN management, those language users should be given the opportunity to voice their opinions on relevant IDNs.


3.    Those cooperative organizations formed by the Internet communities who speak native languages other than English should be encouraged to play an important role in relevant IDN management, provided that those organizations operate within the current DNS and under the coordination of ICANN.


  Considering the complexity of management of IDNs, we suggest to set easy before hard, gradually open and push forward IDNs by stages and levels.

STEP ONE: IDNs and ccTLDs

  It will be sure to intensify ICANN's existing authoritative status; It's easy for ccTLDs managers in being to provide IDNs registration service under corresponding ccTLDs for their long-term registration serving experiences; Disordered situations resulted from user applying IDNs registration from different IDNs registration service providers can be avoided effectively.

Level One: IDN.IDNccTLD

  It's suggested that ICANN establishes a list of IDNccTLDs.

  Definition: IDNccTLDs refer to TLDs in IDNs. Generally, IDNccTLDs should be the country names in the national languages corresponding to existing ccTLDs. For example, China's IDNccTLD should be ".
中国".

  Significance: IDNccTLDs are not only identifiers, but also relevant to national identities. ICANN should be very cautious when dealing with such issues. Feasibility study may be needed before any policy is made.

  Registry: Existing ccTLDs managers are in the vital position in respect of IDNccTLDs. Those managers are delegated by ICANN and approved by relevant governments. They are in close relationship and effective communication with the governments. Where national identities are concerned, it is desirable to retain those managers' management status and system when deploying IDNccTLDs.

  Characteristics:


l    IDNccTLDs should be completely on voluntary basis. Existing ccTLDs managers may apply for a IDNccTLD or choose not to do so.

l    Each ccTLD manager should only be permitted to apply for one IDNccTLD.

l    It is each ccTLD manager that decides, under the approval of relevant government, the name or language of the IDNccTLD applied. A country may have multiple names (or abbreviation) or may use multiple languages. Deciding the name or language used in the IDNccTLD should be the internal affairs of that country.ICANN has no obligations to resolve the internal affairs for the countries using multiple languages.It is suggested that ICANN should defer the delegation of such IDNccTLD until the relevent country has selected one kind of language.

l    ICANN may limit the length of the scripts of each IDNccTLD. There should be a procedure to address the issue of the duplication of applied IDNccTLDs.

 

Level Two: IDN.ccTLD

  Significance: we noted that ICANN recognizes the practices of IDN.ccTLD provided by ccTLDs managers .We acknowledge that IDN.ccTLD is an expedient solution for the demand of IDNs of local Internet community.

  ccTLD Managers: It should be in ccTLD managers' discretion to decide whether to provide IDN.ccTLD services.

  ICANN Coordination: In order to prevent disputes between such ccTLD managers, we suggest that ICANN coordinate such mixed IDN services and ensure that one ccTLD manager merely provide one local language IDN service under the ccTLD.

  Common Ground for the Two Levels: DRP

  Localization: Since IDNs under ccTLDs are in local languages and registered through ccTLD managers, DRP should be more localized, and managed by local institutions.

  DRP Systems: Once the IDNs under ccTLD system are deployed, all the existing DRP systems (court proceedings, arbitrations or ADRs) in each ccTLD may extend to them to resolve the disputes caused by abusive registrations.


STEP TWO: IDNs and gTLDs

 Level One: IDN.IDNgTLD

  It's suggested that ICANN create IDNgTLDs and relevant management system after effective consultation with non-English speaking Internet communities that would like to use gTLDs in their own languages.

  Definition: IDNgTLDs refer to gTLDs in IDNs. For example, corresponding to gTLD ".com", Chinese users may prefer ".
公司", while Japanese users may prefer ".株式会社".

  Significance: IDNccTLDs cannot fully satisfy the demand for IDNs, because many countries or regions may share the same language, and IDNgTLDs are needed in these language communities.

  Current Problems: At the present time, several commercial interests around the world start to recommend new IDNgTLDs and provide corresponding registration services.This kind of IDNgTLDs developed by the different commercial interests, each does things in its own way and no uniform and normative DRP system.So the registration under these IDNgTLDs will inevitably result in a lot of cybersquattings
repeated registrations improper directings and non-uniqueness of the resovling pathes, consequently cause the perplexity in the field of existing Internet DNS.

  Management: Obviously, the core problems in IDNgTLD are not gTLD but IDN
thus the management issue of the IDNgTLD are different from gTLD in English.the Internet communitiy who perfectly knows IDN should act an most important role in the management of IDNgTLD.

  Consensus: In order to create a bottom-up system for the users of a language to voice their opinion and input their suggestions, the Internet community that shares the same language should be encouraged to form cooperative organization. Consensus on IDNgTLDs may be formed on the basis of these cooperative organizations. The solution based on consensus should consider the habit, custom and culture of specific language community.

  ccTLD Managers: The ccTLD manager of the country or region in which majority of the users of a language reside may act as the coordinator of the cooperative organization of the specific language, but generally the organization should be open to all the users of that language.

  Registry: Each cooperative organization, after consultation with ICANN, may act as the nomination body for the registry of the IDNgTLD in specific language based on the consensus of the relevant community. ICANN may delegate the registry after receiving the nomination from relevant cooperative organization.

Level Two: IDN.gTLD

  Current Situation: Some gTLD manager has provided IDN.gTLD services to the public. There exist serious abusive registrations and improper registration management in such services.

  ICANN Management: We suggest, rather than taking "let it be" policy, ICANN should cooperate with non-English speaking cooperative organizations to regulate such gTLD manager's practices, especially in the aspects of registration policy and DRP issues.

  Common Grounds for the Two Levels: DRP

  Characteristics: The DRP should keep the balance between the characteristic of gTLDs and the characteristic of IDNs. Therefore, a unified DRP may not provide desirable solution for the disputes in different languages. The DRP must take into account the various elements of the culture, language and legal system relating to IDNs.

  Solution: The DRP for those gTLDs may not be "localized", but should be "regionalized" based on language communities. Non-English speaking cooperative organizations should develop DRP for domain name disputes in their own languages, and delegate dispute service providers.



相关附件
相关文档
2010 Copyright. 中国反钓鱼网站联盟 版权所有
ICP备案编号:京ICP备15032509号-1