Network Working Group J Klensin Internet Draft MCI Document: draft-klensin-tld-whois-00.txt T Wolf, Jr. Dun & Bradstreet September 1996 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