doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc3467.txt b/doc/rfc/rfc3467.txt
new file mode 100644
index 0000000..37ac7ec
--- /dev/null
+++ b/doc/rfc/rfc3467.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                         J. Klensin
+Request for Comments: 3467                                 February 2003
+Category: Informational
+
+
+                  Role of the Domain Name System (DNS)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document reviews the original function and purpose of the domain
+   name system (DNS).  It contrasts that history with some of the
+   purposes for which the DNS has recently been applied and some of the
+   newer demands being placed upon it or suggested for it.  A framework
+   for an alternative to placing these additional stresses on the DNS is
+   then outlined.  This document and that framework are not a proposed
+   solution, only a strong suggestion that the time has come to begin
+   thinking more broadly about the problems we are encountering and
+   possible approaches to solving them.
+
+Table of Contents
+
+   1.  Introduction and History .....................................  2
+      1.1 Context for DNS Development ...............................  3
+      1.2 Review of the DNS and Its Role as Designed ................  4
+      1.3 The Web and User-visible Domain Names .....................  6
+      1.4 Internet Applications Protocols and Their Evolution .......  7
+   2.  Signs of DNS Overloading .....................................  8
+   3.  Searching, Directories, and the DNS .......................... 12
+      3.1 Overview  ................................................. 12
+      3.2 Some Details and Comments ................................. 14
+   4.  Internationalization ......................................... 15
+      4.1 ASCII Isn't Just Because of English ....................... 16
+      4.2 The "ASCII Encoding" Approaches ........................... 17
+      4.3 "Stringprep" and Its Complexities ......................... 17
+      4.4 The Unicode Stability Problem ............................. 19
+      4.5 Audiences, End Users, and the User Interface Problem ...... 20
+      4.6 Business Cards and Other Natural Uses of Natural Languages. 22
+      4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
+
+
+
+Klensin                      Informational                      [Page 1]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
+   5.  Search-based Systems: The Key Controversies .................. 23
+   6.  Security Considerations ...................................... 24
+   7.  References ................................................... 25
+      7.1 Normative References ...................................... 25
+      7.2 Explanatory and Informative References .................... 25
+   8.  Acknowledgements ............................................. 30
+   9.  Author's Address ............................................. 30
+   10. Full Copyright Statement ..................................... 31
+
+1. Introduction and History
+
+   The DNS was designed as a replacement for the older "host table"
+   system.  Both were intended to provide names for network resources at
+   a more abstract level than network (IP) addresses (see, e.g.,
+   [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]).  In recent years,
+   the DNS has become a database of convenience for the Internet, with
+   many proposals to add new features.  Only some of these proposals
+   have been successful.  Often the main (or only) motivation for using
+   the DNS is because it exists and is widely deployed, not because its
+   existing structure, facilities, and content are appropriate for the
+   particular application of data involved.  This document reviews the
+   history of the DNS, including examination of some of those newer
+   applications.  It then argues that the overloading process is often
+   inappropriate.  Instead, it suggests that the DNS should be
+   supplemented by systems better matched to the intended applications
+   and outlines a framework and rationale for one such system.
+
+   Several of the comments that follow are somewhat revisionist.  Good
+   design and engineering often requires a level of intuition by the
+   designers about things that will be necessary in the future; the
+   reasons for some of these design decisions are not made explicit at
+   the time because no one is able to articulate them.  The discussion
+   below reconstructs some of the decisions about the Internet's primary
+   namespace (the "Class=IN" DNS) in the light of subsequent development
+   and experience.  In addition, the historical reasons for particular
+   decisions about the Internet were often severely underdocumented
+   contemporaneously and, not surprisingly, different participants have
+   different recollections about what happened and what was considered
+   important.  Consequently, the quasi-historical story below is just
+   one story.  There may be (indeed, almost certainly are) other stories
+   about how the DNS evolved to its present state, but those variants do
+   not invalidate the inferences and conclusions.
+
+   This document presumes a general understanding of the terminology of
+   RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
+
+
+
+
+
+Klensin                      Informational                      [Page 2]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+1.1  Context for DNS Development
+
+   During the entire post-startup-period life of the ARPANET and nearly
+   the first decade or so of operation of the Internet, the list of host
+   names and their mapping to and from addresses was maintained in a
+   frequently-updated "host table" [RFC625], [RFC811], [RFC952].  The
+   names themselves were restricted to a subset of ASCII [ASCII] chosen
+   to avoid ambiguities in printed form, to permit interoperation with
+   systems using other character codings (notably EBCDIC), and to avoid
+   the "national use" code positions of ISO 646 [IS646].  These
+   restrictions later became collectively known as the "LDH" rules for
+   "letter-digit-hyphen", the permitted characters.  The table was just
+   a list with a common format that was eventually agreed upon; sites
+   were expected to frequently obtain copies of, and install, new
+   versions.  The host tables themselves were introduced to:
+
+   o  Eliminate the requirement for people to remember host numbers
+      (addresses).  Despite apparent experience to the contrary in the
+      conventional telephone system, numeric numbering systems,
+      including the numeric host number strategy, did not (and do not)
+      work well for more than a (large) handful of hosts.
+
+   o  Provide stability when addresses changed.  Since addresses -- to
+      some degree in the ARPANET and more importantly in the
+      contemporary Internet -- are a function of network topology and
+      routing, they often had to be changed when connectivity or
+      topology changed.  The names could be kept stable even as
+      addresses changed.
+
+   o  Provide the capability to have multiple addresses associated with
+      a given host to reflect different types of connectivity and
+      topology.  Use of names, rather than explicit addresses, avoided
+      the requirement that would otherwise exist for users and other
+      hosts to track these multiple host numbers and addresses and the
+      topological considerations for selecting one over others.
+
+   After several years of using the host table approach, the community
+   concluded that model did not scale adequately and that it would not
+   adequately support new service variations.  A number of discussions
+   and meetings were held which drew several ideas and incomplete
+   proposals together.  The DNS was the result of that effort.  It
+   continued to evolve during the design and initial implementation
+   period, with a number of documents recording the changes (see
+   [RFC819], [RFC830], and [RFC1034]).
+
+
+
+
+
+
+
+Klensin                      Informational                      [Page 3]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The goals for the DNS included:
+
+   o  Preservation of the capabilities of the host table arrangements
+      (especially unique, unambiguous, host names),
+
+   o  Provision for addition of additional services (e.g., the special
+      record types for electronic mail routing which quickly followed
+      introduction of the DNS), and
+
+   o  Creation of a robust, hierarchical, distributed, name lookup
+      system to accomplish the other goals.
+
+   The DNS design also permitted distribution of name administration,
+   rather than requiring that each host be entered into a single,
+   central, table by a central administration.
+
+1.2 Review of the DNS and Its Role as Designed
+
+   The DNS was designed to identify network resources.  Although there
+   was speculation about including, e.g., personal names and email
+   addresses, it was not designed primarily to identify people, brands,
+   etc.  At the same time, the system was designed with the flexibility
+   to accommodate new data types and structures, both through the
+   addition of new record types to the initial "INternet" class, and,
+   potentially, through the introduction of new classes.  Since the
+   appropriate identifiers and content of those future extensions could
+   not be anticipated, the design provided that these fields could
+   contain any (binary) information, not just the restricted text forms
+   of the host table.
+
+   However, the DNS, as it is actually used, is intimately tied to the
+   applications and application protocols that utilize it, often at a
+   fairly low level.
+
+   In particular, despite the ability of the protocols and data
+   structures themselves to accommodate any binary representation, DNS
+   names as used were historically not even unrestricted ASCII, but a
+   very restricted subset of it, a subset that derives from the original
+   host table naming rules.  Selection of that subset was driven in part
+   by human factors considerations, including a desire to eliminate
+   possible ambiguities in an international context.  Hence character
+   codes that had international variations in interpretation were
+   excluded, the underscore character and case distinctions were
+   eliminated as being confusing (in the underscore's case, with the
+   hyphen character) when written or read by people, and so on.  These
+   considerations appear to be very similar to those that resulted in
+   similarly restricted character sets being used as protocol elements
+   in many ITU and ISO protocols (cf. [X29]).
+
+
+
+Klensin                      Informational                      [Page 4]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Another assumption was that there would be a high ratio of physical
+   hosts to second level domains and, more generally, that the system
+   would be deeply hierarchical, with most systems (and names) at the
+   third level or below and a very large percentage of the total names
+   representing physical hosts.  There are domains that follow this
+   model: many university and corporate domains use fairly deep
+   hierarchies, as do a few country-oriented top level domains
+   ("ccTLDs").  Historically, the "US." domain has been an excellent
+   example of the deeply hierarchical approach.  However, by 1998,
+   comparison of several efforts to survey the DNS showed a count of SOA
+   records that approached (and may have passed) the number of distinct
+   hosts.  Looked at differently, we appear to be moving toward a
+   situation in which the number of delegated domains on the Internet is
+   approaching or exceeding the number of hosts, or at least the number
+   of hosts able to provide services to others on the network.  This
+   presumably results from synonyms or aliases that map a great many
+   names onto a smaller number of hosts.  While experience up to this
+   time has shown that the DNS is robust enough -- given contemporary
+   machines as servers and current bandwidth norms -- to be able to
+   continue to operate reasonably well when those historical assumptions
+   are not met (e.g., with a flat, structure under ".COM" containing
+   well over ten million delegated subdomains [COMSIZE]), it is still
+   useful to remember that the system could have been designed to work
+   optimally with a flat structure (and very large zones) rather than a
+   deeply hierarchical one, and was not.
+
+   Similarly, despite some early speculation about entering people's
+   names and email addresses into the DNS directly (e.g., see
+   [RFC1034]), electronic mail addresses in the Internet have preserved
+   the original, pre-DNS, "user (or mailbox) at location" conceptual
+   format rather than a flatter or strictly dot-separated one.
+   Location, in that instance, is a reference to a host. The sole
+   exception, at least in the "IN" class, has been one field of the SOA
+   record.
+
+   Both the DNS architecture itself and the two-level (host name and
+   mailbox name) provisions for email and similar functions (e.g., see
+   the finger protocol [FINGER]), also anticipated a relatively high
+   ratio of users to actual hosts.  Despite the observation in RFC 1034
+   that the DNS was expected to grow to be proportional to the number of
+   users (section 2.3), it has never been clear that the DNS was
+   seriously designed for, or could, scale to the order of magnitude of
+   number of users (or, more recently, products or document objects),
+   rather than that of physical hosts.
+
+   Just as was the case for the host table before it, the DNS provided
+   critical uniqueness for names, and universal accessibility to them,
+   as part of overall "single internet" and "end to end" models (cf.
+
+
+
+Klensin                      Informational                      [Page 5]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [RFC2826]).  However, there are many signs that, as new uses evolved
+   and original assumptions were abused (if not violated outright), the
+   system was being stretched to, or beyond, its practical limits.
+
+   The original design effort that led to the DNS included examination
+   of the directory technologies available at the time.  The design
+   group concluded that the DNS design, with its simplifying assumptions
+   and restricted capabilities, would be feasible to deploy and make
+   adequately robust, which the more comprehensive directory approaches
+   were not.  At the same time, some of the participants feared that the
+   limitations might cause future problems; this document essentially
+   takes the position that they were probably correct.  On the other
+   hand, directory technology and implementations have evolved
+   significantly in the ensuing years: it may be time to revisit the
+   assumptions, either in the context of the two- (or more) level
+   mechanism contemplated by the rest of this document or, even more
+   radically, as a path toward a DNS replacement.
+
+1.3 The Web and User-visible Domain Names
+
+   From the standpoint of the integrity of the domain name system -- and
+   scaling of the Internet, including optimal accessibility to content
+   -- the web design decision to use "A record" domain names directly in
+   URLs, rather than some system of indirection, has proven to be a
+   serious mistake in several respects.  Convenience of typing, and the
+   desire to make domain names out of easily-remembered product names,
+   has led to a flattening of the DNS, with many people now perceiving
+   that second-level names under COM (or in some countries, second- or
+   third-level names under the relevant ccTLD) are all that is
+   meaningful.  This perception has been reinforced by some domain name
+   registrars [REGISTRAR] who have been anxious to "sell" additional
+   names.  And, of course, the perception that one needed a second-level
+   (or even top-level) domain per product, rather than having names
+   associated with a (usually organizational) collection of network
+   resources, has led to a rapid acceleration in the number of names
+   being registered.  That acceleration has, in turn, clearly benefited
+   registrars charging on a per-name basis, "cybersquatters", and others
+   in the business of "selling" names, but it has not obviously
+   benefited the Internet as a whole.
+
+   This emphasis on second-level domain names has also created a problem
+   for the trademark community.  Since the Internet is international,
+   and names are being populated in a flat and unqualified space,
+   similarly-named entities are in conflict even if there would
+   ordinarily be no chance of confusing them in the marketplace.  The
+   problem appears to be unsolvable except by a choice between draconian
+   measures.  These might include significant changes to the legislation
+   and conventions that govern disputes over "names" and "marks".  Or
+
+
+
+Klensin                      Informational                      [Page 6]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   they might result in a situation in which the "rights" to a name are
+   typically not settled using the subtle and traditional product (or
+   industry) type and geopolitical scope rules of the trademark system.
+   Instead they have depended largely on political or economic power,
+   e.g., the organization with the greatest resources to invest in
+   defending (or attacking) names will ultimately win out.  The latter
+   raises not only important issues of equity, but also the risk of
+   backlash as the numerous small players are forced to relinquish names
+   they find attractive and to adopt less-desirable naming conventions.
+
+   Independent of these sociopolitical problems, content distribution
+   issues have made it clear that it should be possible for an
+   organization to have copies of data it wishes to make available
+   distributed around the network, with a user who asks for the
+   information by name getting the topologically-closest copy.  This is
+   not possible with simple, as-designed, use of the DNS: DNS names
+   identify target resources or, in the case of email "MX" records, a
+   preferentially-ordered list of resources "closest" to a target (not
+   to the source/user).  Several technologies (and, in some cases,
+   corresponding business models) have arisen to work around these
+   problems, including intercepting and altering DNS requests so as to
+   point to other locations.
+
+   Additional implications are still being discovered and evaluated.
+
+   Approaches that involve interception of DNS queries and rewriting of
+   DNS names (or otherwise altering the resolution process based on the
+   topological location of the user) seem, however, to risk disrupting
+   end-to-end applications in the general case and raise many of the
+   issues discussed by the IAB in [IAB-OPES].  These problems occur even
+   if the rewriting machinery is accompanied by additional workarounds
+   for particular applications.  For example, security associations and
+   applications that need to identify "the same host" often run into
+   problems if DNS names or other references are changed in the network
+   without participation of the applications that are trying to invoke
+   the associated services.
+
+1.4 Internet Applications Protocols and Their Evolution
+
+   At the applications level, few of the protocols in active,
+   widespread, use on the Internet reflect either contemporary knowledge
+   in computer science or human factors or experience accumulated
+   through deployment and use.  Instead, protocols tend to be deployed
+   at a just-past-prototype level, typically including the types of
+   expedient compromises typical with prototypes.  If they prove useful,
+   the nature of the network permits very rapid dissemination (i.e.,
+   they fill a vacuum, even if a vacuum that no one previously knew
+   existed).  But, once the vacuum is filled, the installed base
+
+
+
+Klensin                      Informational                      [Page 7]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   provides its own inertia: unless the design is so seriously faulty as
+   to prevent effective use (or there is a widely-perceived sense of
+   impending disaster unless the protocol is replaced), future
+   developments must maintain backward compatibility and workarounds for
+   problematic characteristics rather than benefiting from redesign in
+   the light of experience.  Applications that are "almost good enough"
+   prevent development and deployment of high-quality replacements.
+
+   The DNS is both an illustration of, and an exception to, parts of
+   this pessimistic interpretation. It was a second-generation
+   development, with the host table system being seen as at the end of
+   its useful life.  There was a serious attempt made to reflect the
+   computing state of the art at the time.  However, deployment was much
+   slower than expected (and very painful for many sites) and some fixed
+   (although relaxed several times) deadlines from a central network
+   administration were necessary for deployment to occur at all.
+   Replacing it now, in order to add functionality, while it continues
+   to perform its core functions at least reasonably well, would
+   presumably be extremely difficult.
+
+   There are many, perhaps obvious, examples of this.  Despite many
+   known deficiencies and weaknesses of definition, the "finger" and
+   "whois" [WHOIS] protocols have not been replaced (despite many
+   efforts to update or replace the latter [WHOIS-UPDATE]).  The Telnet
+   protocol and its many options drove out the SUPDUP [RFC734] one,
+   which was arguably much better designed for a diverse collection of
+   network hosts.  A number of efforts to replace the email or file
+   transfer protocols with models which their advocates considered much
+   better have failed.  And, more recently and below the applications
+   level, there is some reason to believe that this resistance to change
+   has been one of the factors impeding IPv6 deployment.
+
+2. Signs of DNS Overloading
+
+   Parts of the historical discussion above identify areas in which the
+   DNS has become overloaded (semantically if not in the mechanical
+   ability to resolve names).  Despite this overloading, it appears that
+   DNS performance and reliability are still within an acceptable range:
+   there is little evidence of serious performance degradation.  Recent
+   proposals and mechanisms to better respond to overloading and scaling
+   issues have all focused on patching or working around limitations
+   that develop when the DNS is utilized for out-of-design functions,
+   rather than on dramatic rethinking of either DNS design or those
+   uses.  The number of these issues that have arisen at much the same
+   time may argue for just that type of rethinking, and not just for
+   adding complexity and attempting to incrementally alter the design
+   (see, for example, the discussion of simplicity in section 2 of
+   [RFC3439]).
+
+
+
+Klensin                      Informational                      [Page 8]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   For example:
+
+   o  While technical approaches such as larger and higher-powered
+      servers and more bandwidth, and legal/political mechanisms such as
+      dispute resolution policies, have arguably kept the problems from
+      becoming critical, the DNS has not proven adequately responsive to
+      business and individual needs to describe or identify things (such
+      as product names and names of individuals) other than strict
+      network resources.
+
+   o  While stacks have been modified to better handle multiple
+      addresses on a physical interface and some protocols have been
+      extended to include DNS names for determining context, the DNS
+      does not deal especially well with many names associated with a
+      given host (e.g., web hosting facilities with multiple domains on
+      a server).
+
+   o  Efforts to add names deriving from languages or character sets
+      based on other than simple ASCII and English-like names (see
+      below), or even to utilize complex company or product names
+      without the use of hierarchy, have created apparent requirements
+      for names (labels) that are over 63 octets long.  This requirement
+      will undoubtedly increase over time; while there are workarounds
+      to accommodate longer names, they impose their own restrictions
+      and cause their own problems.
+
+   o  Increasing commercialization of the Internet, and visibility of
+      domain names that are assumed to match names of companies or
+      products, has turned the DNS and DNS names into a trademark
+      battleground.  The traditional trademark system in (at least) most
+      countries makes careful distinctions about fields of
+      applicability.  When the space is flattened, without
+      differentiation by either geography or industry sector, not only
+      are there likely conflicts between "Joe's Pizza" (of Boston) and
+      "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
+      Repair" (of Los Angeles).  All three would like to control
+      "Joes.com" (and would prefer, if it were permitted by DNS naming
+      rules, to also spell it as "Joe's.com" and have both resolve the
+      same way) and may claim trademark rights to do so, even though
+      conflict or confusion would not occur with traditional trademark
+      principles.
+
+   o  Many organizations wish to have different web sites under the same
+      URL and domain name.  Sometimes this is to create local variations
+      -- the Widget Company might want to present different material to
+      a UK user relative to a US one -- and sometimes it is to provide
+      higher performance by supplying information from the server
+      topologically closest to the user.  If the name resolution
+
+
+
+Klensin                      Informational                      [Page 9]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      mechanism is expected to provide this functionality, there are
+      three possible models (which might be combined):
+
+      -  supply information about multiple sites (or locations or
+         references).  Those sites would, in turn, provide information
+         associated with the name and sufficient site-specific
+         attributes to permit the application to make a sensible choice
+         of destination, or
+
+      -  accept client-site attributes and utilize them in the search
+         process, or
+
+      -  return different answers based on the location or identity of
+         the requestor.
+
+   While there are some tricks that can provide partial simulations of
+   these types of function, DNS responses cannot be reliably conditioned
+   in this way.
+
+   These, and similar, issues of performance or content choices can, of
+   course, be thought of as not involving the DNS at all.  For example,
+   the commonly-cited alternate approach of coupling these issues to
+   HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
+   connection first be opened to some "common" or "primary" host so that
+   preferences can be negotiated and then the client redirected or sent
+   alternate data.  At least from the standpoint of improving
+   performance by accessing a "closer" location, both initially and
+   thereafter, this approach sacrifices the desired result before the
+   client initiates any action.  It could even be argued that some of
+   the characteristics of common content negotiation approaches are
+   workarounds for the non-optimal use of the DNS in web URLs.
+
+   o  Many existing and proposed systems for "finding things on the
+      Internet" require a true search capability in which near matches
+      can be reported to the user (or to some user agent with an
+      appropriate rule-set) and to which queries may be ambiguous or
+      fuzzy.  The DNS, by contrast, can accommodate only one set of
+      (quite rigid) matching rules.  Proposals to permit different rules
+      in different localities (e.g., matching rules that are TLD- or
+      zone-specific) help to identify the problem.  But they cannot be
+      applied directly to the DNS without either abandoning the desired
+      level of flexibility or isolating different parts of the Internet
+      from each other (or both).  Fuzzy or ambiguous searches are
+      desirable for resolution of names that might have spelling
+      variations and for names that can be resolved into different sets
+      of glyphs depending on context.  Especially when
+      internationalization is considered, variant name problems go
+      beyond simple differences in representation of a character or
+
+
+
+Klensin                      Informational                     [Page 10]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      ordering of a string.  Instead, avoiding user astonishment and
+      confusion requires consideration of relationships such as
+      languages that can be written with different alphabets, Kanji-
+      Hiragana relationships, Simplified and Traditional Chinese, etc.
+      See [Seng] for a discussion and suggestions for addressing a
+      subset of these issues in the context of characters based on
+      Chinese ones.  But that document essentially illustrates the
+      difficulty of providing the type of flexible matching that would
+      be anticipated by users; instead, it tries to protect against the
+      worst types of confusion (and opportunities for fraud).
+
+   o  The historical DNS, and applications that make assumptions about
+      how it works, impose significant risk (or forces technical kludges
+      and consequent odd restrictions), when one considers adding
+      mechanisms for use with various multi-character-set and
+      multilingual "internationalization" systems.  See the IAB's
+      discussion of some of these issues [RFC2825] for more information.
+
+   o  In order to provide proper functionality to the Internet, the DNS
+      must have a single unique root (the IAB provides more discussion
+      of this issue [RFC2826]).  There are many desires for local
+      treatment of names or character sets that cannot be accommodated
+      without either multiple roots (e.g., a separate root for
+      multilingual names, proposed at various times by MINC [MINC] and
+      others), or mechanisms that would have similar effects in terms of
+      Internet fragmentation and isolation.
+
+   o  For some purposes, it is desirable to be able to search not only
+      an index entry (labels or fully-qualified names in the DNS case),
+      but their values or targets (DNS data).  One might, for example,
+      want to locate all of the host (and virtual host) names which
+      cause mail to be directed to a given server via MX records.  The
+      DNS does not support this capability (see the discussion in
+      [IQUERY]) and it can be simulated only by extracting all of the
+      relevant records (perhaps by zone transfer if the source permits
+      doing so, but that permission is becoming less frequently
+      available) and then searching a file built from those records.
+
+   o  Finally, as additional types of personal or identifying
+      information are added to the DNS, issues arise with protection of
+      that information.  There are increasing calls to make different
+      information available based on the credentials and authorization
+      of the source of the inquiry.  As with information keyed to site
+      locations or proximity (as discussed above), the DNS protocols
+      make providing these differentiated services quite difficult if
+      not impossible.
+
+
+
+
+
+Klensin                      Informational                     [Page 11]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   In each of these cases, it is, or might be, possible to devise ways
+   to trick the DNS system into supporting mechanisms that were not
+   designed into it.  Several ingenious solutions have been proposed in
+   many of these areas already, and some have been deployed into the
+   marketplace with some success.  But the price of each of these
+   changes is added complexity and, with it, added risk of unexpected
+   and destabilizing problems.
+
+   Several of the above problems are addressed well by a good directory
+   system (supported by the LDAP protocol or some protocol more
+   precisely suited to these specific applications) or searching
+   environment (such as common web search engines) although not by the
+   DNS.  Given the difficulty of deploying new applications discussed
+   above, an important question is whether the tricks and kludges are
+   bad enough, or will become bad enough as usage grows, that new
+   solutions are needed and can be deployed.
+
+3. Searching, Directories, and the DNS
+
+3.1 Overview
+
+   The constraints of the DNS and the discussion above suggest the
+   introduction of an intermediate protocol mechanism, referred to below
+   as a "search layer" or "searchable system".  The terms "directory"
+   and "directory system" are used interchangeably with "searchable
+   system" in this document, although the latter is far more precise.
+   Search layer proposals would use a two (or more) stage lookup, not
+   unlike several of the proposals for internationalized names in the
+   DNS (see section 4), but all operations but the final one would
+   involve searching other systems, rather than looking up identifiers
+   in the DNS itself.  As explained below, this would permit relaxation
+   of several constraints, leading to a more capable and comprehensive
+   overall system.
+
+   Ultimately, many of the issues with domain names arise as the result
+   of efforts to use the DNS as a directory.  While, at the time this
+   document was written, sufficient pressure or demand had not occurred
+   to justify a change, it was already quite clear that, as a directory
+   system, the DNS is a good deal less than ideal.  This document
+   suggests that there actually is a requirement for a directory system,
+   and that the right solution to a searchable system requirement is a
+   searchable system, not a series of DNS patches, kludges, or
+   workarounds.
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 12]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The following points illustrate particular aspects of this
+   conclusion.
+
+   o  A directory system would not require imposition of particular
+      length limits on names.
+
+   o  A directory system could permit explicit association of
+      attributes, e.g., language and country, with a name, without
+      having to utilize trick encodings to incorporate that information
+      in DNS labels (or creating artificial hierarchy for doing so).
+
+   o  There is considerable experience (albeit not much of it very
+      successful) in doing fuzzy and "sonex" (similar-sounding) matching
+      in directory systems.  Moreover, it is plausible to think about
+      different matching rules for different areas and sets of names so
+      that these can be adapted to local cultural requirements.
+      Specifically, it might be possible to have a single form of a name
+      in a directory, but to have great flexibility about what queries
+      matched that name (and even have different variations in different
+      areas).  Of course, the more flexibility that a system provides,
+      the greater the possibility of real or imagined trademark
+      conflicts.  But the opportunity would exist to design a directory
+      structure that dealt with those issues in an intelligent way,
+      while DNS constraints almost certainly make a general and
+      equitable DNS-only solution impossible.
+
+   o  If a directory system is used to translate to DNS names, and then
+      DNS names are looked up in the normal fashion, it may be possible
+      to relax several of the constraints that have been traditional
+      (and perhaps necessary) with the DNS.  For example, reverse-
+      mapping of addresses to directory names may not be a requirement
+      even if mapping of addresses to DNS names continues to be, since
+      the DNS name(s) would (continue to) uniquely identify the host.
+
+   o  Solutions to multilingual transcription problems that are common
+      in "normal life" (e.g., two-sided business cards to be sure that
+      recipients trying to contact a person can access romanized
+      spellings and numbers if the original language is not
+      comprehensible to them) can be easily handled in a directory
+      system by inserting both sets of entries.
+
+   o  A directory system could be designed that would return, not a
+      single name, but a set of names paired with network-locational
+      information or other context-establishing attributes.  This type
+      of information might be of considerable use in resolving the
+      "nearest (or best) server for a particular named resource"
+
+
+
+
+
+Klensin                      Informational                     [Page 13]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      problems that are a significant concern for organizations hosting
+      web and other sites that are accessed from a wide range of
+      locations and subnets.
+
+   o  Names bound to countries and languages might help to manage
+      trademark realities, while, as discussed in section 1.3 above, use
+      of the DNS in trademark-significant contexts tends to require
+      worldwide "flattening" of the trademark system.
+
+   Many of these issues are a consequence of another property of the
+   DNS:  names must be unique across the Internet.  The need to have a
+   system of unique identifiers is fairly obvious (see [RFC2826]).
+   However, if that requirement were to be eliminated in a search or
+   directory system that was visible to users instead of the DNS, many
+   difficult problems -- of both an engineering and a policy nature --
+   would be likely to vanish.
+
+3.2 Some Details and Comments
+
+   Almost any internationalization proposal for names that are in, or
+   map into, the DNS will require changing DNS resolver API calls
+   ("gethostbyname" or equivalent), or adding some pre-resolution
+   preparation mechanism, in almost all Internet applications -- whether
+   to cause the API to take a different character set (no matter how it
+   is then mapped into the bits used in the DNS or another system), to
+   accept or return more arguments with qualifying or identifying
+   information, or otherwise.  Once applications must be opened to make
+   such changes, it is a relatively small matter to switch from calling
+   into the DNS to calling a directory service and then the DNS (in many
+   situations, both actions could be accomplished in a single API call).
+
+   A directory approach can be consistent both with "flat" models and
+   multi-attribute ones.  The DNS requires strict hierarchies, limiting
+   its ability to differentiate among names by their properties.  By
+   contrast, modern directories can utilize independently-searched
+   attributes and other structured schema to provide flexibilities not
+   present in a strictly hierarchical system.
+
+   There is a strong historical argument for a single directory
+   structure (implying a need for mechanisms for registration,
+   delegation, etc.).  But a single structure is not a strict
+   requirement, especially if in-depth case analysis and design work
+   leads to the conclusion that reverse-mapping to directory names is
+   not a requirement (see section 5).  If a single structure is not
+   needed, then, unlike the DNS, there would be no requirement for a
+   global organization to authorize or delegate operation of portions of
+   the structure.
+
+
+
+
+Klensin                      Informational                     [Page 14]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The "no single structure" concept could be taken further by moving
+   away from simple "names" in favor of, e.g., multiattribute,
+   multihierarchical, faceted systems in which most of the facets use
+   restricted vocabularies.  (These terms are fairly standard in the
+   information retrieval and classification system literature, see,
+   e.g., [IS5127].)  Such systems could be designed to avoid the need
+   for procedures to ensure uniqueness across, or even within, providers
+   and databases of the faceted entities for which the search is to be
+   performed.  (See [DNS-Search] for further discussion.)
+
+   While the discussion above includes very general comments about
+   attributes, it appears that only a very small number of attributes
+   would be needed.  The list would almost certainly include country and
+   language for internationalization purposes.  It might require
+   "charset" if we cannot agree on a character set and encoding,
+   although there are strong arguments for simply using ISO 10646 (also
+   known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
+   [IS10646] coding in interchange.  Trademark issues might motivate
+   "commercial" and "non-commercial" (or other) attributes if they would
+   be helpful in bypassing trademark problems.  And applications to
+   resource location, such as those contemplated for Uniform Resource
+   Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
+   Protocol [RFC2608], might argue for a few other attributes (as
+   outlined above).
+
+4.  Internationalization
+
+   Much of the thinking underlying this document was driven by
+   considerations of internationalizing the DNS or, more specifically,
+   providing access to the functions of the DNS from languages and
+   naming systems that cannot be accurately expressed in the traditional
+   DNS subset of ASCII.  Much of the relevant work was done in the
+   IETF's "Internationalized Domain Names" Working Group (IDN-WG),
+   although this document also draws on extensive parallel discussions
+   in other forums.  This section contains an evaluation of what was
+   learned as an "internationalized DNS" or "multilingual DNS" was
+   explored and suggests future steps based on that evaluation.
+
+   When the IDN-WG was initiated, it was obvious to several of the
+   participants that its first important task was an undocumented one:
+   to increase the understanding of the complexities of the problem
+   sufficiently that naive solutions could be rejected and people could
+   go to work on the harder problems.  The IDN-WG clearly accomplished
+   that task. The beliefs that the problems were simple, and in the
+   corresponding simplistic approaches and their promises of quick and
+   painless deployment, effectively disappeared as the WG's efforts
+   matured.
+
+
+
+
+Klensin                      Informational                     [Page 15]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Some of the lessons learned from increased understanding and the
+   dissipation of naive beliefs should be taken as cautions by the wider
+   community: the problems are not simple. Specifically, extracting
+   small elements for solution rather than looking at whole systems, may
+   result in obscuring the problems but not solving any problem that is
+   worth the trouble.
+
+4.1 ASCII Isn't Just Because of English
+
+   The hostname rules chosen in the mid-70s weren't just "ASCII because
+   English uses ASCII", although that was a starting point.  We have
+   discovered that almost every other script (and even ASCII if we
+   permit the rest of the characters specified in the ISO 646
+   International Reference Version) is more complex than hostname-
+   restricted-ASCII (the "LDH" form, see section 1.1).  And ASCII isn't
+   sufficient to completely represent English -- there are several words
+   in the language that are correctly spelled only with characters or
+   diacritical marks that do not appear in ASCII.  With a broader
+   selection of scripts, in some examples, case mapping works from one
+   case to the other but is not reversible.  In others, there are
+   conventions about alternate ways to represent characters (in the
+   language, not [only] in character coding) that work most of the time,
+   but not always.  And there are issues in coding, with Unicode/10646
+   providing different ways to represent the same character
+   ("character", rather than "glyph", is used deliberately here).  And,
+   in still others, there are questions as to whether two glyphs
+   "match", which may be a distance-function question, not one with a
+   binary answer.  The IETF approach to these problems is to require
+   pre-matching canonicalization (see the "stringprep" discussion
+   below).
+
+   The IETF has resisted the temptations to either try to specify an
+   entirely new coded character set, or to pick and choose Unicode/10646
+   characters on a per-character basis rather than by using well-defined
+   blocks.  While it may appear that a character set designed to meet
+   Internet-specific needs would be very attractive, the IETF has never
+   had the expertise, resources, and representation from critically-
+   important communities to actually take on that job.  Perhaps more
+   important, a new effort might have chosen to make some of the many
+   complex tradeoffs differently than the Unicode committee did,
+   producing a code with somewhat different characteristics.  But there
+   is no evidence that doing so would produce a code with fewer problems
+   and side-effects.  It is much more likely that making tradeoffs
+   differently would simply result in a different set of problems, which
+   would be equally or more difficult.
+
+
+
+
+
+
+Klensin                      Informational                     [Page 16]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+4.2 The "ASCII Encoding" Approaches
+
+   While the DNS can handle arbitrary binary strings without known
+   internal problems (see [RFC2181]), some restrictions are imposed by
+   the requirement that text be interpreted in a case-independent way
+   ([RFC1034], [RFC1035]).  More important, most internet applications
+   assume the hostname-restricted "LDH" syntax that is specified in the
+   host table RFCs and as "prudent" in RFC 1035.  If those assumptions
+   are not met, many conforming implementations of those applications
+   may exhibit behavior that would surprise implementors and users.  To
+   avoid these potential problems, IETF internationalization work has
+   focused on "ASCII-Compatible Encodings" (ACE).  These encodings
+   preserve the LDH conventions in the DNS itself.  Implementations of
+   applications that have not been upgraded utilize the encoded forms,
+   while newer ones can be written to recognize the special codings and
+   map them into non-ASCII characters. These approaches are, however,
+   not problem-free even if human interface issues are ignored.  Among
+   other issues, they rely on what is ultimately a heuristic to
+   determine whether a DNS label is to be considered as an
+   internationalized name (i.e., encoded Unicode) or interpreted as an
+   actual LDH name in its own right.  And, while all determinations of
+   whether a particular query matches a stored object are traditionally
+   made by DNS servers, the ACE systems, when combined with the
+   complexities of international scripts and names, require that much of
+   the matching work be separated into a separate, client-side,
+   canonicalization or "preparation" process before the DNS matching
+   mechanisms are invoked [STRINGPREP].
+
+4.3 "Stringprep" and Its Complexities
+
+   As outlined above, the model for avoiding problems associated with
+   putting non-ASCII names in the DNS and elsewhere evolved into the
+   principle that strings are to be placed into the DNS only after being
+   passed through a string preparation function that eliminates or
+   rejects spurious character codes, maps some characters onto others,
+   performs some sequence canonicalization, and generally creates forms
+   that can be accurately compared.  The impact of this process on
+   hostname-restricted ASCII (i.e., "LDH") strings is trivial and
+   essentially adds only overhead.  For other scripts, the impact is, of
+   necessity, quite significant.
+
+   Although the general notion underlying stringprep is simple, the many
+   details are quite subtle and the associated tradeoffs are complex. A
+   design team worked on it for months, with considerable effort placed
+   into clarifying and fine-tuning the protocol and tables.  Despite
+   general agreement that the IETF would avoid getting into the business
+   of defining character sets, character codings, and the associated
+   conventions, the group several times considered and rejected special
+
+
+
+Klensin                      Informational                     [Page 17]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   treatment of code positions to more nearly match the distinctions
+   made by Unicode with user perceptions about similarities and
+   differences between characters.  But there were intense temptations
+   (and pressures) to incorporate language-specific or country-specific
+   rules.  Those temptations, even when resisted, were indicative of
+   parts of the ongoing controversy or of the basic unsuitability of the
+   DNS for fully internationalized names that are visible,
+   comprehensible, and predictable for end users.
+
+   There have also been controversies about how far one should go in
+   these processes of preparation and transformation and, ultimately,
+   about the validity of various analogies.  For example, each of the
+   following operations has been claimed to be similar to case-mapping
+   in ASCII:
+
+   o  stripping of vowels in Arabic or Hebrew
+
+   o  matching of "look-alike" characters such as upper-case Alpha in
+      Greek and upper-case A in Roman-based alphabets
+
+   o  matching of Traditional and Simplified Chinese characters that
+      represent the same words,
+
+   o  matching of Serbo-Croatian words whether written in Roman-derived
+      or Cyrillic characters
+
+   A decision to support any of these operations would have implications
+   for other scripts or languages and would increase the overall
+   complexity of the process.  For example, unless language-specific
+   information is somehow available, performing matching between
+   Traditional and Simplified Chinese has impacts on Japanese and Korean
+   uses of the same "traditional" characters (e.g., it would not be
+   appropriate to map Kanji into Simplified Chinese).
+
+   Even were the IDN-WG's other work to have been abandoned completely
+   or if it were to fail in the marketplace, the stringprep and nameprep
+   work will continue to be extremely useful, both in identifying issues
+   and problem code points and in providing a reasonable set of basic
+   rules.  Where problems remain, they are arguably not with nameprep,
+   but with the DNS-imposed requirement that its results, as with all
+   other parts of the matching and comparison process, yield a binary
+   "match or no match" answer, rather than, e.g., a value on a
+   similarity scale that can be evaluated by the user or by user-driven
+   heuristic functions.
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 18]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+4.4 The Unicode Stability Problem
+
+   ISO 10646 basically defines only code points, and not rules for using
+   or comparing the characters.  This is part of a long-standing
+   tradition with the work of what is now ISO/IEC JTC1/SC2: they have
+   performed code point assignments and have typically treated the ways
+   in which characters are used as beyond their scope.  Consequently,
+   they have not dealt effectively with the broader range of
+   internationalization issues.  By contrast, the Unicode Technical
+   Committee (UTC) has defined, in annexes and technical reports (see,
+   e.g., [UTR15]), some additional rules for canonicalization and
+   comparison.  Many of those rules and conventions have been factored
+   into the "stringprep" and "nameprep" work, but it is not
+   straightforward to make or define them in a fashion that is
+   sufficiently precise and permanent to be relied on by the DNS.
+
+   Perhaps more important, the discussions leading to nameprep also
+   identified several areas in which the UTC definitions are inadequate,
+   at least without additional information, to make matching precise and
+   unambiguous.  In some of these cases, the Unicode Standard permits
+   several alternate approaches, none of which are an exact and obvious
+   match to DNS needs.  That has left these sensitive choices up to
+   IETF, which lacks sufficient in-depth expertise, much less any
+   mechanism for deciding to optimize one language at the expense of
+   another.
+
+   For example, it is tempting to define some rules on the basis of
+   membership in particular scripts, or for punctuation characters, but
+   there is no precise definition of what characters belong to which
+   script or which ones are, or are not, punctuation.  The existence of
+   these areas of vagueness raises two issues: whether trying to do
+   precise matching at the character set level is actually possible
+   (addressed below) and whether driving toward more precision could
+   create issues that cause instability in the implementation and
+   resolution models for the DNS.
+
+   The Unicode definition also evolves.  Version 3.2 appeared shortly
+   after work on this document was initiated.  It added some characters
+   and functionality and included a few minor incompatible code point
+   changes.  IETF has secured an agreement about constraints on future
+   changes, but it remains to be seen how that agreement will work out
+   in practice.  The prognosis actually appears poor at this stage,
+   since UTC chose to ballot a recent possible change which should have
+   been prohibited by the agreement (the outcome of the ballot is not
+   relevant, only that the ballot was issued rather than having the
+   result be a foregone conclusion).  However, some members of the
+   community consider some of the changes between Unicode 3.0 and 3.1
+   and between 3.1 and 3.2, as well as this recent ballot, to be
+
+
+
+Klensin                      Informational                     [Page 19]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   evidence of instability and that these instabilities are better
+   handled in a system that can be more flexible about handling of
+   characters, scripts, and ancillary information than the DNS.
+
+   In addition, because the systems implications of internationalization
+   are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
+   those issues to its SC22/WG20 (the Internationalization working group
+   within the subcommittee that deals with programming languages,
+   systems, and environments).  WG20 has historically dealt with
+   internationalization issues thoughtfully and in depth, but its status
+   has several times been in doubt in recent years.  However, assignment
+   of these matters to WG20 increases the risk of eventual ISO
+   internationalization standards that specify different behavior than
+   the UTC specifications.
+
+4.5 Audiences, End Users, and the User Interface Problem
+
+   Part of what has "caused" the DNS internationalization problem, as
+   well as the DNS trademark problem and several others, is that we have
+   stopped thinking about "identifiers for objects" -- which normal
+   people are not expected to see -- and started thinking about "names"
+   -- strings that are expected not only to be readable, but to have
+   linguistically-sensible and culturally-dependent meaning to non-
+   specialist users.
+
+   Within the IETF, the IDN-WG, and sometimes other groups, avoided
+   addressing the implications of that transition by taking "outside our
+   scope -- someone else's problem" approaches or by suggesting that
+   people will just become accustomed to whatever conventions are
+   adopted.  The realities of user and vendor behavior suggest that
+   these approaches will not serve the Internet community well in the
+   long term:
+
+   o  If we want to make it a problem in a different part of the user
+      interface structure, we need to figure out where it goes in order
+      to have proof of concept of our solution.  Unlike vendors whose
+      sole [business] model is the selling or registering of names, the
+      IETF must produce solutions that actually work, in the
+      applications context as seen by the end user.
+
+   o  The principle that "they will get used to our conventions and
+      adapt" is fine if we are writing rules for programming languages
+      or an API.  But the conventions under discussion are not part of a
+      semi-mathematical system, they are deeply ingrained in culture.
+      No matter how often an English-speaking American is told that the
+      Internet requires that the correct spelling of "colour" be used,
+      he or she isn't going to be convinced. Getting a French-speaker in
+      Lyon to use exactly the same lexical conventions as a French-
+
+
+
+Klensin                      Informational                     [Page 20]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      speaker in Quebec in order to accommodate the decisions of the
+      IETF or of a registrar or registry is just not likely.  "Montreal"
+      is either a misspelling or an anglicization of a similar word with
+      an acute accent mark over the "e" (i.e., using the Unicode
+      character U+00E9 or one of its equivalents). But global agreement
+      on a rule that will determine whether the two forms should match
+      -- and that won't astonish end users and speakers of one language
+      or the other -- is as unlikely as agreement on whether
+      "misspelling" or "anglicization" is the greater travesty.
+
+   More generally, it is not clear that the outcome of any conceivable
+   nameprep-like process is going to be good enough for practical,
+   user-level, use.  In the use of human languages by humans, there are
+   many cases in which things that do not match are nonetheless
+   interpreted as matching.  The Norwegian/Danish character that appears
+   in U+00F8 (visually, a lower case 'o' overstruck with a forward
+   slash) and the "o-umlaut" German character that appears in U+00F6
+   (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
+   different and no matching program should yield an "equal" comparison.
+   But they are more similar to each other than either of them is to,
+   e.g., "e".  Humans are able to mentally make the correction in
+   context, and do so easily, and they can be surprised if computers
+   cannot do so.  Worse, there is a Swedish character whose appearance
+   is identical to the German o-umlaut, and which shares code point
+   U+00F6, but that, if the languages are known and the sounds of the
+   letters or meanings of words including the character are considered,
+   actually should match the Norwegian/Danish use of U+00F8.
+
+   This text uses examples in Roman scripts because it is being written
+   in English and those examples are relatively easy to render.  But one
+   of the important lessons of the discussions about domain name
+   internationalization in recent years is that problems similar to
+   those described above exist in almost every language and script.
+   Each one has its idiosyncrasies, and each set of idiosyncracies is
+   tied to common usage and cultural issues that are very familiar in
+   the relevant group, and often deeply held as cultural values.  As
+   long as a schoolchild in the US can get a bad grade on a spelling
+   test for using a perfectly valid British spelling, or one in France
+   or Germany can get a poor grade for leaving off a diacritical mark,
+   there are issues with the relevant language.  Similarly, if children
+   in Egypt or Israel are taught that it is acceptable to write a word
+   with or without vowels or stress marks, but that, if those marks are
+   included, they must be the correct ones, or a user in Korea is
+   potentially offended or astonished by out-of-order sequences of Jamo,
+   systems based on character-at-a-time processing and simplistic
+   matching, with no contextual information, are not going to satisfy
+   user needs.
+
+
+
+
+Klensin                      Informational                     [Page 21]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Users are demanding solutions that deal with language and culture.
+   Systems of identifier symbol-strings that serve specialists or
+   computers are, at best, a solution to a rather different (and, at the
+   time this document was written, somewhat ill-defined), problem.  The
+   recent efforts have made it ever more clear that, if we ignore the
+   distinction between the user requirements and narrowly-defined
+   identifiers, we are solving an insufficient problem.  And,
+   conversely, the approaches that have been proposed to approximate
+   solutions to the user requirement may be far more complex than simple
+   identifiers require.
+
+4.6 Business Cards and Other Natural Uses of Natural Languages
+
+   Over the last few centuries, local conventions have been established
+   in various parts of the world for dealing with multilingual
+   situations.  It may be helpful to examine some of these.  For
+   example, if one visits a country where the language is different from
+   ones own, business cards are often printed on two sides, one side in
+   each language.  The conventions are not completely consistent and the
+   technique assumes that recipients will be tolerant. Translations of
+   names or places are attempted in some situations and transliterations
+   in others.  Since it is widely understood that exact translations or
+   transliterations are often not possible, people typically smile at
+   errors, appreciate the effort, and move on.
+
+   The DNS situation differs from these practices in at least two ways.
+   Since a global solution is required, the business card would need a
+   number of sides approximating the number of languages in the world,
+   which is probably impossible without violating laws of physics.  More
+   important, the opportunities for tolerance don't exist:  the DNS
+   requires a exact match or the lookup fails.
+
+4.7 ASCII Encodings and the Roman Keyboard Assumption
+
+   Part of the argument for ACE-based solutions is that they provide an
+   escape for multilingual environments when applications have not been
+   upgraded.  When an older application encounters an ACE-based name,
+   the assumption is that the (admittedly ugly) ASCII-coded string will
+   be displayed and can be typed in.  This argument is reasonable from
+   the standpoint of mixtures of Roman-based alphabets, but may not be
+   relevant if user-level systems and devices are involved that do not
+   support the entry of Roman-based characters or which cannot
+   conveniently render such characters.  Such systems are few in the
+   world today, but the number can reasonably be expected to rise as the
+   Internet is increasingly used by populations whose primary concern is
+   with local issues, local information, and local languages.  It is,
+
+
+
+
+
+Klensin                      Informational                     [Page 22]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   for example, fairly easy to imagine populations who use Arabic or
+   Thai scripts and who do not have routine access to scripts or input
+   devices based on Roman-derived alphabets.
+
+4.8 Intra-DNS Approaches for "Multilingual Names"
+
+   It appears, from the cases above and others, that none of the intra-
+   DNS-based solutions for "multilingual names" are workable.  They rest
+   on too many assumptions that do not appear to be feasible -- that
+   people will adapt deeply-entrenched language habits to conventions
+   laid down to make the lives of computers easy; that we can make
+   "freeze it now, no need for changes in these areas" decisions about
+   Unicode and nameprep; that ACE will smooth over applications
+   problems, even in environments without the ability to key or render
+   Roman-based glyphs (or where user experience is such that such glyphs
+   cannot easily be distinguished from each other); that the Unicode
+   Consortium will never decide to repair an error in a way that creates
+   a risk of DNS incompatibility; that we can either deploy EDNS
+   [RFC2671] or that long names are not really important; that Japanese
+   and Chinese computer users (and others) will either give up their
+   local or IS 2022-based character coding solutions (for which addition
+   of a large fraction of a million new code points to Unicode is almost
+   certainly a necessary, but probably not sufficient, condition) or
+   build leakproof and completely accurate boundary conversion
+   mechanisms; that out of band or contextual information will always be
+   sufficient for the "map glyph onto script" problem; and so on.  In
+   each case, it is likely that about 80% or 90% of cases will work
+   satisfactorily, but it is unlikely that such partial solutions will
+   be good enough.  For example, suppose someone can spell her name 90%
+   correctly, or a company name is matched correctly 80% of the time but
+   the other 20% of attempts identify a competitor: are either likely to
+   be considered adequate?
+
+5. Search-based Systems: The Key Controversies
+
+   For many years, a common response to requirements to locate people or
+   resources on the Internet has been to invoke the term "directory".
+   While an in-depth analysis of the reasons would require a separate
+   document, the history of failure of these invocations has given
+   "directory" efforts a bad reputation.  The effort proposed here is
+   different from those predecessors for several reasons, perhaps the
+   most important of which is that it focuses on a fairly-well-
+   understood set of problems and needs, rather than on finding uses for
+   a particular technology.
+
+   As suggested in some of the text above, it is an open question as to
+   whether the needs of the community would be best served by a single
+   (even if functionally, and perhaps administratively, distributed)
+
+
+
+Klensin                      Informational                     [Page 23]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   directory with universal applicability, a single directory that
+   supports locally-tailored search (and, most important, matching)
+   functions, or multiple, locally-determined, directories.  Each has
+   its attractions.  Any but the first would essentially prevent
+   reverse-mapping (determination of the user-visible name of the host
+   or resource from target information such as an address or DNS name).
+   But reverse mapping has become less useful over the years --at least
+   to users -- as more and more names have been associated with many
+   host addresses and as CIDR [CIDR] has proven problematic for mapping
+   smaller address blocks to meaningful names.
+
+   Locally-tailored searches and mappings would permit national
+   variations on interpretation of which strings matched which other
+   ones, an arrangement that is especially important when different
+   localities apply different rules to, e.g., matching of characters
+   with and without diacriticals.  But, of course, this implies that a
+   URL may evaluate properly or not depending on either settings on a
+   client machine or the network connectivity of the user.  That is not,
+   in general, a desirable situation, since it implies that users could
+   not, in the general case, share URLs (or other host references) and
+   that a particular user might not be able to carry references from one
+   host or location to another.
+
+   And, of course, completely separate directories would permit
+   translation and transliteration functions to be embedded in the
+   directory, giving much of the Internet a different appearance
+   depending on which directory was chosen.  The attractions of this are
+   obvious, but, unless things were very carefully designed to preserve
+   uniqueness and precise identities at the right points (which may or
+   may not be possible), such a system would have many of the
+   difficulties associated with multiple DNS roots.
+
+   Finally, a system of separate directories and databases, if coupled
+   with removal of the DNS-imposed requirement for unique names, would
+   largely eliminate the need for a single worldwide authority to manage
+   the top of the naming hierarchy.
+
+6.  Security Considerations
+
+   The set of proposals implied by this document suggests an interesting
+   set of security issues (i.e., nothing important is ever easy).  A
+   directory system used for locating network resources would presumably
+   need to be as carefully protected against unauthorized changes as the
+   DNS itself.  There also might be new opportunities for problems in an
+   arrangement involving two or more (sub)layers, especially if such a
+   system were designed without central authority or uniqueness of
+   names.  It is uncertain how much greater those risks would be as
+   compared to a DNS lookup sequence that involved looking up one name,
+
+
+
+Klensin                      Informational                     [Page 24]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   getting back information, and then doing additional lookups
+   potentially in different subtrees.  That multistage lookup will often
+   be the case with, e.g., NAPTR records [RFC 2915] unless additional
+   restrictions are imposed.  But additional steps, systems, and
+   databases almost certainly involve some additional risks of
+   compromise.
+
+7.  References
+
+7.1 Normative References
+
+   None
+
+7.2 Explanatory and Informative References
+
+   [Albitz]       Any of the editions of Albitz, P. and C. Liu, DNS and
+                  BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
+
+   [ASCII]        American National Standards Institute (formerly United
+                  States of America Standards Institute), X3.4, 1968,
+                  "USA Code for Information Interchange". ANSI X3.4-1968
+                  has been replaced by newer versions with slight
+                  modifications, but the 1968 version remains definitive
+                  for the Internet.  Some time after ASCII was first
+                  formulated as a standard, ISO adopted international
+                  standard 646, which uses ASCII as a base.  IS 646
+                  actually contained two code tables: an "International
+                  Reference Version" (often referenced as ISO 646-IRV)
+                  which was essentially identical to the ASCII of the
+                  time, and a "Basic Version" (ISO 646-BV), which
+                  designates a number of character positions for
+                  national use.
+
+   [CIDR]         Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
+                  Inter-Domain Routing (CIDR): an Address Assignment and
+                  Aggregation Strategy", RFC 1519, September 1993.
+
+                  Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
+                  ADDR.ARPA delegation", RFC 2317, March 1998.
+
+   [COM-SIZE]     Size information supplied by Verisign Global Registry
+                  Services (the zone administrator, or "registry
+                  operator", for COM, see [REGISTRAR], below) to ICANN,
+                  third quarter 2002.
+
+   [DNS-Search]   Klensin, J., "A Search-based access model for the
+                  DNS", Work in Progress.
+
+
+
+
+Klensin                      Informational                     [Page 25]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [FINGER]       Zimmerman, D., "The Finger User Information Protocol",
+                  RFC 1288, December 1991.
+
+                  Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
+                  December 1977.
+
+   [IAB-OPES]     Floyd, S. and L. Daigle, "IAB Architectural and Policy
+                  Considerations for Open Pluggable Edge Services", RFC
+                  3238, January 2002.
+
+   [IQUERY]       Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+                  2002.
+
+   [IS646]        ISO/IEC 646:1991 Information technology -- ISO 7-bit
+                  coded character set for information interchange
+
+   [IS10646]      ISO/IEC 10646-1:2000 Information technology --
+                  Universal Multiple-Octet Coded Character Set (UCS) --
+                  Part 1: Architecture and Basic Multilingual Plane and
+                  ISO/IEC 10646-2:2001 Information technology --
+                  Universal Multiple-Octet Coded Character Set (UCS) --
+                  Part 2: Supplementary Planes
+
+   [MINC]         The Multilingual Internet Names Consortium,
+                  http://www.minc.org/ has been an early advocate for
+                  the importance of expansion of DNS names to
+                  accommodate non-ASCII characters.  Some of their
+                  specific proposals, while helping people to understand
+                  the problems better, were not compatible with the
+                  design of the DNS.
+
+   [NAPTR]        Mealling, M. and R. Daniel, "The Naming Authority
+                  Pointer (NAPTR) DNS Resource Record", RFC 2915,
+                  September 2000.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
+                  October 2002.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part Two: The Algorithm", RFC 3402, October
+                  2002.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part Three: The Domain Name System (DNS)
+                  Database", RFC 3403, October 2002.
+
+
+
+
+
+Klensin                      Informational                     [Page 26]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [REGISTRAR]    In an early stage of the process that created the
+                  Internet Corporation for Assigned Names and Numbers
+                  (ICANN), a "Green Paper" was released by the US
+                  Government.   That paper introduced new terminology
+                  and some concepts not needed by traditional DNS
+                  operations.  The term "registry" was applied to the
+                  actual operator and database holder of a domain
+                  (typically at the top level, since the Green Paper was
+                  little concerned with anything else), while
+                  organizations that marketed names and made them
+                  available to "registrants" were known as "registrars".
+                  In the classic DNS model, the function of "zone
+                  administrator" encompassed both registry and registrar
+                  roles, although that model did not anticipate a
+                  commercial market in names.
+
+   [RFC625]       Kudlick, M. and E. Feinler, "On-line hostnames
+                  service", RFC 625, March 1974.
+
+   [RFC734]       Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
+
+   [RFC811]       Harrenstien, K., White, V. and E. Feinler, "Hostnames
+                  Server", RFC 811, March 1982.
+
+   [RFC819]       Su, Z. and J. Postel, "Domain naming convention for
+                  Internet user applications", RFC 819, August 1982.
+
+   [RFC830]       Su, Z., "Distributed system for Internet name
+                  service", RFC 830, October 1982.
+
+   [RFC882]       Mockapetris, P., "Domain names: Concepts and
+                  facilities", RFC 882, November 1983.
+
+   [RFC883]       Mockapetris, P., "Domain names: Implementation
+                  specification", RFC 883, November 1983.
+
+   [RFC952]       Harrenstien, K, Stahl, M. and E. Feinler, "DoD
+                  Internet host table specification", RFC 952, October
+                  1985.
+
+   [RFC953]       Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
+                  SERVER", RFC 953, October 1985.
+
+   [RFC1034]      Mockapetris, P., "Domain names, Concepts and
+                  facilities", STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+Klensin                      Informational                     [Page 27]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [RFC1035]      Mockapetris, P., "Domain names - implementation and
+                  specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1591]      Postel, J., "Domain Name System Structure and
+                  Delegation", RFC 1591, March 1994.
+
+   [RFC2181]      Elz, R. and  R. Bush, "Clarifications to the DNS
+                  Specification", RFC 2181, July 1997.
+
+   [RFC2295]      Holtman, K. and A. Mutz, "Transparent Content
+                  Negotiation in HTTP", RFC 2295, March 1998
+
+   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
+                  "Uniform Resource Identifiers (URI): Generic Syntax",
+                  RFC 2396, August 1998.
+
+   [RFC2608]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
+                  "Service Location Protocol, Version 2", RFC 2608, June
+                  1999.
+
+   [RFC2671]      Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                  2671, August 1999.
+
+   [RFC2825]      IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
+                  Domain Names, and the Other Internet protocols", RFC
+                  2825, May 2000.
+
+   [RFC2826]      IAB, "IAB Technical Comment on the Unique DNS Root",
+                  RFC 2826, May 2000.
+
+   [RFC2972]      Popp, N., Mealling, M., Masinter, L. and K. Sollins,
+                  "Context and Goals for Common Name Resolution", RFC
+                  2972, October 2000.
+
+   [RFC3305]      Mealling, M. and R. Denenberg, Eds., "Report from the
+                  Joint W3C/IETF URI Planning Interest Group: Uniform
+                  Resource Identifiers (URIs), URLs, and Uniform
+                  Resource Names (URNs):  Clarifications and
+                  Recommendations", RFC 3305, August 2002.
+
+   [RFC3439]      Bush, R. and D. Meyer, "Some Internet Architectural
+                  Guidelines and Philosophy", RFC 3439, December 2002.
+
+   [Seng]         Seng, J., et al., Eds., "Internationalized Domain
+                  Names:  Registration and Administration Guideline for
+                  Chinese, Japanese, and Korean", Work in Progress.
+
+
+
+
+
+Klensin                      Informational                     [Page 28]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [STRINGPREP]   Hoffman, P. and M. Blanchet, "Preparation of
+                  Internationalized Strings (stringprep)", RFC 3454,
+                  December 2002.
+
+                  The particular profile used for placing
+                  internationalized strings in the DNS is called
+                  "nameprep", described in Hoffman, P. and M. Blanchet,
+                  "Nameprep: A Stringprep Profile for Internationalized
+                  Domain Names", Work in Progress.
+
+   [TELNET]       Postel, J. and J. Reynolds, "Telnet Protocol
+                  Specification", STD 8, RFC 854, May 1983.
+
+                  Postel, J. and J. Reynolds, "Telnet Option
+                  Specifications", STD 8, RFC 855, May 1983.
+
+   [UNICODE]      The Unicode Consortium, The Unicode Standard, Version
+                  3.0, Addison-Wesley: Reading, MA, 2000.  Update to
+                  version 3.1, 2001.  Update to version 3.2, 2002.
+
+   [UTR15]        Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+                  Unicode Normalization Forms", Unicode Consortium,
+                  March 2002.  An integral part of The Unicode Standard,
+                  Version 3.1.1.  Available at
+                  (http://www.unicode.org/reports/tr15/tr15-21.html).
+
+   [WHOIS]        Harrenstien, K, Stahl, M. and E. Feinler,
+                  "NICNAME/WHOIS", RFC 954, October 1985.
+
+   [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
+                  Information Lookup Service, Whois++", RFC 1834, August
+                  1995.
+
+                  Weider, C., Fullton, J. and S. Spero, "Architecture of
+                  the Whois++ Index Service", RFC 1913, February 1996.
+
+                  Williamson, S., Kosters, M., Blacka, D., Singh, J. and
+                  K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
+                  RFC 2167, June 1997;
+
+                  Daigle, L. and P. Faltstrom, "The
+                  application/whoispp-query Content-Type", RFC 2957,
+                  October 2000.
+
+                  Daigle, L. and P. Falstrom, "The application/whoispp-
+                  response Content-type", RFC 2958, October 2000.
+
+
+
+
+
+Klensin                      Informational                     [Page 29]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [X29]          International Telecommuncations Union, "Recommendation
+                  X.29: Procedures for the exchange of control
+                  information and user data between a Packet
+                  Assembly/Disassembly (PAD) facility and a packet mode
+                  DTE or another PAD", December 1997.
+
+8. Acknowledgements
+
+   Many people have contributed to versions of this document or the
+   thinking that went into it.  The author would particularly like to
+   thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt
+   Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie,
+   Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific
+   suggestions and/or challenging the assumptions and presentation of
+   earlier versions and suggesting ways to improve them.
+
+9. Author's Address
+
+   John C. Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA 02140
+
+   EMail: klensin+srch@jck.com
+
+   A mailing list has been initiated for discussion of the topics
+   discussed in this document, and closely-related issues, at
+   ietf-irnss@lists.elistx.com.  See http://lists.elistx.com/archives/
+   for subscription and archival information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 30]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+10. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 31]
+