One document matched: draft-klensin-tld-whois-00.txt

	       Domain Names and Company Name Retrieval


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress``.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.

   A revised version of this draft document may be submitted to the
   RFC Editor for processing as an Experimental RFC for the Internet
   Community.  Discussion and suggestions for improvement are
   requested. This draft will expire before March 1, 1997.
   Distribution of this draft is unlimited. 


Abstract

   Location of web information for particular companies based on
   their names has become an increasingly difficult problem and the
   Internet and the web grow.   The use of a naming convention and
   the domain name system (DNS) for that purpose has caused
   complications for the latter while not solving the problem.
   While there have been several proposals to use contemporary,
   high-capability, directory service and search protocols to reduce
   the dependencies on DNS conventions, none of them have been
   significantly deployed.

   This document proposes a company name to URL mapping service based
   on the oldest and least complex of Internet directory protocols,
   whois, in order to explore whether and extremely simple and
   widely-deployed protocol can succeed where more complex and
   powerful options have failed or been excessively delayed.


1. Introduction and Context

   In recent months, there have been many discussions in various
   segments of the Internet community about "the top level domain
   problem".  Perhaps characteristically, that term is used by
   different groups to identify different, and perhaps nearly
   orthogonal, issues.  Those issues include:

   1.1.  A "domain administration policy" issue.

   1.2.  A "name ownership" issue, of which the trademark issue may
         constitute a special case.

   1.3.  An information location issue, specifically the problem of
         locating the appropriate domain, or information tied to a
	 domain, for an entity given the name by which that entity is
	 usually known.

   Of these, controversies about the first two may be inevitable
   consequences of the growth of the Internet.  There have been
   intermittent difficulties with top level domain adminstration and
   various attempts to use the domain registry function as a
   mechanism for control of service providers or services from time
   to time since a large number of such domains started being
   allocated.  Those problems led to the publication of the policy
   guidelines of [RFC1591].

   The third appears to be largely a consequence of the explosive
   growth of the World Wide Web and, in particular, the exposure of
   URL formats [URL] to the end user because no other mechanisms have
   been available.  The absence of an appropriate and adequately-
   deployed directory service has led to the assumption that it
   should be possible to locate the web pages for a company by use of
   a naming convention involving that company's name or product name,
   i.e., for the XYZ Company, a web page located at

        http://www.xyz.com/
   or
        http://www.xyz-company.com/

   has been assumed.

   However, as the network grows and as increasing numbers of web
   sites are rooted in domains other than ".COM", this convention
   becomes difficult to sustain: there will be too many organizations
   or companies with legitimate claims --perhaps in different lines
   of business or jurisdictions-- to the same short descriptive
   names.  For that reason, there has been a general sense in the
   community for several years that the solution to this information
   location problem lies, not in changes to the domain name system,
   but in some type of directory service.

   But such directory services have not come into being.  There has
   been ongoing controversy about choices of protocols and accessing
   mechanisms.  IETF has published specifications for several
   different directory and search protocols, including [WHOIS++],
   [RWHOIS], [LDAP], [X500], [GOPHER].  One hypothesis about why this
   has not happened is that these mechanisms have been hard to select
   and deploy because they are much more complex than is necessary.
   This document proposes an extremely simple alternative.


