Domain Names, Internationalization, and

Alternatives

John C KLENSIN

Klensin+cn@jck.com© John C Klensin, 2002

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 importantbut probably biggest change to Internet since deployment

of IP

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

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.

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.

Users and Naming

• Do not know about DNS names

• What they type

• What they transcribe

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

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

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

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.

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

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?

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

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

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

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

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)

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

References: Background reading

• IETF materials– DNS Limitations

draft-klensin-dns-role-03.txt

– The multilayer “dns-search” architecturedraft-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