IDN Standards and Implications Kenny Huang Board, PIR

Overview IDN Standard Update What needs to be done The future of IDNs

IDN Standards Update IETF and Protocol Standardization ICANN and Policy Guidelines Relevant Linguistic Issues TLD Deployments

IETF and Protocol Standardization IDN RFCs –3490 IDNA – Framework for conversion of IDN into Punycode at the application end for DNS resolution –3491 Nameprep – Stringprep Profile for use in IDNs (case mapping, normalization and “ sanitization ” to reduce ambiguity of names) –3492 Punycode – An ACE (ASCII Compatible Encoding) for use in IDNs –3454 Stringprep IESG Statement –IDNA does not solve all of the problems of IDN

ICANN and Policy Guidelines Strict compliance with IDN Standards (RFC 3490, 3491 and 3492) “ Inclusion-based" approach for identifying permissible code points for registration Associate each registered IDN with one language or set of languages, and employ language-specific registration and administration rules that are documented and publicly available Work collaboratively with relevant and interested stakeholders to develop language-specific registration policies –Should, initially, limit any given domain label to the characters associated with one language or set of languages only –Should provide informational resources and services in all languages for which they offer internationalized domain name registrations

Relevant Linguistic Issues ICANN requires registries to establish Language-specific registration policies –What authorities are “ authoritative ” for which languages? –What if there are more than one possible “ authority ”, e.g. French used in different parts of the world? Character Equivalence Mapping –Should there be Character Equivalence Mapping for visually identical (or close to identical) characters (e.g. Greek capital Alpha and English capital “ A ” ) –Other Languages that may have “ traditional-simplified ” equivalence issues –How far down the “ semantic ” path should we get?

TLD Deployments Verisign.COM and.NET.ORG legacy IDN registrations.CN,.TW Chinese Implementations.KR,.JP Implementations.NU,.BZ,.TV Implementations European Implementations (.DE,.AT,.CH,.PL) Afilias.INFO Implementation Other planning and scheduled implementations

Where are we heading? Wider spread deployment Wider spread doubts Internet navigation becoming more user-friendly for the rest of the world Internet navigation becoming more confusing for everyone Highly dependent on the deployment path and user expectation management

Who needs to be doing what? Registry Responsibilities –DNS Resolution, Domain Registration & WHOIS –Interim Resolution Strategies, IDN over EPP, IDN at WHOIS Application Developers –IDN Resolution –Speed of deployment ICANN & IETF –Policies and Standards –Consistent & promote wide adoption Linguists –Linguistic Relevance –Start conservative with the goal to become as light-weight as possible Service Providers –Accept IDN traffic (Do Not Block) –Manage and maintain IDN information

IDN and Web Browsing What is Happening Today: –IDNA-enabled Browsers Mozilla 1.4+ & Opera 7.1+ –IDNA plug-ins –Assistive Resolution Platforms Web Redirection –Synthesized-IDN A RR –E.g. Verisign (.COM /.NET),.CN,.TW,.JP,.KR 8-bit DNS Resolution –Synthesized CNAME RR (DNAME based concept) to Punycode Domain –E.g. Afilias (.INFO),.BZ

IDN and Web Browsing Areas of consideration for Application Providers –Address Bar, IDN Links, Bookmarks –History, Status Bar, Etc. –Integration with other applications (e.g. copy-and-paste) IRI – Internationalized Resource Identifiers

IDN and IDNA MUA plugins (Mail User Agents, e.g. Outlook, Eudora, etc.) Assistive Resolution Platforms –Mail Relay Synthesized MX record –8-bit DNS Resolution Same as in Web Browsing

IDN and Areas remaining to be standardized –IDN over SMTP –IDN in MIME Headers –Internationalized user name (Local part of an address, i.e. the name before the ” sign) Discussions have somewhat started at IETF

IDN and Domain Registry Systems IDN Registration Storefront Database management for IDN –Store as Punycode vs Store as UTF IDN over EPP –Object extension approach Add service extension to Domain Object Suitable for use without character equivalence preparations Simple for deployment Announcement of Language-Tag

IDN and Digital Certificates Not much work yet Probably dependant on browser or other Digital Certificates viewers Use of Punycode could be problematic –Perception is reality –User will be confused if displayed name is not easily recognizable with intended name

Other Applications Network tools –NSLookup, etc –Network monitoring tools Customer and other Databases –Storing and using IDNs (automated s, automated web updates etc.) –Search databases (click through links) Mailing Lists Etc.

The Future of IDNs Is there demand for IDNs? Who would use IDNs? Chicken and Egg issue for Registries and Application Providers Does IDN solve all of the user- friendliness of Internet navigation issue?

What the DNS does and does not Domain Names are identifiers Unique and unambiguous to the machine (not necessarily to humans) –E.g. Digit 0 and Character O Domain Names are NOT “ navigation tool ” Domain Names are best only for “ direct navigation ” NOT involving guessing Domain Names function best as an “ address ” –i.e. you don ’ t try to send mail to an address without knowing the exact address and expect it to arrive at the right person

Place for IDNs Local or regional use Intra-company use Personal use International preference may be lowest common denominator: i.e. everyone should be able to type in a particular name Local preference includes culture and heritage Personal use makes most sense to use your native tongue

Summary IDN Standards (RFCs) are published IESG IDN Statement is published ICANN IDN Guidelines are drafted Everything Else remains to be worked out –IRIs and Addresses –IDN over EPP –IDN in WHOIS –IDN in Digital Certificates IDN aware Applications –Browsers and Agents –Database Management Systems –Any application that uses or stores domain names