Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06845; 1 Jul 92 15:07 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06841; 1 Jul 92 15:07 EDT Received: from NNSC.NSF.NET by NRI.Reston.VA.US id aa24173; 1 Jul 92 15:08 EDT Received: from nnsc.nsf.net by NNSC.NSF.NET id aa25308; 1 Jul 92 14:50 EDT Received: from venera.isi.edu by NNSC.NSF.NET id aa25304; 1 Jul 92 14:48 EDT Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 1 Jul 1992 11:50:19 -0700 Date: Wed, 1 Jul 1992 11:48:32 -0700 From: jkrey@isi.edu Posted-Date: Wed, 1 Jul 1992 11:48:32 -0700 Message-Id: <199207011848.AA02353@akamai.isi.edu> Received: by akamai.isi.edu (5.65c/4.0.3-4) id ; Wed, 1 Jul 1992 11:48:32 -0700 To: us-wg@nnsc.nsf.net Subject: IETF User Services Area Sessions/BOFs Boston IETF Cc: jkrey@isi.edu IETF User Services Area Sessions/BOFs IETF - Boston Monday, July 13, 1992 1:30-3:30 pm Internet School Networking WG (isn) Tuesday, July 14, 1992 9:30-12:00N User Documents WG (userdoc2) 1:30-3:30 pm Internet User Glossary WG (userglos) 4:00-6:00 pm Internet User Glossary WG (userglos) Wednesday, July 15, 1992 9:30-12:00N User Services WG (uswg) - (NOCTOOLs will meet during the first 30 minutes of this session.) 1:30-3:30 pm Internet Anonymous FTP Archives WG (iafa) 4:00-6:00 pm Network Information Services Infrastructure WG (nisi) 7:00-10:00pm Directory Resources Engineering Group BOF (dregs) Thursday, July 16, 1992 1:30-3:30 pm Directory Information Services Infrastructure WG (disi)   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ac08841; 2 Jul 92 17:42 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08837; 2 Jul 92 17:42 EDT Received: from NNSC.NSF.NET by NRI.Reston.VA.US id aa03958; 2 Jul 92 17:43 EDT Received: from nnsc.nsf.net by NNSC.NSF.NET id aa04926; 2 Jul 92 17:23 EDT Received: from venera.isi.edu by NNSC.NSF.NET id aa04922; 2 Jul 92 17:21 EDT Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 2 Jul 1992 14:23:27 -0700 Date: Thu, 2 Jul 1992 14:21:47 -0700 From: jkrey@isi.edu Posted-Date: Thu, 2 Jul 1992 14:21:47 -0700 Message-Id: <199207022121.AA04408@akamai.isi.edu> Received: by akamai.isi.edu (5.65c/4.0.3-4) id ; Thu, 2 Jul 1992 14:21:47 -0700 To: us-wg@nnsc.nsf.net Subject: USWG AGENDA - Boston IETF Cc: jkrey@isi.edu User Services Working Group Agenda IETF - Boston Wednesday, July 15th, 1992 9:30am-12N Chair: Joyce K. Reynolds/ISI (jkrey@isi.edu) Discussions/Reports: 1) NOCTOOLS2 - Robert Enger The NOCTOOLS2 catalog is quickly coming to closure. The first 20-30 minutes of this USWG session is for us to put in our last two bits to Robert before the catalog is submitted as an to I-D. 2) "Internet Guide for New Users", book in progress by Dan Dern (McGraw/Hill Publishers). a) What Dan is doing. b) Perception of some of the need of these types of books. c) Other similar activities (Zen, EFF, SRI NISC, SIGUCCS, etc.) d) Publishers and Contracts - pointers for authors. e) What has he learned?? 3) Jill Foster - an update on RARE activities, including a report on the RARE Information Services/User Services (ISUS) activities. 4) Peter Deutsch - "Internet Quick and Dirty" (Document on descriptions of each network service with pointers on where to obtain additional information.) 5) Ideas/thoughts about a WG on training materials a) A joint effort between RARE & IETF?   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09223; 6 Jul 92 11:37 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09219; 6 Jul 92 11:37 EDT Received: from NNSC.NSF.NET by NRI.Reston.VA.US id aa07924; 6 Jul 92 11:39 EDT Received: from nnsc.nsf.net by NNSC.NSF.NET id aa26157; 6 Jul 92 11:06 EDT Received: from [192.52.179.2] by NNSC.NSF.NET id aa26152; 6 Jul 92 11:05 EDT Received: from BITNIC.EDUCOM.EDU by bitnic.educom.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6456; Mon, 06 Jul 92 11:04:42 EDT Received: from BITNIC (CONKLIN) by BITNIC.EDUCOM.EDU (Mailer R2.05) with BSMTP id 6453; Mon, 06 Jul 92 11:04:37 EDT Date: Mon, 06 Jul 92 11:02:11 EDT From: Jim Conklin Subject: Re: Training materials To: Jill.Foster@newcastle.ac.uk, us-wg@nnsc.nsf.net, Margaret.Isaacs@newcastle.ac.uk In-Reply-To: Message of Mon, 29 Jun 92 18:58:35 BST from Message-ID: <9207061139.aa07924@NRI.Reston.VA.US> We have, in LISTSERV@BITNIC (LISTSERV@bitnic.educom.edu), a variety of materials on BITNET and its use, which you're welcome to include in your resources if you like. This is one, which gets you started. Jim BITNET Network Information Center BITNET INTRO 03/29/90 EDUCOM, Suite 600, 1112 16th St, NW, Washington, DC 20036I 202-872-4200 (c) Copyright CREN 1990,1991. May be reproduced with credit. USING BITNET AN INTRODUCTION by James B. Conkin, Jr. I. BASIC ELECTRONIC MAIL * To send and receive electronic mail (e-mail), use your local mailer software or special Wide-Area mailer. It should properly handle the Domain-style e-mail names and headers, to allow you to communicate between BITNET and the Internet. Unfortunately, most of the hardware- vendor-supplied software does not do this yet, so your system must probably include non-vendor software. The mailer software and the user interface differ from system to system, unfortunately, but there are common elements: * Determine your correspondent's e-mail address. Use the phone, just as you would to learn her postal address. There's no e-mail "phone book" (frequently referred to as "directory service" or "white pages") yet. Sometime in the future, there will likely be widespread, distributed directory service, based on the new international directory- services standard X.500. * Supply the address of your correspondent. Your mailer software will usually prompt you for a "To:" address, which must be the BITNET or Internet address of the person (or list) you wish to receive your mail. Examples might be To: CONKLIN@BITNIC a BITNET address To: CONKLIN@BITNIC.BITNET Your mailer may require the ".BITNET" for BITNET mail, even though ".BITNET" is not a real Internet domain. To: Conklin@bitnic.educom.edu an Internet address The first part of the address (to the left of the at-sign) is the user- name (often called user-ID) of the person, or software package such as LISTSERV, to which the mail is to be sent. The second is the name of the node (network-connected computer) on which the person has this user- name; in the case of Internet addresses, this is a node name and domain names, separated by periods, which together define a unique node. In the above examples, "CONKLIN" and "Conklin" are user-names, "BITNIC" a node name, "educom" a second-level domain name, and "edu" the top-level domain name. * Supply the subject of the message. Although this is optional, many people who receive a lot of electronic mail are guided by the stated subject in their reading of mail, and if your message is missing a subject line it may not get read. Your mailer software will probably prompt you for a subject. You should supply a brief description of the topic of your message, for example: Subject: Let's party Friday! Subject: A Protocol for File-Transfer Services * Supply the text of your message. Many mail software packages limit lines to 80 characters and some even add characters to lines to fill them out to 80 characters. Your mail package may be based on the editor you usually use or a different one. Most mail software includes a facility for mailing a text file which you have created separately, which is often most convenient for long messages. If you compose your mail on a personal computer or workstation, be sure to somehow get carriage returns at the ends of your lines, or they may be transmitted to your recipient as though you had typed one very long line of text, making it difficult to read! * Send your message. This is specific to the particular mail system you may be using. II. USING LISTSERV E-MAIL DISCUSSION LISTS What List to Join? * To get a list of all public LISTSERV lists, send mail to LISTSERV@BITNIC or to LISTSERV at any other LISTSERV site, with any (or no) subject and the single line of text: LIST GLOBAL which will cause LISTSERV to send you a non-mail file, "LISTSERV LISTS," containing all public lists on all LISTSERVs. You will usually have to RECEIVE this file in order to print or manipulate it. Check your local documentation for information about the RECEIVE command on your system. You may or may not be notified about files waiting to be RECEIVEd. If your mail is sent to LISTSERV from an Internet address, LISTSERV will send the file as a mail message, in order for it to pass through the BITNET<->Internet gateway. The LISTSERV LISTS file will contain the name of each public LISTSERV list (list_name), the node of the LISTSERV from which the list is distributed (there may be more than one), and a brief discription of the list's intended function. There are about a thousand active lists, covering most topics of academic interest, so you are likely to find lists to satisfy your interests! * To learn more about the intended use of a list and its subscribers, send mail to LISTSERV@node, where "node" is the node shown in the LISTSERV LISTS file for the list in which you are interested. Use any (or no) subject, and the single line of text REVIEW list_name in which "list_name" is the name of the LISTSERV list as shown in the file. For, example, the text REVIEW LIAISON sent in a mail message to LISTSERV@BITNIC will cause a file containing the description, characteristics, and subscribers for the LIAISON list to be sent to you. Unless you are sending from an Internet address, the file will be non-mail, and you will probably have to RECEIVE it. Using LISTSERV Lists * To subscribe a list (become a participant in the discussion), send mail to LISTSERV@node with any (or no) subject, and one line of text: SUB list_name "your_name" For example, send mail to LISTSERV@BITNIC with the message text SUB LIAISON "Jim Conklin" NOTE: THE MAIL MUST BE SENT TO LISTSERV, NOT TO list_name! * To communicate with the subscribers to a list, send mail to list_name@site just as if it were a person's mail address. Send a regular mail message with a descriptive subject and the text you wish the list participants to receive. For example, send the message to LIAISON@BITNIC. Note that the message should be consistent with the intended purpose of the list and with the CREN Acceptable Use Policy (CREN NET_USE from LISTSERV@BITNIC). NOTE: Most LISTSERVes will not send you a copy of mail you send to the list. * To unsubscribe from a list (get off it), send mail to LISTSERV@node with the message: UNSUB list_name and any (or no) subject. For example, send mail to LISTSERV@BITNIC with the message UNSUB LIAISON NOTE: THE MAIL MUST BE SENT TO LISTSERV, NOT TO list_name! It must be sent from the same e-mail address which you used to subscribe to the list, and it must be sent to the LISTSERV node from which your list mail is being sent to you. If you have difficulty in unsubscribing, you may wish to have LISTSERV REVIEW the list for you, as described above, in order to see what user-name and node LISTSERV shows for your subscription. A Few Useful Lists * BITNEWS@BITNIC (via LISTSERV@BITNIC), the official BITNIC list for administrative and policy announcements * TECHNEWS@BITNIC (via LISTSERV@BITNIC), the official BITNIC list for technical announcements -- a must for those managing BITNET nodes * CCNEWS@BITNIC (via LISTSERV@BITNIC), for timely articles of interest to University computing centers and the people who use them * LIAISON@BITNIC (via LISTSERV@BITNIC), for topics of interest to campus supporters of BITNET users and services * NODMGT-L@BITNIC (via LISTSERV@BITNIC), for discussions related to managing BITNET nodes * NETMONTH@YALEVM (via LISTSERV@YALEVM), a newsletter featuring a variety of excellent articles about BITNET, currently in limbo but hopefully to be resumed in the near future. III. GETTING DOCUMENTS AND OTHER FILES FROM LISTSERV Ordering Files from LISTSERV@BITNIC * To learn about documents available, get, as described below, the LISTSERV file NETINFO FILELIST, which lists names and short descriptions of documentation about the network available from LISTSERV@BITNIC. To learn even more, get the LISTSERV file LISTSERV FILELIST, which lists all FILELISTs on LISTSERV. Other LISTSERVs have similar FILELIST files. * Note that all LISTSERV files have two-part names! In IBM parlance, the first part is known as the file-name and the second as the file- type, but this guide will treat both parts as a single name for simplicity. * To order a file once you know its name, send a mail message to LISTSERV@BITNIC with any (or no) subject, and the message text SENDME file_name in which "file_name" is the (two-part) name of the file, with a space separating the second part from the first. For example, send mail to LISTSERV@BITNIC with the message text SENDME NETINFO FILELIST to obtain the file NETINFO FILELIST, which you must then RECEIVE. You may substitute the word GET or SEND for SENDME in LISTSERV requests. You may also submit several requests, each on its own line, to LISTSERV in a single mail message. Some Useful Documents from LISTSERV@BITNIC Documents About Using BITNET: Rules and Instructions CREN NET_USE, the CREN Acceptable Use Policy for BITNET and CSNET CREN TERMS, CREN Terms and Conditions of membership, including special requirements for BITNET participation BITNET INTRO, this introduction to using BITNET BITNET USERHELP, a good introductory manual by Chris Condon LEGAL COMMERCE, a copy of an advisory letter from the US Department of Commerce describing the implications to CREN and its members, of BITNET international connectivity LEGAL COUNSEL, a copy of an opinion from CREN's counsel on the legal implications to CREN and its members of BITNET international connectivity LEGAL GTDA, a copy of the US Commerce Department rules defining information which may be distributed outside the USA without special license BITNETJP NET_USE, the Acceptable Use Policy of the Japan BITNET Association, covering Japan, Korea, and Taiwan SCARNET NET_USE, the Acceptable Use Policy of the Southern Cone Academic and Research Network, which includes Chile, Argentina, Peru, and Uruguay Descriptions of BITNET and Its Services, and of CREN BITNET OVERVIEW, a brief description of BITNET BITNET TOPICS, a list of topics covered by BITNET discussion lists INTERNTL SITELIST, BITNET sites outside the United States, organized by country STATE SITELIST, BITNET sites within the US, sorted by member name within state NODE INFO1, a list of nodes and their descriptions, sorted by node- name NODE INFO2, a list of nodes and their descriptions, sorted by node description NETINFO FILELIST, a list of many of the documents available from LISTSERV@BITNIC TOOLS FILELIST, a list of the software-tools files available from LISTSERV@BITNIC BITNET SERVERS, a list of LISTSERV and other servers on BITNET, with information on the services they provide and on how to access those services CREN COST, the cost of CREN membership and services CREN BYLAWS, the Bylaws of BITNET's parent corporation CREN BOARD, the current CREN Board of Trustees BOARD MINUTES, the minutes of the most recent meeting of the CREN Board BDyymm MINUTES, minutes of the Board meeting held in month "mm" of year"yy" WHY CREN, Reasons for continuing an organization's membership in CREN, promolgated by the CREN Board in February, 1990 Information for Supporting a BITNET Node UPDATE PROCEDUR, the manual which documents the procedures to be followed in sending to BITNIC the updates to node and member information, and the information required to add new nodes REQUIRED INFO1, a description of the specific "tags", or information items, which are sent to UPDATE@BITNIC using the procedures described in UPDATE PROCEDUR DOMAIN NAMES, used by mailer software for routing mail through the appropriate gateways to various Internet domains XMAILER NAMES, also used by mailer software, for routing mail to mail transfer agents at recipient nodes MAILER NAMES, similarly used, for mail to mail-only nodes IV. NETSERV AS A SOURCE OF DOCUMENTS AND OTHER INFORMATION Ordering Files from NETSERV@BITNIC * To learn about documents available, get the NETSERV file NETSERV FILELIST, which is completely analogous to the LISTSERV FILELIST available from LISTSERV. Note that all NETSERV files also have two-part names. * To order a file once you know its name, send a mail message to NETSERV@BITNIC with any (or no) subject, and the message text SENDME file_name in which "file_name is the (two-part) name of the file, with a space separating the second part from the first. For example, send mail to LISTSERV@BITNIC with the message text SENDME NETSERV FILELIST to obtain the file NETSERV FILELIST, in complete parallel to the LISTSERV request. As with LISTSERV, SEND or GET may be substituted for SENDME. Some Useful Documents from NETSERV@BITNIC Information About BITNET NODENTRY node_name, the BITEARN NODES information about the node "node_name", which will be sent as a file named node_name NODENTRY (note the reverse order of the two parts) Information for Supporting a BITNET Node BITEARN NODES, the complete file of information maintained about all nodes, worlldwide, on BITNET, EARN, and all other Cooperating Networks. This file is so large that it is restricted to Node Administrators, and even they should order it only once and update it monthly with the incremental updates. VERSyynn NODUPD, the BITEARN NODES update file number nn for year yy (since there may be extra updates distributed, nn may be larger than the number of the month) DOMAIN NAMES, used by mailer software for routing mail through the appropriate gateways to various Internet domains XMAILER NAMES, also used by mailer software, for routing mail to mail transfer agents at recipient nodes MAILER NAMES, similarly used, for mail to mail-only nodes APPENDIX A ADDITIONAL INFORMATION ABOUT LISTSERV * To receive a brief list of LISTSERV commands, send mail to your favorite LISTSERV with the text line: HELP (note, not "SENDME HELP"). LISTSERV will send you mail with a "starter list" of commands plus a list of the people responsible for the LISTSERV to which you sent the mail. * To receive a list of LISTSERV information guides, send mail to LISTSERV with the text line: INFO ? (note, not "SENDME INFO ?" and not "INFO?" without the space before the question mark). These guides may be obtained either by using the name supplied in the first column of the report, preceeded by the work "INFO" as the text of a mail message to LISTSERV, or by using the two names which follow it in parentheses as the file name of a LISTSERV file. Thus, mail to LISTSERV with the text line INFO PR (not "SENDME INFO PR") or the text line SENDME LISTPRES MEMO will cause LISTSERV to send the "Presentation of LISTSERV for New Users" document. Mail with the text line INFO GEN or SENDME LISTSERV MEMO will cause the "General Information About Revised LISTSERV" document to be sent. And mail with text line INFO REF or SENDME LISTSERV REFCARD will result in the document "Command Reference Card". * Communicating with LISTSERV Using "Interactive Messages". Many BITNET systems have the capability to use a one-line "interactive" message to send the commands described above as the text lines in mail messages to LISTSERV@node. On IBM systems running VM/CMS or MVS, these are the TELL messages, and on VAX/VMS systems, they are the SEND messages, though VAX/VMS systems which are part of clusters are, in genaral advised to use mail rather than SEND messages, as the latter may supply the cluster name to LISTSERV rather than the proper node name of the user's node. The form of such messages is simply TELL LISTSERV AT node command for the VM/CMS or MVS systems, or SEND LISTSERV@node command for VAX/VMS. Any command including lower-case (such as the SUBscribe command with the user's real name) must be enclosed in quotation marks (") when using the SEND command, as VMS will otherwise convert it to all-capitals. Commands which include special, non- alphanumeric, characters should be included in quotation marks when using either TELL or SEND commands. Neither can be used from an Internet address. Examples: TELL LISTSERV AT BITNIC SUB LIAISON Jim Conklin SEND LISTSERV@BITNIC SUB LIAISON "Jim Conklin" TELL LISTSERV AT BITNIC REVIEW LIAISON SEND LISTSERV@BITNIC REVIEW LIAISON   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10898; 8 Jul 92 19:41 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10894; 8 Jul 92 19:41 EDT Received: from NNSC.NSF.NET by NRI.Reston.VA.US id aa08883; 8 Jul 92 19:43 EDT Received: from nnsc.nsf.net by NNSC.NSF.NET id aa18435; 8 Jul 92 19:31 EDT Received: from venera.isi.edu by NNSC.NSF.NET id aa18431; 8 Jul 92 19:31 EDT Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 8 Jul 1992 16:32:36 -0700 Date: Wed, 8 Jul 1992 16:30:55 -0700 From: jkrey@isi.edu Posted-Date: Wed, 8 Jul 1992 16:30:55 -0700 Message-Id: <199207082330.AA02488@akamai.isi.edu> Received: by akamai.isi.edu (5.65c/4.0.3-4) id ; Wed, 8 Jul 1992 16:30:55 -0700 To: us-wg@nnsc.nsf.net Subject: Agenda - Directory Resources Engineering Group BOF Cc: jcgargano@ucdavis.edu, jkrey@isi.edu AGENDA Directory Resources Engineering Group BOF Joan Gargano/UC-Davis, Joyce K. Reynolds/ISI Wednesday, July 15th, 1992 7:00-10:00pm What do we have? I. Review of current whois servers 1) Hostnames used for whois service for a domain 2) Review of information content 3) Review of information display 4) Review of help responses What do we want? II. Definition of desired information content 1) People 2) Machines 3) Domains 4) Services III. Review of user interface issues 1) Supported query types 2) Amount and appropriateness of help information 3) Support of electronic mail queries IV. Providing a coordinated whois service 1) Automatic registration of local database entries in the NIC database. 2) Usage guidelines 3) Hostname consistancy V. Options 1) Whois 2) WAIS 3) Functional X.500 over IP (one that works with a good response time and requires reasonable amounts of system resources). VI. Review/Discussion of draft WG charter VII. Review/Discussion of draft document, "Specifications for WHOIS Services"   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10975; 8 Jul 92 20:01 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10971; 8 Jul 92 20:01 EDT Received: from NNSC.NSF.NET by NRI.Reston.VA.US id aa09402; 8 Jul 92 20:03 EDT Received: from nnsc.nsf.net by NNSC.NSF.NET id aa18453; 8 Jul 92 19:33 EDT Received: from venera.isi.edu by NNSC.NSF.NET id aa18449; 8 Jul 92 19:32 EDT Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 8 Jul 1992 16:34:32 -0700 Date: Wed, 8 Jul 1992 16:32:48 -0700 From: jkrey@isi.edu Posted-Date: Wed, 8 Jul 1992 16:32:48 -0700 Message-Id: <199207082332.AA02492@akamai.isi.edu> Received: by akamai.isi.edu (5.65c/4.0.3-4) id ; Wed, 8 Jul 1992 16:32:48 -0700 To: us-wg@nnsc.nsf.net Subject: draft document: "Specifications for WHOIS Services" Cc: jcgargano@ucdavis.edu, jkrey@isi.edu USWGers, Enclosed is a discussion paper that we will be going over during the Directory Resources Engineering Group BOF on Wednesday, July 16 - 7-10pm. Joyce & Joan ========================================================================= Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano User Services DREGs Ken Weiss Discussion Paper University of California, Davis July 8, 1992 Joan Gargano University of California, Davis Specifications for WHOIS Services Status of this Memo This paper proposes changes to the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is intended to update RFC 954. Distribution of this memo is unlimited. Introduction As currently defined, NICNAME/WHOIS service is a TCP transaction based query/response server, running on a few specific central machines, that provides netwide directory service to Internet users. The Network Information Center (NIC) maintains the central NICNAME database and server, defined in RFC 954, providing online look-up of individuals, network organizations, key host machines, and other information of interest to users of the Interrnet. Newer distributed directory information servers and information retrieval tools have been developed and it is anticipated more will be created. Many sites now maintain local directory servers with information about individuals, departments and services at that specific site. Typically these directory servers are network accessible. Local development of these services has resulted in wide variations in the type of data stored, access methods, search schemes, and user interfaces. The purpose of the Directory Resources Engineering Group (DREGs) is to expand and define the standard for WHOIS types of services, to resolve issues associated with the variations in access and the advent of new information retrieval applications and provide a consistent and predictable service across the network. This paper describes features for consideration. Architecture WHOIS service should be provided in a client/server model. There are no restrictions on the design of the client, provided it is capable of passing queries to the server in the proper format, and capturing the server's response in some useful format. Existing WHOIS specifications call for clients to display responses in human-readable form. This more general proposal does not impose that restriction. This discussion paper acknowledges the existance of many distributed directory information servers, and anticipates the creation of many more. To help users locate WHOIS servers, each directory server should be registered with the central NICNAME system. Each distributed server should have a domain name in the form "directory.domain", so that a search in the NICNAME database for "directory" will return a list of all distributed WHOIS servers and their IP addresses. The distributed servers should have a mechanism for automatically forwarding registration information to the central NICNAME database. A field in the local data specification identifies whether or not a given record should be forwarded to the NIC for central registration. Client Design and Behavior The client provides the user interface to the WHOIS/NICNAME system, providing a mechanism for query generation and display of the response. The client is responsible for providing support for paging of long output from the server. All clients must provide this service. The server will not include any special charaters, or make any efforts to control output to a screen. Special search criteria may be specified by the use of keywords or special characters, some of which are defined in RFC 954. Clients should be designed to make support for quoted strings unnecessary. All text that follows the last keyword and precedes the CR/LF should be stripped of leading blanks and passed to the server as a single string. Server Design and Behavior The server should return the same information in response to a given query consistently, regardless of the client software or the hardware used to originate the query. Queries should be evaluated on a case-insensitive basis. Spaces should not be considered in searches. A search for "La Russo" should return both "LaRusso" and "La Russo" as matches. Search Options A unique handle must be provided for every record in the server database to target specifc records for display. For example, if there are three individuals named, respectively, A. La Russo, B. LaRusso, and C. Larusso, then a search for "LA RUSSO" would return all three as matches. However, each record would have a unique handle: LARUSSO1, LARUSSO2, AND LARUSSO3. A search for any one of these handles would return a single match for that particular individual. whois !SMITH1 exact match on the handle, SMITH1 whois handle SMITH1 whois smith exact match on last name whois smith,j exact match on last name, whois "smith,j" first name begins with "J" whois j. Smith whois "j. Smith" whois smith, john exact match on last and first names whois "smith, john" whois john Smith whois "john Smith" whois .john Smith whois "smith..." all last names beginning with Smith whois smith* whois begins smith whois smith?? all last names beginning with "Smith" and containing up to two letters after "Smith", i.e. "Smith", "Smithy", "Smithey" and "Smithie" whois ends smith all last names ending in "smith" whois exact A Martinez exact match for "A Martinez" whois fuzzy paulson all last names that sound like or are spelled like "Paulson" whois first Kazuko exact match on first name "Kazuko" whois first begins Art all first names beginning with "Art" whois first fuzzy Kasuko all first names that sound like or are spelled like "Kasuko" whois hamlet.ucdavis.edu IP address and other information on whois system hamlet.ucdavis.edu the computer called hamlet.ucdavis.edu. Could be served by a domain name service querytype (QTYPE) * whois system hamlet IP address and other information on the computer called hamlet with the default domain appended. Could be served by a domain name service querytype (QTYPE) * whois 128.120.2.9 domain name and other information on whois system 128.120.2.9 the computer at specified IP address. Could be served by a domain name service querytype (QTYPE) PTR. whois !ucdavis-dom site contacts and other information whois domain ucdavis.edu on the site ucdavis If any keywords are specified in the query, the server will complete that specific query and return the results (even if 0 matches are found). If no keywords are specified, the server will interpret the query based upon the rules above. Optionally, the server may be configured so that if a search yields no matches, the query will automatically be run again, but with the keyword begin inserted. Servers must support multiple levels of detail in response to queries. A query yielding multiple matches should return a short-form record for each match. A query yielding a single match should return a long-form record. A query yielding no matches should return context-senstive help on expanding the search criteria. On-line Help Every query should return a minimal (two line) help message. That message should identify the database being searched and provide instructions for the user to obtain more detailed help screens. Additional minimal help should be provided in special situations. The server should recoginze queries that return zero matches, and provide a brief help message explaining how to broaden a search. If a search returns more than 50 matches,the server should take two actions. First, the user should get a message explaining how to narrow searches. Second, the user should be offered the option of re-specifying the search, or receiving all matching responses. When multiple matches are found and returned to the client, the server should add a brief help message explaining how to use handles to narrow the search to a single record. If the client queries for "help" or "?" then the server should return a complete help file. The help file should contain most of the information in this memo, in sufficient detail for the user to understand and access all the features of WHOIS service. Information Content There are three types of data records supported in this proposal: records for people, hosts, and domains. Individual records Name required Organization required Work telephone optional Fax telephone optional Work address optional Title/Academic status optional Department/Unit/Major optional Electronic mail address optional Handle (server generated) required Forward information to NIC (Y/N) required Last update required Home telephone optional Home address optional Host records Full domain name required IP address required System administrator name optional System administrator telephone optional System administrator address optional System administrator e-mail address optional Type of machine optional Operating system optional Mail exchanger optional Last update optional Location of additional information optional (i.e. anonymous FTP) The data record for a domain should contain the following fields: Domain name required Administrative contact name required Administrative contact telephone required Administrative contact address required Administrative contact e-mail address required Technical contact name required Technical contact telephone required Technical contact address required Technical contact e-mail address required Domain nameservers optional Last update required Example of a friendly system $ whois -h argus.stanford.edu yundt Stanford University Whois Service "whois help" for general info | Problems to "whois-problem@networking" "whois update" for entry update info | Comments to "help@networking" name: Yundt, William H e-mail: gd.why@Forsythe organization: University department: Networking/Communication Sys position: Dir Networking/Comm address: Pine Hall 115 phone: (415) 723-3104 mail-code: 4122 home-address: 817 Lurline Drive, Foster City, Ca, 94404 handle: wyundt updated-by: download date-updated: May 22 1992 8:58PM Example of an unfriendly system $ whois -h uc.edu weiss WHOIS Server says hello to othello.ucdavis.edu [128.120.2.72] WHOIS Server received the following parameter: weiss Parameter Length = 7 User is Gary Weiss WHOIS Server end program. $ whois -h uc.edu "Gary Weiss" WHOIS Server says hello to othello.ucdavis.edu [128.120.2.72] WHOIS Server received the following parameter: Gary Weiss Parameter Length = 12 Unknown user... or other error! WHOIS Server end program. $ whois -h uc.edu help WHOIS Server says hello to othello.ucdavis.edu [128.120.2.72] WHOIS Server received the following parameter: help Parameter Length = 6 Unknown user... or other error! WHOIS Server end program. User Services DREGs 7 Specifications for WHOIS Services   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa11244; 8 Jul 92 20:26 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa11240; 8 Jul 92 20:26 EDT Received: from NNSC.NSF.NET by NRI.Reston.VA.US id aa10223; 8 Jul 92 20:28 EDT Received: from nnsc.nsf.net by NNSC.NSF.NET id aa18540; 8 Jul 92 20:02 EDT Received: from uu2.psi.com by NNSC.NSF.NET id aa18536; 8 Jul 92 20:01 EDT Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA29893; Wed, 8 Jul 92 20:00:47 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA26912; Wed, 8 Jul 92 16:59:34 PDT Message-Id: <9207082359.AA26912@aland.bbn.com> To: us-wg@nnsc.nsf.net Subject: re: draft document: "Specifications for WHOIS Services" Cc: jcgargano@ucdavis.edu, jkrey@isi.edu Reply-To: Craig Partridge From: Craig Partridge Date: Wed, 08 Jul 92 16:59:34 -0700 Sender: craig@aland.bbn.com Hi folks: I probably won't be at IETF so I wanted to get in my comments quickly now. Host records and Domain records should optionally include FAX numbers. Domain in particular -- having someone's e-mail address is no good if her or his domain server is dead, and if they're 12 timezones away, a phone number is no good either. FAX is cheaper and more effective than express mail! Thanks! Craig   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09217; 10 Jul 92 16:35 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09213; 10 Jul 92 16:35 EDT Received: from NNSC.NSF.NET by NRI.Reston.VA.US id aa00725; 10 Jul 92 16:37 EDT Received: from nnsc.nsf.net by NNSC.NSF.NET id aa15531; 10 Jul 92 16:16 EDT Received: from phoebus.nisc.sri.com by NNSC.NSF.NET id aa15527; 10 Jul 92 16:14 EDT Received: by phoebus.nisc.sri.com (5.64/SRI-NISC1.1) id AA00597; Fri, 10 Jul 92 13:12:08 -0700 From: April Marine Message-Id: <9207102012.AA00597@phoebus.nisc.sri.com> To: us-wg@nnsc.nsf.net Subject: NISI WG Agenda Date: Fri, 10 Jul 92 13:12:07 PDT I sent this to the NISI list already, but it occurs to me that it might be of interest to the more general list as well. Hope to see you in Boston! April Marine SRI Agenda for NETWORK INFORMATION SERVICES INFRASTRUCTURE WORKING GROUP (NISI) WEDNESDAY, July 22, 4:00 - 6:00 Primary Goal: To come up with some concrete contents for the "nethelp" doc discussed at the last meeting. 1. Announcements, etc. -- call for comments on DB Accuracy and Privacy doc 2. Status of other work. -- reminder re other 2 docs on the burner -- clarification of List of Services doc; decision re its future -- presentation of nethelp doc outline 3. Discussion/modification of nethelp outline. 4. Small group work on contents of nethelp doc based on outline. 5. Summary of what groups came up with. 6. Summary/plan of what to do next. I'd like to spend about an hour (maybe more if we're running fast) in smaller groups (#4) getting some meat on the nethelp idea. Then about a half hour summarizing and sharing the group work and clarifying the next steps. That leaves about a half hour for the initial chitchat, which probably won't take that long, but everything always takes longer than you think. See you next week!   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa13040; 14 Jul 92 0:34 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13036; 14 Jul 92 0:33 EDT Received: from NNSC.NSF.NET by NRI.Reston.VA.US id aa04882; 14 Jul 92 0:36 EDT Received: from nnsc.nsf.net by NNSC.NSF.NET id aa06918; 14 Jul 92 0:16 EDT Received: from [192.41.197.14] by NNSC.NSF.NET id aa06914; 14 Jul 92 0:14 EDT Received: by yumiko.nic.ad.jp (5.67+1.6W/6.4JAIN-1.0) id AA21489; Tue, 14 Jul 92 13:15:37 JST Return-Path: Message-Id: <9207140415.AA21489@yumiko.nic.ad.jp> To: jkrey@isi.edu Cc: us-wg@nnsc.nsf.net, jcgargano@ucdavis.edu Subject: Re: draft document: "Specifications for WHOIS Services" In-Reply-To: Your message of Wed, 08 Jul 92 16:32:48 MST. <199207082332.AA02492@akamai.isi.edu> Date: Tue, 14 Jul 92 13:15:35 +0900 From: Masaki Hirabaru Dear USWG members: I am in charge of JNIC (stands for Japan NIC). JNIC now provides an experimental whois service on NIC.AD.JP. Our whois service returns information in two languages, English and Japanese. Showing information in local language is necessary as well as in English. I hope responding language/code options would be considered when discussing the specification for whois services. Currently JNIC whois server responds in English if a query has "/e" or "/english". For example, "whois -h nic.ad.jp hirabaru/e" responds in English, and also "whois -h nic.ad.jp hirabaru/j" responds in Japanese. Default is Japanese. I won't attend IETF and BOF. -- Masaki Hirabaru JNIC