idnits 2.17.1 draft-klensin-tld-whois-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 426 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10022 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1591 ** Downref: Normative reference to an Informational RFC: RFC 1436 (ref. 'GOPHER') ** Obsolete normative reference: RFC 1777 (ref. 'LDAP') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1714 (ref. 'RWHOIS') (Obsoleted by RFC 2167) ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 954 (ref. 'WHOIS') (Obsoleted by RFC 3912) ** Downref: Normative reference to an Informational RFC: RFC 1803 (ref. 'X500') Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J Klensin 2 Internet Draft MCI 3 Document: draft-klensin-tld-whois-01.txt T Wolf, Jr. 4 Dun & Bradstreet 5 November 1996 7 Domain Names and Company Name Retrieval 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress``. 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 25 munnari.oz.au. 27 A revised version of this draft document may be submitted to the 28 RFC Editor for processing as an Experimental RFC for the Internet 29 Community. Discussion and suggestions for improvement are 30 requested. This draft will expire before April 1, 1997. 31 Distribution of this draft is unlimited. 33 Changes from prior draft: Minor editorial work; new sections 34 inserted after section 2. 36 Abstract 38 Location of web information for particular companies based on 39 their names has become an increasingly difficult problem and the 40 Internet and the web grow. The use of a naming convention and 41 the domain name system (DNS) for that purpose has caused 42 complications for the latter while not solving the problem. 43 While there have been several proposals to use contemporary, 44 high-capability, directory service and search protocols to reduce 45 the dependencies on DNS conventions, none of them have been 46 significantly deployed. 48 This document proposes a company name to URL mapping service based 49 on the oldest and least complex of Internet directory protocols, 50 whois, in order to explore whether and extremely simple and 51 widely-deployed protocol can succeed where more complex and 52 powerful options have failed or been excessively delayed. 54 1. Introduction and Context 56 In recent months, there have been many discussions in various 57 segments of the Internet community about "the top level domain 58 problem". Perhaps characteristically, that term is used by 59 different groups to identify different, and perhaps nearly 60 orthogonal, issues. Those issues include: 62 1.1. A "domain administration policy" issue. 64 1.2. A "name ownership" issue, of which the trademark issue may 65 constitute a special case. 67 1.3. An information location issue, specifically the problem of 68 locating the appropriate domain, or information tied to a 69 domain, for an entity given the name by which that entity is 70 usually known. 72 Of these, controversies about the first two may be inevitable 73 consequences of the growth of the Internet. There have been 74 intermittent difficulties with top level domain adminstration and 75 various attempts to use the domain registry function as a 76 mechanism for control of service providers or services from time 77 to time since a large number of such domains started being 78 allocated. Those problems led to the publication of the policy 79 guidelines of [RFC1591]. 81 The third appears to be largely a consequence of the explosive 82 growth of the World Wide Web and, in particular, the exposure of 83 URL formats [URL] to the end user because no other mechanisms have 84 been available. The absence of an appropriate and adequately- 85 deployed directory service has led to the assumption that it 86 should be possible to locate the web pages for a company by use of 87 a naming convention involving that company's name or product name, 88 i.e., for the XYZ Company, a web page located at 90 http://www.xyz.com/ 91 or 92 http://www.xyz-company.com/ 94 has been assumed. 96 However, as the network grows and as increasing numbers of web 97 sites are rooted in domains other than ".COM", this convention 98 becomes difficult to sustain: there will be too many organizations 99 or companies with legitimate claims --perhaps in different lines 100 of business or jurisdictions-- to the same short descriptive 101 names. For that reason, there has been a general sense in the 102 community for several years that the solution to this information 103 location problem lies, not in changes to the domain name system, 104 but in some type of directory service. 106 But such directory services have not come into being. There has 107 been ongoing controversy about choices of protocols and accessing 108 mechanisms. IETF has published specifications for several 109 different directory and search protocols, including [WHOIS++], 110 [RWHOIS], [LDAP], [X500], [GOPHER]. One hypothesis about why this 111 has not happened is that these mechanisms have been hard to select 112 and deploy because they are much more complex than is necessary. 113 This document proposes an extremely simple alternative. 115 2. Using WHOIS 117 The WHOIS protocol is the oldest directory access protocol in use 118 on the Internet, dating in published form to March 1982 and first 119 implemented somewhat earlier. The procotol itself is simple and 120 minimalist: the client opens a telnet connection to the WHOIS 121 port and transmits a line over it. The server looks up the line 122 in a fashion that it defines, returns one or more lines of 123 information to the client, and closes the connection. 125 We suggest that modifications or add-ins be created to Web 126 browsers that would access a new, commercially-provided Whois 127 server, sending a putative company name and receiving back one or 128 more lines, each containing a URL followed by one or more blanks 129 and then a matching company name (that order was chosen to 130 minimize parsing problems: since URLs cannot contain blanks, the 131 first blank character marks the end of the URL and the next 132 non-blank marks the beginning of the company name). As is usual 133 with Whois, the criteria used by the server to match the incoming 134 string is at the server's discretion. The difference between this 135 and the protocol as documented in [WHOIS] is that exactly one 136 company name is returned per line (see section 3 for details of 137 syntax). 139 The client would then be expected to: 141 (i) If a single line (company name and URL) is returned, either 142 ask for confirmation or simply fetch the associated URL as if 143 it had been typed by the user. 145 (ii) If multiple lines (names) are returned, present the user with 146 a choice, presumably showing company names rather than (or 147 supplemented by) URLs, then fetch using the URL selected. 149 Obviously, while the most convenient use of the services 150 contemplated in this document would occur through a client that 151 was part of, or intimately connected with, a Web browser, a user 152 without that type of facility could utilize a traditional WHOIS 153 client and paste or otherwise transfer the relevant information 154 into the target location of a browser. 156 3. Formats, versions, and international character sets 158 Preliminary work with the approach suggested above suggests that 159 some specific conventions about syntax and variations would be 160 useful. 162 3.1 Line sent from client to server. 164 These lines may take either of two forms: 166 (i) A simple 7-bit ASCII string, containing a "company name" 168 (ii) A string in the format (using the ABNF notation of RFC 822): 169 Variation "/" 1*Octet 171 Variation :== "0" | ( Non-zero-digit 1*Digit) 172 Non-zero-digit :== 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 173 Digit :== 0 | Non-zero-digit 175 Where Octet is any eight-bit sequence, representing a prefixed 176 variation number. 178 The first form will be construed as equivalent to the second form 179 with the leading string "0/". Variation numbers are specified in 180 section 3.3. 182 In all cases, the interpretation of what "company name" might mean 183 and, in particular, what variations of form or spelling, 184 abbreviations, and so on, might be accepted is strictly up to the 185 interpretation of the server. If rules driving the server lead to 186 the conclusion that a string matches some company in its data, 187 the correctness or incorrectness of that decision is not covered 188 by this specification. 190 3.2 Lines sent from server to client. 192 The server is expected to return one or more lines to the client, 193 depending on its interpretation of the input string. In general, 194 each line will consist, as described above, of a URL, a space, and 195 a "company name". This document deliberately does not specify the 196 content or semantics of the "company name" string. It might be a 197 name, or a name and descriptive information such as location and 198 type of business, or other information at the option of the 199 server. The expectation, as mentioned above, is that the 200 information will be displayed by the client to aid users in 201 selecting the appropriate URL. 203 When and if different variation numbers are introduced, their 204 specifications may include variations on what the server is 205 expected to return. 207 In lieu of "URL and company name" responses, the Server may also 208 return "error messages". These take the form 210 "///" SP String 212 where the String is 7-bit ASCII with no control characters other 213 than SP, unless the variation associated with the variation 214 number specifies otherwise. For this experiment, all "error 215 messages" but the following two are discouraged: 217 /// Not found 218 Indicating that the "company name" does not 219 match anything 220 /// Variation not supported 221 Indicating that the variation number supplied 222 by the client is not recognized by the server. 224 3.3. Registered variations 226 The following two variations are established as part of this 227 specification: 229 0/ Query and response are in 7-bit ASCII, no controls other 230 than SP, "Company name" separated from URL by one or more 231 SP characters. 233 1/ Query and response are in UTF-8, no controls other than 234 SP, "Company name" separated from URL by one or more 235 SP characters, no specification of language on either 236 input or output. 238 The authors will maintain a registry of additional variations 239 which they hope will be very short (see section 9). If this 240 specification evolves into a proposed standard after an 241 experimental period, the draft for that standard will propose that 242 the registry be turned over to IANA. 244 4. Alternatives not chosen 246 Few comments on the initial draft of this document addressed the 247 basic model or protocol design for the service discussed. 248 Instead, they focused on inquiring about the decisions we didn't 249 make and about beliefs about the protocol specification that were 250 not intended by the authors. The latter have been, we hope, 251 corrected. Questions of the following three types predominated in 252 the first category. 254 4.1. Why didn't you use ? 256 Many notes raised the question of how much more could be done with 257 a higher-powered directory protocol rather than the extremely 258 simple WHOIS. Questions were raised about LDAP, X.500 DAP, CCSO, 259 RWHOIS, and WHOIS++. We had several reasons for avoiding them. 260 The most important has been a strong commitment to see how much 261 can be done with an extremely simplistic approach, and WHOIS 262 represented the most simplistic approach we could find. If it 263 turns out to be too simple in practice, things can always evolve 264 to one or more of the more advanced protocols. But, if we 265 started with one of them, we would never get that information. 266 Other issues included: 268 * None of the existing directory proposals has really emerged as 269 the "right" solution with a large installed base. The deployed 270 base of WHOIS and WHOIS clients is huge, and using it avoids 271 either having to make a premature choice of "winner" or to 272 become embroiled in the debate. 274 * For the casual user, the mechanisms needed to activate the 275 extensive attribute-based directory searches of the stronger 276 protocols are just too complicated and may actually act as a 277 deterrent to effective use. 279 * Substantially since the dawn of the ARPANET, the Internet 280 experience has been that setting up a directory service is easy, 281 but that maintaining one and keeping the records up-to-date is 282 extremely difficult. The economics of operating an effective 283 directory service and keeping everything up to date may will 284 require a revenue-producing product. Use of a very simple 285 protocol for the basic service creates a situation in which 286 basic service can rationally be given away while more advanced 287 service are operated on a charge or subscription basis. 289 4.2 And why not use a Web search engine? 291 Web search engines are immensely effective and powerful, but 292 address a different problem than this protocol. The protocol 293 model here does involve a directory lookup, using a presumed 294 company name as a key. The quality of the result will depend 295 on the quality of the underlying directory and the editorial and 296 research work that goes into its construction. Web search engines 297 are often more effective at locating information about companies 298 than the specific company-designated web pages. 300 4.3. Why not return a more highly structured information format 301 rather than a simple pair of URL and "company name"? 303 Again, the goal was to keep things extremely simple and, in 304 particular, permit minimal interpretation between the user's input 305 and the query and between the response and a display or action. 306 Some of the inquiries on this subject were due to 307 misunderstandings about the implications of the "company name" 308 field; the semantics of that field have been clarified above. We 309 also wanted to avoid the level of standardization implied by a 310 tagging scheme: highly-structured fields might lead either to 311 interoperability problems or excessive restriction on what might 312 be returned. 314 5. Thoughts on Directory Providers 316 There is no technical reason why there should be only one provider 317 of company name to URL mapping services using this protocol, nor 318 is there any reason for registries of such providers. Presumably, 319 servers that provide the best-quality mappings will eventually 320 prevail in the marketplace. However, as with most traditional 321 uses of WHOIS, it is desirable for implementations of clients (or 322 Web browsers supporting this protocol) to allow for user choice of 323 servers through configuration options or the equivalent. 325 6. References 327 [RFC1591] J. Postel, "Domain Name System Structure and 328 Delegation", RFC 1591, March 3, 1994 330 [GOPHER] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. 331 John, D. Torrey, B. Alberti, "The Internet Gopher Protocol 332 (a distributed document search and retrieval protocol)", 333 RFC 1436, 03/18/1993. 335 [LDAP] W. Yeong, T. Howes, S. Kille, "Lightweight Directory 336 Access Protocol", RFC 1777, 03/28/1995. 338 [RWHOIS] S. Williamson, M. Kosters, "Referral Whois Protocol 339 (RWhois)", RFC 1714, 12/15/1994. 341 [URL] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform 342 Resource Locators (URL)", RFC 1738, December 20, 1994. 344 [WHOIS] E. Feinler, K. Harrenstien, M. Stahl, "NICNAME/WHOIS", 345 RFC 954, 0/01/1985. 347 [WHOIS++] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, 348 "Architecture of the WHOIS++ service", RFC 1835, August 16, 349 1995. 351 [X500] R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. 352 Yeong, "Recommendations for an X.500 Production Directory 353 Service", RFC 1803, 06/07/1995. 355 [Z39.50] C. Lynch, "Using the Z39.50 Information Retrieval 356 Protocol in the Internet Environment", RFC 1729, 12/16/1994. 358 7. Security Considerations 360 This suggested use of the WHOIS protocol adds no significant 361 security risks to those of traditional applications of the 362 protocol which is one of the most widely-deployed applications on 363 the Internet. As usual, servers should expect to use the string 364 sent to them as an information retrieval key, not as a function to 365 be executed in some way. A more significant risk would arise if 366 the server supporting the translation function were somehow 367 spoofed; in that case, an incorrect URL might be returned for a 368 particular company. As with the possibility of finding an 369 incorrect page using naming conventions, the best protection 370 against the risks that could then occur is careful attention to 371 certificates, signatures, and other authenticity-indicating 372 information. 374 8. Acknowledgements 376 This memo was inspired by a many discussions over the last few 377 years about the status and uses of the domain name system, 378 information location using conventions about domain names, 379 exposure of URLs to end users, and convergence of directory and 380 search protocols. While the people involved are too numerous to 381 attempt to list, the authors would like to acknowledge their 382 contributions and comments. 384 Martin Hamilton and Keith Moore made important suggestions that 385 have contributed to the revision of this draft. 387 9. Authors' Address 389 John C. Klensin 390 MCI Data Architecture 391 800 Boylston St, 7th floor 392 Boston, MA 02199 393 USA 394 Email: klensin@mci.net 395 Tel: +1 617 960 1011 397 Ted Wolf, Jr. 398 Electronic Commerce 399 Dun & Bradstreet Information Services 400 3 Sylvan Way 401 Parsippany, NJ 07054 402 USA 403 Email: ted@usa.net 404 Tel: +1 201 605 6308 406 Address for purposes of registering variants only: 407 url-whois@mail1.reston.mci.net