AT-LARGE GATEWAY
At-Large Regional Policy Engagement Program (ARPEP)
At-Large Review Implementation Plan Development
Page History
Important Information Links | |
Comment Open: | 6 January 2012 |
Comment Close: | 7 February 2012 |
Close Time (UTC): | 23:59 UTC |
Reply Open: | 8 February 2012 |
Reply Close: | 7 March 2012 |
Close Time (UTC): | 23:59 UTC |
Brief Overview |
|
Originating Organization: | Joint ccNSO and GNSO IDN Working Group (JIG WG) |
Categories/Tags: |
|
Purpose (Brief): | The Initial Report reflects the preliminary stocktaking by the WG members of policy and other considerations relating to the Universal Acceptance of IDN TLDs. |
Current Status: | Seeking public comment on its Initial Report is part of the process to report on identified issues to the respective Councils and propose a methodology to address the issues. |
Next Steps: | The WG will closely review all submitted comments to revise and assess its preliminary stocktaking. |
Staff Contact: | Bart Boswinkel |
Email: |
JIG Initial Report on Universal Acceptance of IDN TLDs downloadable from here.
Click here to download this draft Statement in PDF form.
DRAFT ALAC STATEMENT ON JIG REPORT ON UNIVERSAL ACCEPTANCE OF IDNs
Acknowledgement of Work done by the JIG
The ALAC has noted the JIG Report on Universal Acceptance of IDNs (JIG Report on UA of IDNs) and acknowledges the manner in which they have assessed the work done by ICANN on Universal Acceptance. The ALAC supports the preliminary viewpoints and possible approaches identified in the JIG Report on UA of IDNs. In particular we welcome the questions about how ICANN should prioritize its efforts and exert its influence to best promote Universal Acceptance.
The ALAC advises that it should include but not be limited to the 5 areas identified by the JIG Report on UA of IDNs:-
a) Browsers and DNS Lookup tools and components
b) Network infrastructure, hosting and email providers
c) Network management and security tools
d) Applications and databases (where domains, email addresses and/or URLs represents a data object maintained, e.g. user profiles, contact information, search engines, etc.)
e) Registries, Registrars and RIR systems.
The need for flexibility when it comes to IDN Policies
The ALAC believes that every culture and language is unique and attempts to uniformly apply rules and restrictions across cultures and languages would inevitably lead to maladministration. The ICANN should be flexible in adopting different policies for different cultures and languages when it implements IDN Policy.
Creating a culture of supportive policies for IDN TLDs
The ALAC understands that Universal Acceptance is a collective responsibility of the global internet universe. The ALAC acknowledges the sphere of influence that ICANN has in ensuring that there is a level of coherence in policies that will exert the relevant influence in promoting the goal of universal acceptance. Whilst policies developed and enforced by ICANN may not directly solve the issue of Universal Acceptance, the ALAC supports JIG’s views that ICANN has significant influence to promote the goal of Universal Acceptance of IDN TLDs through supportive policies for IDN TLDs through Internet applications, devices, infrastructure and other hardware and software systems.
Identification of Stakeholders, Coordination and Policy Issues
The ALAC welcomes and supports the multi stakeholder approach which includes the identification of stakeholders, coordination and policy issues identified in the JIG Report on UA of IDNs. Aside from the stakeholders identified in the JIG Report on UA of IDNs, they should be extended to include Network Operator Groups (NOGs), GAC, and utilise forums like the regional IGFs to create awareness. It is also critical to get intergovernmental organisations involved especially the ITU through the ITU Telecommunication Standardization Sector (ITU-T) and UNESCO. The ALAC notes the ITU Resolution 133 on the Role of Administration of Member States in the management of Internationalized (multilingual) Domain Names.
Solutions are not always technical
Wiki Markup |
---|
Whilst the ICANN by its very nature is a type of multi stakeholder technical coordination body, it tends to seek comments and rely on comments from the technical community. The ALAC in a 2010 Statement is on record to say that not every problem has a technical solution and that ICANN should not deter from making a policy decision even when technical solutions do not exist\[[1]\|#_ftn1\]. An illustration to from a previous statement is as follows\[[2]\|#_ftn2\]:\- |
The Chinese SC-TC problem is a classic case. During the early days of IDN, it was proposed that SC-TC be handle within the IDN protocol. There was a long debate among the IETF Working Group participants and a strong push from the Chinese technical community.
If we have resolved SC-TC problem within the IDN protocol, we would not have issues like Synchronized IDN ccTLD. Unfortunately, it is impossible to deal with it at the protocol level because SC-TC mapping is almost 1-1 but not always. More importantly, such mapping will cause problems for the Japanese and Korean, both with also use the same Han ideograph like Chinese.
So when SC-TC was rejected at the protocol level, it encouraged the community, particularly the Chinese, Japanese and Korean to work together on RFC 3743 (Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean). The community understood some problem has to be resolved at the registration and administration policy level.
From RFC 3743:
"Addressing the issues around differing character sets, a primary consideration and administrative challenge involves region-specific definitions, interpretations, and the semantics of strings to be used in IDNs. A Unicode string may have a specific meaning as a name, word, or phrase in a particular language but that meaning could vary depending on the country, region, culture, or other context in which the string is used. It might also have different interpretations in different languages that share some or all of the same characters."
"Additionally, because of local language or writing-system differences, it is impossible to create universally accepted definitions for which potential variants are the same and which are not the same. It is even more difficult to define a technical algorithm to generate variants that are linguistically accurate."
It is technically impossible to resolve Chinese-based languages community at a technical level. Similarly, there are other languages likewise. Therefore, ICANN should not be deter from making a policy decision even if a technical solution does not exist if it serves the larger good of the community.
ALAC would like to encourage ICANN to prioritize its efforts and exert its influence to best promoting Universal Acceptance and thanks the JIG for the initial report.
Wiki Markup |
---|
\[[1]\|#_ftnref1\] [https://community.icann.org/display/alacidnpolicy/ALAC+Statement+IDN+Issues] |
Wiki Markup |
---|
\[[2]\|#_ftnref2\] ibid |