internationalized domain name evolution
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Internationalized Domain Name Evolution
Kenny HuangTWNIC
2001.10.17
DemandsWhere 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 long-term penalty
• 8bit clean technique introduces system vulnerability ?
Policy PerspectiveWHO’S WHO
Who Own and Control the Internet?
• Domain Names(gTLD, ccTLD)• IP Address• Protocol Parameter• Root Server• BIND
ICANN
ICANN(Formally IANA)
TLDs:gTLD/ccTLD
ARIN,RIPEAPNIC
IETF/IAB
Govt. AdvisoryCommittee
DNS Root Server
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 non-interoperable 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 m
ultilingual.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 self-financing 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 Chi
nese Characters
Technology PerspectiveIETF IDN Movement & Status
Update
IDNA Concept
CommunicationCommunicationLayerLayer
Input/OutputInput/Output
DNS ProtocolDNS Protocol Application Application ProtocolProtocol
IDNAIDNATransformationTransformation
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 laye
r 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
StringPrep
Reordering
AMC-ACE-Z
Localization
IDNA Internationalization
Search Model Example One
ApplicationApplication
StringPrepStringPrepTC/SC EngineTC/SC Engine DNS
Yellowpage
Search Model Example Two
ApplicationApplication
StringPrepStringPrepDNS
Yellowpage
THANK YOU