Transcript Document 7697744

Internationalized Domain Name
Evolution
Kenny Huang
TWNIC
2001.10.17
Demands
Where and How
Human factors
• People would like to name themselves and
their objects in their own language
• ISO 10646+UNICODE is a necessary answer,
but not sufficient
• DNS has some shortcomings as well
Deployment Issues
• Objectives of Internationalizing Protocols
• Deploying parallel name spaces
• Deploying parallel communication spaces
Objectives of Internationalizing
Protocols
• Many protocols internationalized:
– SMTP, HTML, etc
• Domain Name Service foundational
– and therefore has earthquake effects if changed
without thinking clearly
Deploying parallel name spaces
• Simple to do – Deploy many DNS roots with different name
spaces
• Effect:
– People using one cannot find people in another
– Commerce diminished
– Mail exchange impeded, etc
Correctness issues
• Many servers running Bind
– Often as old as version 4
• Incompatible upgrades cause other systems
to fail
– Software reliability is one of the big issues, and
this is a key component
ASCII (ACE) or non ASCII IDN
• The IDN solutions can be very extreme,
there is no intermediate solution
• ACE has short-term benefit but has longterm penalty
• 8bit clean technique introduces system
vulnerability ?
Policy Perspective
WHO’S WHO
Who Own and Control the Internet?
•
•
•
•
•
Domain Names(gTLD, ccTLD)
IP Address
Protocol Parameter
Root Server
BIND
ICANN
Govt. Advisory
Committee
ICANN
(Formally IANA)
DNS Root Server
TLDs:
gTLD/ccTLD
ARIN,RIPE
APNIC
IETF/IAB
What ICANN does
• To Coordinate the unique assignment of
• Three values that are essential to the
• Proper functioning of the Internet
– Domain Names
– IP addresses
– Protocol port and parameter numbers
What ICANN does not do
•
•
•
•
•
Content Control
Network Security
Data Privacy Protection
Setting multilingual name standards
Multilingual Internet interoperability
ICANN’s Responses
• 2000. 3 Cairo
• 2000. 6 Yokohama
– ASCII, Internet Language
• 2000. 11Marina del Rey
– To host Internationalized Domain Names Workshop
• 2001. 3 Melbourne
– To discuss Internationalized DN in the public forum
MINC
• Coordination of R&D on multilingual names
• Coordination on deployment of multilingual names
• Coordination with the relevant organizations i.e.
IETF, W3C, ICANN, ISOC, Unicode, IEEE, ISO and ITU
• Coordination for standards development
Issues of Interoperability
• Tower of Babel – Babelisation of Internet has taken
place.
• “Islands” of the Internet should be prevented i.e. which
should not fragment the network with multiple noninteroperable standards
• Asia Pacific Taskforce on internationalising Domain
Names set up
• Internet Engineering Task Force urgently set up IDN
Working Group
Several Multilingual Domain Names
Testbeds emergent
• Industry driving this
• NSI (Verisign) and partner companies setting up
multilingual.com services testbed
• JPNIC, KRNIC launching production level testbeds for
japanese.jp and korean.kr
• CNNIC, TWNIC, HKNIC, MONIC forms CDNC
- in progress
MINC’s Role
• MINC will coordinate the Interoperability
Testing as a whole.
• MINC will commission the Interoperability
Testing Working Group to manage the
Testing.
• MINC will operate the testing using a selffinancing cost-recovering model.
What is JET?
• Joint Engineer Team for developing Open Multilingual
Domain Name System for ICANN TLDs.
• Core members are CNNIC, JPNIC, KRNIC and TWNIC.
• ISC, IETF co-chair and VeriSign GRS are invited.
• Business status & plan are exchanged for the better
service introduction.
JET meetings & Discussions
• 1st : July 15 2000 (Yokohama)
 Local charset or ACE
• 2nd : Aug 28-30 2000 (Beijing)
 Common mDNS
• 3rd : Nov. 29-30 2000 (Taipei)
 Global/Localized components
• 4th : Feb. 28 – Mar 1 2001 (Kuala Lumpur)
 IETF Standardization & Localization
• 5th : June 25-26 2001 (Shanghai)
• 6th : Oct 18 2001 (Beijing)
– Last f2f meeting before IETF standardization
Open Source Code
• TWNIC/CNNIC
– mDNS with 8-bit clean BIND
– 8-bit clean Squid proxy/Apache web server
• JPNIC
– mDNkit
• To be fully compatible with IETF standards
• Core library for processing mDN
– Code conversion between local charset and ACEs
– Normalization
• Tools for code conversion
– mdnconv, dnsproxy, runmdn, mDN Wrapper
• BIND 8 & 9 Patches
JET Outcome
• Information exchange on the business
–
–
–
–
Service menu & schedule (JPRS)
System development
Reserved words
DRP
• Engineering Discussion
• IETF Contribution
–
–
–
–
UNAME
TSCONV
JPCHAR
HANGUELCHAR
• Software Release: JPNIC’s mDNkit Plan
• Localization
CDNC
• Members : CNNIC, TWNIC, MONIC, HKNIC
• Development
– multilingual domain name system
– system interoperability
• Information Sharing
• Multilingual domain name service
activation and operation
CDNC Experience
• Strong momentum from official registries
• First organization introduce multiple root
systems model (chain table) and
multilingual ccTLDs, gTLDs (全漢字)
• Normalization
– Simplified Chinese Characters vs. traditional
Chinese Characters
Technology Perspective
IETF IDN Movement & Status Update
IDNA Concept
Input/Output
IDNA
Transformation
Communication
Layer
DNS Protocol
Application
Protocol
IDNA Overview
• Changes of presentation layer of
applications
• No changes to application protocols
• No changes to DNS protocol
• No changes to any current DNS servers
IDNA Interface Components
Changes to applications for IDNA
• Input of host names
– Prepares name using stringprep
– Applies an ACE
– Sends encoded name to resolver (as well as application layer
protocol)
• Display of host names
– Scans displayable text or protocol elements for ACEs
– Displays them in local display format
STRINGPREP
• Output of a single, unambiguous string
• Let user enter anything that might look
correct to them
• Typical users should be able to follow logic
of preparation
Overview of STRINGPREP
• Mapping
– Mapping characters to other characters
• Normalization
– Normalizing the characters
• Prohibit
– Excluding characters that are prohibited from in
internationalized host names
Ripple Effects
• Un-updated applications will display obscure
ACE format
• Non-IDN names that use the ACE prefix or
suffix will either be considered illegal or will
appear as nonsense characters
• Doesn’t internationalize text records in the
DNS zone files
Administrative Issues
• Administrative interface for DNS servers
must all check IDN names
• Probably done with automated scripts
converting from and to preferred native
format
• Will probably be important to check all
names with stringprep, even after they are
in the zone files
IETF IDN Update
• AMC-ACE-Z as chosen ACE
• nameprep/tsconv/hanguelchar/jpchar/stringprep
should be consolidated into one architecture
• the requirements draft will be moving forward
for IETF Last Call
• Go forward with IDNA.
IDNA Possible Structure
Client
Local Process
Localization
StringPrep
Reordering
AMC-ACE-Z
IDNA
Internationalization
Search Model Example One
StringPrep
TC/SC Engine
Application
Yellowpage
DNS
Search Model Example Two
StringPrep
Application
Yellowpage
DNS
THANK YOU