idnits 2.17.1 draft-klensin-tld-whois-02.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-23) 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 432 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 (July 29, 1997) is 9765 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-02.txt T Wolf, Jr. 4 Dun & Bradstreet 5 July 29, 1997 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 January 30, 1998. 31 Distribution of this draft is unlimited. 33 Changes from prior draft: Small technical clarifications. 35 Abstract 37 Location of web information for particular companies based on 38 their names has become an increasingly difficult problem and the 39 Internet and the web grow. The use of a naming convention and 40 the domain name system (DNS) for that purpose has caused 41 complications for the latter while not solving the problem. 42 While there have been several proposals to use contemporary, 43 high-capability, directory service and search protocols to reduce 44 the dependencies on DNS conventions, none of them have been 45 significantly deployed. 47 This document proposes a company name to URL mapping service based 48 on the oldest and least complex of Internet directory protocols, 49 whois, in order to explore whether and extremely simple and 50 widely-deployed protocol can succeed where more complex and 51 powerful options have failed or been excessively delayed. 53 1. Introduction and Context 55 In recent months, there have been many discussions in various 56 segments of the Internet community about "the top level domain 57 problem". Perhaps characteristically, that term is used by 58 different groups to identify different, and perhaps nearly 59 orthogonal, issues. Those issues include: 61 1.1. A "domain administration policy" issue. 63 1.2. A "name ownership" issue, of which the trademark issue may 64 constitute a special case. 66 1.3. An information location issue, specifically the problem of 67 locating the appropriate domain, or information tied to a 68 domain, for an entity given the name by which that entity is 69 usually known. 71 Of these, controversies about the first two may be inevitable 72 consequences of the growth of the Internet. There have been 73 intermittent difficulties with top level domain adminstration and 74 various attempts to use the domain registry function as a 75 mechanism for control of service providers or services from time 76 to time since a large number of such domains started being 77 allocated. Those problems led to the publication of the policy 78 guidelines of [RFC1591]. 80 The third appears to be largely a consequence of the explosive 81 growth of the World Wide Web and, in particular, the exposure of 82 URL formats [URL] to the end user because no other mechanisms have 83 been available. The absence of an appropriate and adequately- 84 deployed directory service has led to the assumption that it 85 should be possible to locate the web pages for a company by use of 86 a naming convention involving that company's name or product name, 87 i.e., for the XYZ Company, a web page located at 89 http://www.xyz.com/ 90 or 91 http://www.xyz-company.com/ 93 has been assumed. 95 However, as the network grows and as increasing numbers of web 96 sites are rooted in domains other than ".COM", this convention 97 becomes difficult to sustain: there will be too many organizations 98 or companies with legitimate claims --perhaps in different lines 99 of business or jurisdictions-- to the same short descriptive 100 names. For that reason, there has been a general sense in the 101 community for several years that the solution to this information 102 location problem lies, not in changes to the domain name system, 103 but in some type of directory service. 105 But such directory services have not come into being. There has 106 been ongoing controversy about choices of protocols and accessing 107 mechanisms. IETF has published specifications for several 108 different directory and search protocols, including [WHOIS++], 109 [RWHOIS], [LDAP], [X500], [GOPHER]. One hypothesis about why this 110 has not happened is that these mechanisms have been hard to select 111 and deploy because they are much more complex than is necessary. 112 This document proposes an extremely simple alternative. 114 2. Using WHOIS 116 The WHOIS protocol is the oldest directory access protocol in use 117 on the Internet, dating in published form to March 1982 and first 118 implemented somewhat earlier. The procotol itself is simple and 119 minimalist: the client opens a telnet connection to the WHOIS 120 port (43) and transmits a line over it. The server looks up the 121 line in a fashion that it defines, returns one or more lines of 122 information to the client, and closes the connection. 124 We suggest that modifications or add-ins be created to Web 125 browsers that would access a new, commercially-provided Whois 126 server, sending a putative company name and receiving back one or 127 more lines, each containing a URL followed by one or more blanks 128 and then a matching company name (that order was chosen to 129 minimize parsing problems: since URLs cannot contain blanks, the 130 first blank character marks the end of the URL and the next 131 non-blank marks the beginning of the company name). As is usual 132 with Whois, the criteria used by the server to match the incoming 133 string is at the server's discretion. The difference between this 134 and the protocol as documented in [WHOIS] is that exactly one 135 company name is returned per line (see section 3 for details of 136 syntax). 138 The client would then be expected to: 140 (i) If a single line (company name and URL) is returned, either 141 ask for confirmation or simply fetch the associated URL as if 142 it had been typed by the user. 144 (ii) If multiple lines (names) are returned, present the user with 145 a choice, presumably showing company names rather than (or 146 supplemented by) URLs, then fetch using the URL selected. 148 Obviously, while the most convenient use of the services 149 contemplated in this document would occur through a client that 150 was part of, or intimately connected with, a Web browser, a user 151 without that type of facility could utilize a traditional WHOIS 152 client and paste or otherwise transfer the relevant information 153 into the target location of a browser. 155 3. Formats, versions, and international character sets 157 Preliminary work with the approach suggested above suggests that 158 some specific conventions about syntax and variations would be 159 useful. 161 3.1 Line sent from client to server. 163 These lines may take either of two forms: 165 (i) A simple 7-bit ASCII string, containing a "company name" 167 (ii) A string in the format (using the ABNF notation of RFC 822): 168 Variation "/" 1*Octet 170 Variation :== "0" | ( Non-zero-digit 1*Digit) 171 Non-zero-digit :== 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 172 Digit :== 0 | Non-zero-digit 174 Where Octet is any eight-bit sequence, representing a prefixed 175 variation number. 177 The first form will be construed as equivalent to the second form 178 with the leading string "0/". Variation numbers are specified in 179 section 3.3. 181 In all cases, the interpretation of what "company name" might mean 182 and, in particular, what variations of form or spelling, 183 abbreviations, and so on, might be accepted is strictly up to the 184 interpretation of the server. If rules driving the server lead to 185 the conclusion that a string matches some company in its data, 186 the correctness or incorrectness of that decision is not covered 187 by this specification. 189 For variation 0 and, by default for all others, any alphabetic 190 text in lines is to be construed in a case-insensitive fashion. 192 3.2 Lines sent from server to client. 194 The server is expected to return one or more lines to the client, 195 depending on its interpretation of the input string. In general, 196 each line will consist, as described above, of a URL, a space, and 197 a "company name". This document deliberately does not specify the 198 content or semantics of the "company name" string. It might be a 199 name, or a name and descriptive information such as location and 200 type of business, or other information at the option of the 201 server. The expectation, as mentioned above, is that the 202 information will be displayed by the client to aid users in 203 selecting the appropriate URL. 205 These lines, consistent with normal Internet practice, will be 206 terminated by a CR LF sequence (rather than one or the other of 207 those control characters). 209 When and if different variation numbers are introduced, their 210 specifications may include variations on what the server is 211 expected to return. 213 In lieu of "URL and company name" responses, the Server may also 214 return "error messages". These take the form of lines containing: 216 "///" SP String 218 where the String is 7-bit ASCII with no control characters other 219 than SP, unless the variation associated with the variation 220 number specifies otherwise. For this experiment, all "error 221 messages" but the following two are discouraged: 223 /// Not found 224 Indicating that the "company name" does not 225 match anything 226 /// Variation not supported 227 Indicating that the variation number supplied 228 by the client is not recognized by the server. 230 3.3. Registered variations 232 The following two variations are established as part of this 233 specification: 235 0/ Query and response are in 7-bit ASCII, no controls other 236 than SP, "Company name" separated from URL by one or more 237 SP characters. 239 1/ Query and response are in UTF-8, no controls other than 240 SP, "Company name" separated from URL by one or more 241 SP characters, no specification of language on either 242 input or output. 244 The authors will maintain a registry of additional variations 245 which they hope will be very short (see section 9). If this 246 specification evolves into a proposed standard after an 247 experimental period, the draft for that standard will propose that 248 the registry be turned over to IANA. 250 4. Alternatives not chosen 252 Few comments on the initial draft of this document addressed the 253 basic model or protocol design for the service discussed. 254 Instead, they focused on inquiring about the decisions we didn't 255 make and about beliefs about the protocol specification that were 256 not intended by the authors. The latter have been, we hope, 257 corrected. Questions of the following three types predominated in 258 the first category. 260 4.1. Why didn't you use ? 262 Many notes raised the question of how much more could be done with 263 a higher-powered directory protocol rather than the extremely 264 simple WHOIS. Questions were raised about LDAP, X.500 DAP, CCSO, 265 RWHOIS, and WHOIS++. We had several reasons for avoiding them. 266 The most important has been a strong commitment to see how much 267 can be done with an extremely simplistic approach, and WHOIS 268 represented the most simplistic approach we could find. If it 269 turns out to be too simple in practice, things can always evolve 270 to one or more of the more advanced protocols. But, if we 271 started with one of them, we would never get that information. 272 Other issues included: 274 * None of the existing directory proposals has really emerged as 275 the "right" solution with a large installed base. The deployed 276 base of WHOIS and WHOIS clients is huge, and using it avoids 277 either having to make a premature choice of "winner" or to 278 become embroiled in the debate. 280 * For the casual user, the mechanisms needed to activate the 281 extensive attribute-based directory searches of the stronger 282 protocols are just too complicated and may actually act as a 283 deterrent to effective use. 285 * Substantially since the dawn of the ARPANET, the Internet 286 experience has been that setting up a directory service is easy, 287 but that maintaining one and keeping the records up-to-date is 288 extremely difficult. The economics of operating an effective 289 directory service and keeping everything up to date may will 290 require a revenue-producing product. Use of a very simple 291 protocol for the basic service creates a situation in which 292 basic service can rationally be given away while more advanced 293 service are operated on a charge or subscription basis. 295 4.2 And why not use a Web search engine? 297 Web search engines are immensely effective and powerful, but 298 address a different problem than this protocol. The protocol 299 model here does involve a directory lookup, using a presumed 300 company name as a key. The quality of the result will depend 301 on the quality of the underlying directory and the editorial and 302 research work that goes into its construction (neither of which 303 are matters for the protocol itself -- we trust that marketplace 304 pressures will separate good servers from poor ones). Web search 305 engines are often more effective at locating information about 306 companies than the specific company-designated web pages. 308 4.3. Why not return a more highly structured information format 309 rather than a simple pair of URL and "company name"? 311 Again, the goal was to keep things extremely simple and, in 312 particular, permit minimal interpretation between the user's input 313 and the query and between the response and a display or action. 314 Some of the inquiries on this subject were due to 315 misunderstandings about the implications of the "company name" 316 field; the semantics of that field have been clarified above. We 317 also wanted to avoid the level of standardization implied by a 318 tagging scheme: highly-structured fields might lead either to 319 interoperability problems or excessive restriction on what might 320 be returned. 322 5. Thoughts on Directory Providers 324 There is no technical reason why there should be only one provider 325 of company name to URL mapping services using this protocol, nor 326 is there any reason for registries of such providers. Presumably, 327 servers that provide the best-quality mappings will eventually 328 prevail in the marketplace. However, as with most traditional 329 uses of WHOIS, it is desirable for implementations of clients (or 330 Web browsers supporting this protocol) to allow for user choice of 331 servers through configuration options or the equivalent. 333 6. References 335 [RFC1591] J. Postel, "Domain Name System Structure and 336 Delegation", RFC 1591, March 3, 1994 338 [GOPHER] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. 339 John, D. Torrey, B. Alberti, "The Internet Gopher Protocol 340 (a distributed document search and retrieval protocol)", 341 RFC 1436, 03/18/1993. 343 [LDAP] W. Yeong, T. Howes, S. Kille, "Lightweight Directory 344 Access Protocol", RFC 1777, 03/28/1995. 346 [RWHOIS] S. Williamson, M. Kosters, "Referral Whois Protocol 347 (RWhois)", RFC 1714, 12/15/1994. 349 [URL] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform 350 Resource Locators (URL)", RFC 1738, December 20, 1994. 352 [WHOIS] E. Feinler, K. Harrenstien, M. Stahl, "NICNAME/WHOIS", 353 RFC 954, 0/01/1985. 355 [WHOIS++] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, 356 "Architecture of the WHOIS++ service", RFC 1835, August 16, 357 1995. 359 [X500] R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. 360 Yeong, "Recommendations for an X.500 Production Directory 361 Service", RFC 1803, 06/07/1995. 363 [Z39.50] C. Lynch, "Using the Z39.50 Information Retrieval 364 Protocol in the Internet Environment", RFC 1729, 12/16/1994. 366 7. Security Considerations 368 This suggested use of the WHOIS protocol adds no significant 369 security risks to those of traditional applications of the 370 protocol which is one of the most widely-deployed applications on 371 the Internet. As usual, servers should expect to use the string 372 sent to them as an information retrieval key, not as a function to 373 be executed in some way. A more significant risk would arise if 374 the server supporting the translation function were somehow 375 spoofed; in that case, an incorrect URL might be returned for a 376 particular company. As with the possibility of finding an 377 incorrect page using naming conventions, the best protection 378 against the risks that could then occur is careful attention to 379 certificates, signatures, and other authenticity-indicating 380 information. 382 8. Acknowledgements 384 This memo was inspired by a many discussions over the last few 385 years about the status and uses of the domain name system, 386 information location using conventions about domain names, 387 exposure of URLs to end users, and convergence of directory and 388 search protocols. While the people involved are too numerous to 389 attempt to list, the authors would like to acknowledge their 390 contributions and comments. 392 Martin Hamilton, Keith Moore, and Gary Oglesby made important 393 suggestions that have contributed to the revision of this draft. 395 9. Authors' Address 397 John C. Klensin 398 MCI Internet Architecture 399 800 Boylston St, 7th floor 400 Boston, MA 02199 401 USA 402 Email: klensin@mci.net 403 Tel: +1 617 960 1011 405 Ted Wolf, Jr. 406 Electronic Commerce 407 Dun & Bradstreet Information Services 408 3 Sylvan Way 409 Parsippany, NJ 07054 410 USA 411 Email: ted@usa.net 412 Tel: +1 201 605 6308 414 Address for purposes of registering variants only: 415 url-whois@alpha1.reston.mci.net