Transcript ccTLD IDN Report ccTLD Meeting, Montreol June 24, 2003 Young-Eum Lee([email protected]) IDN Management • Technical Standard – IETF • Individual Efforts (ccTLDs, Commercial) – CNNIC, JPNIC, KRNIC,

ccTLD IDN Report
ccTLD Meeting, Montreol
June 24, 2003
Young-Eum Lee([email protected])
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/idntopic.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, toplevel 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
content of the ICANN IDN-RIC document
• ICANN IDN-RIC should be presented as best
practice.
• Unless the IDN-RIC document goes through the
ccNSO 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
experiments 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
Mailing List:
[email protected]
Inquiries to:
[email protected]