1 / 20

IDN Standards and Implications Kenny Huang Board, PIR huangk@alum.sinica

IDN Standards and Implications Kenny Huang Board, PIR huangk@alum.sinica.edu. 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.

alijah
Télécharger la présentation

IDN Standards and Implications Kenny Huang Board, PIR huangk@alum.sinica

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IDN Standards and ImplicationsKenny HuangBoard, PIRhuangk@alum.sinica.edu

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

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

  4. 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

  5. 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

  6. 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?

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. IDN and Email • 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

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

  14. 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

  15. 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

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

  17. 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?

  18. 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

  19. 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

  20. 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 Email Addresses • IDN over EPP • IDN in WHOIS • IDN in Digital Certificates • IDN aware Applications • Browsers and Email Agents • Database Management Systems • Any application that uses or stores domain names

More Related