1. Domain Names, Internationalization, and Alternatives John C KLENSIN Klensin+cn@jck.com © John C Klensin, 2002

2. Goals For most of us –Use of natural language names in natural ways –Preserve integrity of DNS, I.e., Uniqueness of names Global accessibility of names Hardest problems are in applications and UI –Putting names into databases is almost trivial Internationalization is very important but probably biggest change to Internet since deployment of IP

3. Example Traps Localization is fairly easy, but can –Destroy uniqueness and fragment network –Not work for speakers of language1 working in country2 (or an ISP from there) DNS is very precise – no “near matches” Limited width Side effects, e.g. multilingual Whois Assuming only alternatives lie entirely inside the DNS Web solution – no plan for other applications

4. Localization-specific risks Leakage will always occur, especially with names embedded in running text. If non-global codings are used, interpretation of bit string depends on language/ coding assumptions: –Same name, different codings –Different names, same coding Many opportunities for accidental & deliberate mischief.

5. Humans and their languages Trained people adapt well to artificial systems Untrained people expect natural-looking systems to act naturally People are very sensitive about their languages – what is correct and what isn’t Systems that assume people will adapt by changing lifetime habits will fail.

6. Users and Naming Do not know about DNS names What they type What they transcribe

7. The Web, URLs, and the Internet The Web is not the Internet –Email and messaging –File transfer and sharing –Many other applications, present and future In theory, users within the web environment see and use link names, not URLs –Link names already internationalized –Transcription problem from other media

8. What users want Do What I Mean –Simple references to everything Everything should have a short name Could really make things simple by just saying “site” or “mail address” –Words to mean whatever is convenient More realistically… –This has never worked –We qualify names of people and often places and things

9. DNS Matching Characters, not names or strings No language or script constraints –Joining and ordering restrictions cannot be enforced No way to tell character-sharing languages/ names apart –English mostly like French or Spanish –French partially like Greek or Cyrillic –Han-based characters indistinguishable

10. Success criteria for internationaliztaion Different for registrars/registries and, e.g., users Rendering and keying issues must be addressed realistically. Solution is forever: wrecking the Internet to get a quick solution is a bad tradeoff.

11. The DNS Label Model Network-resource facing, not end-user facing Strict hierarchy Administrative structure, not semantic structure Identifier use –User knows exact string and spelling No transcription issues No transcoding issues –Very restricted list of permitted characters Much like a programming language and its identifiers

12. An Extreme Conclusion about Internationalization No DNS-based solution, alone, will be adequate Directory system with partial, fuzzy, and local matching rules probably needed. “Jack up applications, put directory underneath” (but above DNS) –Different from directory escape from app If need directory anyway, should we add overhead and risk wrecking the DNS?

13. Internationalization: The Character Set Issue Must have a single, “universal” coded character set –No place for language info –No place to identify/ encode different scripts –No place for state information –Unicode/IS10646 is the only candidate To preserve the identifier-integrity of DNS, need analogy to current restrictions

14. The Keyword Alternatives - Versions One name, one site = “direct navigation” or Combinations of term from reserved vocabularies Either version permits –Qualification by country, language, or designated database –Language-specific rules Scaling problems with unique names

15. Conclusion: Naming considered harmful DNS constraints make things more difficult but… Serious problems with any system that –Maps one name onto one location –Has no way to resolve ambiguities among names, even Language or Country constraints

16. The Radical Alternatives: Looking beyond the DNS –The Search Engines Free-text database and automatic indexing Finding what is out there rather than what subject wants found: –E.g., finding site versus finding information about site or owner –Global directory – populated by those who want to be found Still a “white pages” service Structured attribute model (e.g., X.500, LDAP) Faceted, multihierarchical model –Localized directories Support “yellow pages” services Hard to use in a global/interoperable way But may be just the thing for local needs

17. Model implications and questions Can we avoid uniqueness and arbiters? Can we deal properly with languages? How to organize it? How to find servers? How to look things up (this is not primarily about LDAP or CNRP)

18. The futures Continue to try to impose internationalization on DNS –Internet fragmentation –Confusion about “ownership” of names and user confusion Keyword solutions with most of the same constraints –Same problems Working out an “above DNS” model that gives us the flexibility, language and national sensitivity we need

19. References: Background reading IETF materials –DNS Limitations draft-klensin-dns-role-03.txt –The multilayer “dns-search” architecture draft-klensin-dns-search-04.txt References to other documents –Available from http://www.ietf.org/internet- drafts/draft… ICANN and registrar materials –http://www.icann.org/committees/idn/final-report- 27jun02.htm