Transcript Domain Names, Internationalization, and Alternatives

Domain Names,
Internationalization, and
Alternatives
John C KLENSIN
[email protected]
© 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 important
but 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” architecture
draft-klensin-dns-search-04.txt
• References to other documents
– Available from http://www.ietf.org/internetdrafts/draft…
• ICANN and registrar materials
– http://www.icann.org/committees/idn/final-report27jun02.htm