cctld idn report cctld meeting, montreol june 24, 2003 young-eum lee([email protected])
TRANSCRIPT
IDN Management
• Technical Standard– IETF
• Individual Efforts (ccTLDs, Commercial)– CNNIC, JPNIC, KRNIC, TWNIC, Verisign, i-DNS
• Regional and Language Groups– CDNC, INFITT, CLINC, EUROLINC, Arabic
• International Efforts– ICANN, MINC
• ccTLD– Individual, Regional, Language, International
IDN Status 1
• Some gTLDs and ccTLDs registering since 2000• Language Groups being formed• Actual deployment mainly in Asia• ccTLD IDN TF
– Feb., 2003, Workshop, March, Rio Meeting
• Proposed IETF Standard, prefix determined, RFCs announced, March, 2003
• ICANN IDN-RIC Document in March, 2003
IDN Status Since March, 2002
• Individual Efforts continue:– ccTLDs, Verisign, I-DNS
• Not much Language Group activity – CDNC unified table not announced yet– .kr working on technical standards document
• Technical Coordination Efforts– IDN Connect: JPRS– MINC: Interoperability Testbed
• ICANN IDN-RIC document– Still to be worked on– Wording changed from “must” to “will”
ICANN and IDN
• ICANN IDN Committee– Formed in Sept. 2001(March, 2001)– IDN Implementation committee– IDN-RIC in March, 2003
ICANN
• IDN Requirement Document
• March 13, 2003: “Standards for ICANN Authorization of Internationalized Domain Name Registrations in Registries with Agreements”
• http://www.icann.org/riodejaneiro/idn-topic.htm
• Revisions from “must” to “will”
• 1. Top-level domain registries that implement internationalized domain name capabilities will do so in strict compliance with the technical requirements described in RFCs 3490, 3491, and 3492 (collectively, the "IDN standards").
• 2. In implementing the IDN standards, top-level domain registries will employ an "inclusion-based" approach (meaning that code points that are not explicitly permitted by the registry are prohibited) for identifying permissible code points from among the full Unicode repertoire.
• 3. In implementing the IDN standards, top-level domain registries will (a) associate each registered internationalized domain name with one language or set of languages, (b) employ language-specific registration and administration rules that are documented and publicly available, such as the reservation of all domain names with equivalent character variants in the languages associated with the registered domain name, and, (c) where the registry finds that the registration and administration rules for a given language would benefit from a character variants table, allow registrations in that language only when an appropriate table is available.
• 4. Registries will work collaboratively with relevant and interested stakeholders to develop language-specific registration policies (including, where the registry determines appropriate, character variant tables), with the objective of achieving consistent approaches to IDN implementation for the benefit of DNS users worldwide. Registries will work collaboratively with each other to address common issues, through, for example, ad hoc groups, regional groups, and global fora, such as the ICANN IDN Registry Implementation Committee.
• 5. In implementing the IDN standards, top-level domain registries should, at least initially, limit any given domain label (such as a second-level domain name) to the characters associated with one language or set of languages only.
• 6. Top-level domain registries (and registrars) should provide informational resources and services in all languages for which they offer internationalized domain name registrations.
Issues in ICANN IDN
• Document source is JET
• Individuals from ccTLD community participate
• Otherwise, industry de facto standard may be implemented – BINDING!!
• ICANN document – possible for ccTLD input
• ccNSO and Scope
KR’s Position
• IDN interoperability is necessary• Cooperation among various entities needed• ICANN policy should not be binding• However, don’t have much problems with the cont
ent of the ICANN IDN-RIC document • ICANN IDN-RIC should be presented as best prac
tice.• Unless the IDN-RIC document goes through the c
cNSO PDP, it should not be binding
IDN Issues
• Technical – Coordination necessary– Language, Scripts, Codes: Individual language
tables to be agreed on by the language community
– 1:n, n:1, n:1: can be solved by individual character variant tables.
• Policy– Registration: Locally determined– DRP: Locally determined– IP: Locally determined
Technical Coordination
• International standard: IETF
• Adoption: International and Local Internet Community
• IDN Connect: JPRS initiative
• MINC interoperability testbed
• Browser Development: Verisign’s plug-in, I-DNS plug-in, KRNIC plug-in, etc.
• MS OS incorporation not yet planned
Issues Identified by ccTLD IDN Workshop• Information exchange about experiment
s and the experience on services is needed.(e.g., CJK model)
• In respect for the IETF standards, xn-- needs to be blocked universally at all levels of domain names under the jurisdiction of TLDs.
• Registration Policies should be determined by the respective TLDs
• User requirements should be addressed, not only in registration but also in resolution.
• Sensitivity to the multilingual and multicultural community's requirements is needed.
• Interoperable implementation of IDNs need to be coordinated globally by test coordinators.
• Formation and deployment of variant tables in respective languages need to be consulted amongst all of its users.(e.g., CJK Mapping)
• DRP issue needs further discussion.
Action Plan: Agora & Outreach
• Global focus needed
• Regional, language, and individual efforts need to be coordinated – ccNSO PDP?
• Outreach
• Coordination – Interoperability testing, Language group coordination
• Information Sharing