2. Using WHOIS

   The WHOIS protocol is the oldest directory access protocol in use
   on the Internet, dating in published form to March 1982 and first
   implemented somewhat earlier.  The procotol itself is simple and
   minimalist: the client opens a telnet connection to the WHOIS
   port and transmits a line over it.  The server looks up the line
   in a fashion that it defines, returns one or more lines of
   information to the client, and closes the connection.

   We suggest that modifications or add-ins be created to Web
   browsers that would access a new, commercially-provided Whois
   server, sending a putative company name and receiving back one or
   more lines, each containing a URL followed by one or more blanks
   and then a matching company name (that order was chosen to
   minimize parsing problems: since URLs cannot contain blanks, the
   first blank character marks the end of the URL and the next
   non-blank marks the beginning of the company name).  As is usual
   with Whois, the criteria used by the server to match the incoming
   string is at the server's discretion.  The difference between this
   and the protocol as documented in [WHOIS] is that exactly one
   company name is returned per line.

   The client would then be expected to:

   (i) If a single line (company name and URL) is returned, either
       ask for confirmation or simply fetch the associated URL as if
       it had been typed by the user.

   (ii) If multiple lines (names) are returned, present the user with
       a choice, presumably showing company names rather than (or
       supplemented by) URLs, then fetch using the URL selected.

   Obviously, while the most convenient use of the services
   contemplated in this document would occur through a client that
   was part of, or intimately connected with, a Web browser, a user
   without that type of facility could utilize a traditional WHOIS
   client and paste or otherwise transfer the relevant information
   into the target location of a browser.



3. Thoughts on Directory Providers

   There is no technical reason why there should be only one provider
   of company name to URL mapping services using this protocol, nor
   is there any reason for registries of such providers.  Presumably,
   servers that provide the best-quality mappings will eventually
   prevail in the marketplace.  However, as with most traditional
   uses of WHOIS, it is desirable for implementations of clients (or
   Web browsers supporting this protocol) to allow for user choice of
   servers through configuration options or the equivalent.


4. References

   [RFC1591]  J. Postel, "Domain Name System Structure and
           Delegation",  RFC 1591, March 3, 1994

   [GOPHER] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D.
           John, D. Torrey, B. Alberti, "The Internet Gopher Protocol
	   (a distributed document search and retrieval protocol)",
	   RFC 1436, 03/18/1993.

   [LDAP]  W. Yeong, T. Howes, S. Kille, "Lightweight Directory
           Access Protocol", RFC 1777, 03/28/1995.


   [RWHOIS]   S. Williamson, M. Kosters, "Referral Whois Protocol
          (RWhois)", RFC 1714, 12/15/1994. 

   [URL]   T. Berners-Lee, L. Masinter, M. McCahill, "Uniform
           Resource Locators (URL)", RFC 1738, December 20, 1994.

   [WHOIS] E. Feinler, K. Harrenstien, M. Stahl, "NICNAME/WHOIS", 
           RFC 954, 0/01/1985. 

   [WHOIS++]  P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider,
           "Architecture of the WHOIS++ service", RFC 1835, August
	   16, 1995. 

   [X500]  R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W.
           Yeong, "Recommendations for an X.500 Production Directory
	   Service", RFC 1803, 06/07/1995.

   [Z39.50]  C. Lynch, "Using the Z39.50 Information Retrieval
           Protocol in the Internet Environment", RFC 1729,
	   12/16/1994. 


5. Security Considerations

   This suggested use of the WHOIS protocol adds no significant
   security risks to those of traditional applications of the
   protocol which is one of the most widely-deployed applications on
   the Internet.  As usual, servers should expect to use the string
   sent to them as an information retrieval key, not as a function to
   be executed in some way.  A more significant risk would arise if
   the server supporting the translation function were somehow
   spoofed; in that case, an incorrect URL might be returned for a
   particular company. As with the possibility of finding an
   incorrect page using naming conventions, the best protection
   against the risks that could then occur is careful attention to
   certificates, signatures, and other authenticity-indicating
   information. 


6. Acknowledgements

   This memo was inspired by a many discussions over the last few
   years about the status and uses of the domain name system, 
   information location using conventions about domain names,
   exposure of URLs to end users, and convergence of directory and
   search protocols.  While the people involved are too numerous to
   attempt to list, the authors would like to acknowledge their
   contributions and comments.


7. Authors' Address

 John C. Klensin
 MCI Data Architecture
 800 Boylston St, 7th floor
 Boston, MA 02199
 USA
    Email: klensin@mci.net
    Tel: +1 617 960 1011

 Ted Wolf, Jr.
 Electronic Commerce
 Dun & Bradstreet Information Services
 3 Sylvan Way
 Parsippany, NJ 07054
 USA
    Email: ted@usa.net
    Tel: +1 201 605 6308