From ietf-wnils-request@ucdavis.ucdavis.edu Sat Aug 22 10:10:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03662; Sat, 22 Aug 92 10:02:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16756; Sat, 22 Aug 92 09:59:21 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03457; Sat, 22 Aug 92 09:50:21 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from ivory.educom.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03334; Sat, 22 Aug 92 09:43:32 -0700 Received: from info.educom.edu by ivory.educom.edu (5.64/A/UX-3.00) id AA12011; Sat, 22 Aug 92 12:47:41 PDT Received: by educom.edu (4.1/SMI-4.1.1) id AA14540; Sat, 22 Aug 92 12:41:07 EDT Date: Sat, 22 Aug 92 12:41:07 EDT From: mah@info.educom.edu (Marco Hernandez) Message-Id: <9208221641.AA14540@educom.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Subscribe Greetings: Please subscribe me to the ietf-wnils discussion list. ---------------------------------------------- Marco A. Hernandez CREN/BITnet 1112 16th St., NW, Suite 600 Washington, D.C. 20036 (202) 872-4200 BITnet: Marco@bitnic.bitnet Internet: mah@info.educom.edu marco@bitnic.educom.edu ------------------------------------------------ From ietf-wnils-request@ucdavis.ucdavis.edu Thu Oct 1 19:31:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12761; Thu, 1 Oct 92 19:29:01 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28000; Thu, 1 Oct 92 19:10:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11978; Thu, 1 Oct 92 19:01:34 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from punisher.cco.caltech.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11689; Thu, 1 Oct 92 18:52:49 -0700 Received: by punisher.caltech.edu (4.1/DEI:4.41) id AA04599; Thu, 1 Oct 92 18:52:41 PDT From: dank@cco.caltech.edu (Daniel R. Kegel) Date: Thu, 1 Oct 92 18:52:41 PDT Message-Id: <9210020152.AA04599@punisher.caltech.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Hello- what is state of new whois server frontends? Hello all, I'm preparing to release a whois client, uwho, and a new version of my whois server, Horton, in the near future (and have been for several months :-( ). The bits I've heard about an enhanced whois sound appealing, and I'd like to support it if possible. Where is your effort right now? I'd love to see an up-to-date copy of your proposed protocol, and if a simple server front-end implementation was ready, I'd gladly bolt it onto my stuff before releasing it. (It might be a big improvement- the whois server frontend in the new Horton right now is just egrep.) Looking forward to seeing traffic on this list, Dan Kegel (dank@alumni.caltech.edu) From ietf-wnils-request@ucdavis.ucdavis.edu Mon Oct 5 10:10:50 1992 Received: from [128.120.2.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00522; Mon, 5 Oct 92 09:20:34 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23769; Mon, 5 Oct 92 08:44:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28677; Mon, 5 Oct 92 08:37:08 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28253; Mon, 5 Oct 92 08:27:50 -0700 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16392 (mail destined for ietf-wnils@ucdavis.edu) on Mon, 5 Oct 92 11:27:24 -0400 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA29596; Mon, 5 Oct 92 11:26:53 EDT Message-Id: <9210051526.AA29596@expresso.cc.mcgill.ca> In-Reply-To: Daniel R. Kegel's message as of Oct 1, 18:52 From: peterd@bunyip.com (Peter Deutsch) Date: Mon, 5 Oct 92 15:26:52 GMT-0:02 In-Reply-To: Daniel R. Kegel's message as of Oct 1, 18:52 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: dank@cco.caltech.edu (Daniel R. Kegel), ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Hello- what is state of new whois server frontends? [ Daniel R. Kegel writes: ] > > Hello all, > > I'm preparing to release a whois client, uwho, and a new version of my whois > server, Horton, in the near future (and have been for several months :-( ). > The bits I've heard about an enhanced whois sound appealing, and I'd like > to support it if possible. > > Where is your effort right now? I'd love to see an up-to-date copy of > your proposed protocol, and if a simple server front-end implementation > was ready, I'd gladly bolt it onto my stuff before releasing it. > (It might be a big improvement- the whois server frontend in the new Horton > right now is just egrep.) There is half of a pilot server available for testing (it parsing the current command set, but doesn't yet return info in the correct format) and both Jim Fulton and Simon Spero have indicated that they plan to work on adding search engines behind this. I was side-tracked because of extensive delays in Bunyip-related business that basically killed September. It looks like this will all be wrapped up in the next day or two, and I then plan to return to the server. If all goes well a version of this server will ship as part of the archie release. Although I don't have a date on this, it will be a high priority for me. > Looking forward to seeing traffic on this list, I think the next week or two I will have something real to report. - peterd -- --------------------------------------------------------------------------- "First Dan Quayle attacks Murphy Brown as if a television character were a real person. Then of course, Murphy Brown attacked Dan Quayle as if he were a real person." - Kirk Douglas --------------------------------------------------------------------------- From ietf-wnils-request@ucdavis.ucdavis.edu Tue Oct 6 23:22:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23202; Tue, 6 Oct 92 23:11:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15549; Tue, 6 Oct 92 22:49:58 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22373; Tue, 6 Oct 92 22:41:11 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from [150.80.254.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22347; Tue, 6 Oct 92 22:39:51 -0700 Received: from cosmos.aic.co.jp ([150.80.4.1]) by aic-wide.aic.co.jp (4.1/2.7W) id AA23067; Wed, 7 Oct 92 14:39:24 JST Received: from beat.aic.co.jp by cosmos.aic.co.jp (4.0/6.4J.6-92/2) id AA22157; Wed, 7 Oct 92 14:39:22 JST Received: by beat.aic.co.jp (4.1/6.4J.6-91/1/29) id AA00666; Wed, 7 Oct 92 14:39:21 JST Date: Wed, 7 Oct 92 14:39:21 JST From: Thomas Johannsen Return-Path: Message-Id: <9210070539.AA00666@beat.aic.co.jp> To: ietf-wnils@ucdavis.ucdavis.edu Subject: structure of current whois-records I understood that this wg is going to expand and define the standard for WHOIS services. I was wondering whether there is any other document than rfc954 currently defining whois entries. I am very interested in getting to know which types of information (network, personal, ...) and which fields for each type are used now and would probably be reflected in a new standard. The background for my question is a study on the relationship between X.500 and whois records. Any pointers / hints would be appreciated. Thank you, Thomas +---------------------------------------------------------------------+ | Thomas Johannsen Internet: thomas@aic.co.jp | | AIC Systems Lab. BITNET: JOHANNSE at DDDTU1 | | Sendai (Japan) Tel: +81 22 279 3310 Fax: +81 22 279 3640 | | X.500: @c=JP@o=AIC@ou=RD@ou=NetMan@cn=Thomas Johannsen | +---------------------------------------------------------------------+ From ietf-wnils-request@ucdavis.ucdavis.edu Wed Oct 7 07:31:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07945; Wed, 7 Oct 92 07:25:19 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17472; Wed, 7 Oct 92 07:00:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07043; Wed, 7 Oct 92 06:52:02 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06933; Wed, 7 Oct 92 06:47:36 -0700 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA05226; Wed, 7 Oct 92 09:47:02 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA23652; Wed, 7 Oct 92 09:47:01 EDT Date: Wed, 7 Oct 92 09:47:01 EDT From: clw@merit.edu Message-Id: <9210071347.AA23652@home.merit.edu> To: ietf-wnils@ucdavis.ucdavis.edu, thomas@aic.co.jp Subject: Re: structure of current whois-records Thomas: I expect a new round of documents to be out in the next month.... If I find (or help write :^) ) anything I'll keep you posted. Chris From ietf-wnils-request@ucdavis.ucdavis.edu Thu Oct 8 01:20:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11174; Thu, 8 Oct 92 01:16:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29191; Thu, 8 Oct 92 00:50:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10183; Thu, 8 Oct 92 00:40:25 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10105; Thu, 8 Oct 92 00:37:19 -0700 Received: from dale.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA05636; Thu, 8 Oct 92 00:36:49 PDT From: ccjoan@bullwinkle.ucdavis.edu Date: Thu, 8 Oct 92 00:36:49 PDT Message-Id: <9210080736.AA05636@bullwinkle.ucdavis.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: First update to the discussion paper Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano This is the first update to the discussion paper presented at the July IETF on Whois service. It incorporates suggestions from the meeting. I hope this provides a good starting point for discussion. Whois and Network Information Lookup Service Whois++ Ken Weiss Joan Gargano University of California, Davis 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. Other 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 Whois and Network Information Lookup Group (WNILG) is to expand and define the standard for WHOIS types of services, to resolve issues associated with the variations in access and 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 paper acknowledges the existance of many distributed information servers, and anticipates the creation of many more. To help users locate WHOIS servers, each server should have a nameserver entry in the form "whois.domain", i.e. whois.ddn.mil. Client Design and Behavior The client provides the user interface to the WHOIS 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. 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. There are three types of data records supported in this proposal: records for people, hosts, and domains. Individual records Name Name of the individual required Organization Name of the organization required Organization-type Type of organization optional (university, commercial research) Work-telephone Work telephone number optional Fax-telephone Fax telephone number optional Work-address Work postal address optional Title Working title or position optional within an organization Department Department optional Email-address Email address in RFC 822 optional format for this individual Handle A unique identifier for required this record on the local server Last-update Date this record was last required updated Home-telephone Home telepone number optional Home-address Home postal address optional Host records Domain-name Fully qualified domain required name IP-address Complete IP address required Sysadmin Name of the System optional Administrator for this host Sysadmin-telephone Telephone number of the optional System Administrator for this host Sysadmin-address Postal address of the optional System Administrator for this host Sysadmin-email Electronic mail address in optional RFC 822 format of the System Administrator for this host Machine-type Type of machine or optional manufacturer Operating-system Operating system optional Mail-exchanger Fully qualified domain optional name of any machine acting as a mail exchanger for this host Last-update Date this record was last optional updated Domain records Domain-name Domain name registered with required the Network Information Center (NIC) Network-address Network address associated required with this domain name Admin-name Name of the Administrative required Contact for this domain Admin-address Postal address of the required Administrative Contact for this domain Admin-telephone Telepone number of the required Administrative Contact for this domain Admin-email Electronic mail address in required RFC 822 format for the Administrative Contact for this domain Tech-name Name of the Technical required Contact for this domain Tech-address Postal address of the required Administrative Contact for this domain Tech-telephone Telepone number of the required Technical Contact for this domain Tech-email Electronic mail address in required RFC 822 format for the Administrative Contact for this domain Nameservers Primary domain nameservers optional for this domain Last-update Last date this record was required updated 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, i.e. LARUSSO1, LARUSSO2, and LARUSSO3. A search for any one of these handles would return a single match for that particular individual. This is consistant with the RFC 954 query, "whois !SMITH1" Other search options which should be supported are: *** This area needs work *** 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 The client should return a minimal (two line) help message for every query sent to the server. That message should identify the database being searched and provide instructions for the user to obtain more detailed help screens. Additional help should be provided in special situations. The server should recognize 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 informaton in sufficient detail for the user to understand and access all the features of WHOIS service. Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Thu Oct 8 23:11:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13132; Thu, 8 Oct 92 23:07:02 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10396; Thu, 8 Oct 92 19:30:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09917; Thu, 8 Oct 92 19:23:05 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from [150.80.254.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09757; Thu, 8 Oct 92 19:14:51 -0700 Received: from cosmos.aic.co.jp ([150.80.4.1]) by aic-wide.aic.co.jp (4.1/2.7W) id AA11051; Fri, 9 Oct 92 11:13:50 JST Received: from beat.aic.co.jp by cosmos.aic.co.jp (4.0/6.4J.6-92/2) id AA06061; Fri, 9 Oct 92 11:13:49 JST Received: by beat.aic.co.jp (4.1/6.4J.6-91/1/29) id AA00377; Fri, 9 Oct 92 11:13:49 JST Date: Fri, 9 Oct 92 11:13:49 JST From: Thomas Johannsen Return-Path: Message-Id: <9210090213.AA00377@beat.aic.co.jp> To: jcgargano@ucdavis.ucdavis.edu Subject: Re: First update to the discussion paper Cc: ietf-wnils@ucdavis.ucdavis.edu > From: jcgargano@ucdavis.edu > This is the first update to the discussion paper presented at the July IETF > on Whois service. It incorporates suggestions from the meeting. I hope > this provides a good starting point for discussion. It certainly does. > There are three types of data records supported in this > proposal: records for people, hosts, and domains. I am aware of at least one more type which is quite useful: network. >From several whois queries I learnt that at least the following attributes are supported for a Network Record: Network number (class A/B/C-IP) Network name (as resgistered with assigning authority) Organization (owner of network) Address (of organization) description Administrative contact (pointer to person) Technical contact (pointer to person) Nameserver State ((not) connected / ...) Date (I suppose of getting into this state) Last update I would suggest first to compile a list of currently used record types and attributes (simply by querying top-level whois servers or asking their sys-admins). Some sites might have very interesting and unconventional entries. The new proposal should then select a useful set of these records and attributes for standardization. Thomas +---------------------------------------------------------------------+ | Thomas Johannsen Internet: thomas@aic.co.jp | | AIC Systems Lab. BITNET: JOHANNSE at DDDTU1 | | Sendai (Japan) Tel: +81 22 279 3310 Fax: +81 22 279 3640 | | X.500: @c=JP@o=AIC@ou=RD@ou=NetMan@cn=Thomas Johannsen | +---------------------------------------------------------------------+ From ietf-wnils-request@ucdavis.ucdavis.edu Sun Oct 11 00:20:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01666; Sun, 11 Oct 92 00:14:18 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27900; Sat, 10 Oct 92 23:49:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00625; Sat, 10 Oct 92 23:40:52 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00591; Sat, 10 Oct 92 23:39:10 -0700 Received: from dale.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA07264; Sat, 10 Oct 92 23:38:36 PDT From: ccjoan@bullwinkle.ucdavis.edu Date: Sat, 10 Oct 92 23:38:36 PDT Message-Id: <9210110638.AA07264@bullwinkle.ucdavis.edu> To: reverman@uci.edu Subject: Re: First update to the discussion paper Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano Cc: ietf-wnils@ucdavis.ucdavis.edu How about just a pointer to the new email address or whois server that can provide the information? > Date: Fri, 9 Oct 92 12:25:13 PDT > From: "Richard Everman" > To: jcgargano@ucdavis.ucdavis.edu > Subject: Re: First update to the discussion paper > > Joan > > The MESSAGE below raised these questions: > > Can (should?) WHOIS have an entry for forwarding eMail? Can (should?) WHOIS > foward the eMail? Can (should?) WHOIS returned to sender, a change of address > message (like the US Mail service), a non-deliverable message, etc? Can > (should?) WHOIS do all, none, or some combination of the above? > > Thanks > > Richard Everman > reverman@uci.edu > Associate Registrar > University of California, Irvine > 215 Adm Bldg > Irvine, CA 92717 > (714) 856-7901 > > > > MESSAGE > > From: "(via the vacation program)" > Date: Thu, 8 Oct 1992 17:04:14 -0500 > To: Multiple recipients of list EC-CAP > Subject: new location > > Prof. Allen is no longer at Purdue University. If you wish to reach him, > his new address is: > > George D. Allen, Ph.D., Director for Learning Technology > College of Nursing, A230 Life Sciences Building > Michigan State University, East Lansing, MI 48825-1317 > Phone: (517) 353-9020 > Email: alleng@msu.edu > > > Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Sun Oct 11 00:30:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01933; Sun, 11 Oct 92 00:23:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27972; Sun, 11 Oct 92 00:00:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00993; Sat, 10 Oct 92 23:54:04 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00863; Sat, 10 Oct 92 23:49:09 -0700 Received: from dale.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA07308; Sat, 10 Oct 92 23:48:38 PDT From: ccjoan@bullwinkle.ucdavis.edu Date: Sat, 10 Oct 92 23:48:38 PDT Message-Id: <9210110648.AA07308@bullwinkle.ucdavis.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: First update to the discussion paper Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano I am forwarding some good suggestions that were sent to me directly. > Date: Thu, 8 Oct 92 12:44:01 PDT > From: "Richard Everman" > To: jcgargano@ucdavis.ucdavis.edu > Subject: Re: First update to the discussion paper > > deleted > > > > 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. > > > deleted > > > > > There are three types of data records supported in this > > proposal: records for people, hosts, and domains. > > > > Individual records > > > > Name Name of the individual required > * public key public key optional > > Organization Name of the organization required > > Organization-type Type of organization optional > > deleted > > ** Department record ** > Department Department optional > public key public key optional > general phone # General Service telephone optional > department eMail department eMail optional > postal address sMail address optional > last-updated date updated optional > service hours days/hours open optional > department directory link of offfice staff optional > attribute function 1 optional > ... > > attribute function n optional > > ** or ** > > attributes functions 1, 2, ..., n optional > > > > deleted > > > Joan > > I would like to send information over the Internet which is protected by the > Privacy Act (students' transcripts.) If the WHOIS directory is extended to > include a public key field, it would do two things: > - the student record would be protected from prying eyes > - it would greatly reduce the logistics of maintaining and distributing keys. > > I suggest that there be two fields for public keys: one in the individual > record and the other in the department record. > > Second, my preference is to see the WHOIS expanded to include the > functionality of the yellow pages, the "campus operator", and the > "information desk." Could > the department field be expanded to included a list of (50?) key words, > highlighting the services that office provides? It is not uncommon > (at least in educational institutions) for a person to want to contact > an #office# and not a staff member of that office. For example, a > student applying to the University: > The applicant simply wants an application form and does not want to > make contact > with a person in the Admission's Office . (This function is not unlike the > automatic request-info feature of nnsc.nsf.net. Yes, an electronic admission > application is in the works.:-)) > > The keywords act as directory information. Since the names of "like" offices > (may) change from institution to institution, this field would provide > the means > for an individual to search an institution WHOIS file for the name > of an office > (and an individual) that may be of assistance. For example, a request for > information about ordering transcripts from UCI would return four entries: > the > Office of the Registrar, Jack Smith (transcripts clerk), the Medical > School, and > Jackie Smith (medical transcripts clerk.) > > The other information (and I do not think it is complete) assisted in > automating > the process of finding a person, a service, hours of operation, and so forth. > > As a footnote, when I read your paper, I tried to look up RFC 954 at > nri.reston.va.us and nnsc.nsf.net. I could not find them there. I did > find it at munnari.oz.au, the University of Melbourne. (That's a wide gap > in time zones had I been trying to contact people. The Internet is bring > true meaning to the phrase about a global community!) > > > Thank you Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Mon Oct 12 02:10:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28042; Mon, 12 Oct 92 02:08:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02848; Mon, 12 Oct 92 01:49:58 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27000; Mon, 12 Oct 92 01:40:44 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26891; Mon, 12 Oct 92 01:37:21 -0700 Received: from localhost by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.23) id AA26692; Mon, 12 Oct 1992 18:06:41 +0930 Message-Id: <9210120836.AA26692@jarrah.itd.adelaide.edu.au> To: jcgargano@ucdavis.ucdavis.edu Cc: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: First update to the discussion paper In-Reply-To: Your message of "Thu, 08 Oct 92 00:36:49 PDT." <9210080736.AA05636@bullwinkle.ucdavis.edu> Date: Mon, 12 Oct 92 18:06:41 +1000 From: Mark Prior X-Mts: smtp OK some comments ... This paper acknowledges the existance of many distributed information servers, and anticipates the creation of many more. To help users locate WHOIS servers, each server should have a nameserver entry in the form "whois.domain", i.e. whois.ddn.mil. As I said at the BOF, I think this should be the main thrust of the group. I don't really care what format the data is presented to me I just have great difficulty in actually finding the stuff. We can at least mandate the use of a name such as this then a great proportion of the problem is solved. 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. I am really not too keen on stripping spaces. If you are actually searching a database then it is likely that you have a field called surname (or whatever) and if you have one label you can just try that but working out if a string with multiple token is a surname or a full name it just too much of a pain and I don't think it really gets you anything. There are three types of data records supported in this proposal: records for people, hosts, and domains. I think you should also allow for site extensions, I might like to make course information available in this manner. Also I'm not sure how applicable a domain search is to an organisational whois (it's fine for a NIC but I think it's a special (site) case. whois smith exact match on last name Should specify that it will match either a surname _or_ username. whois smith,j exact match on last name, whois "smith,j" first name begins with "J" NO! what if you have a person who's given name is a single character. There is no mechanism for specifying that you what the given name "x" rather than the initial "x". I think it would be better to say you must say "whois smith,j." to get an initial based search. whois .john Smith What does this mean? whois "smith..." all last names beginning with Smith Would anyone actually use this form? 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" I'm not too keen on this one either. whois exact A Martinez exact match for "A Martinez" Exact is a bit of a noop isn't it? whois hamlet.ucdavis.edu IP address and other information on I think system searches should always start with the keyword system. The keyword less cases should be reserved for surname/full name cases. I would think it is more likely that someone would want to lookup the e-mail address of someone and this may have "."'s in it. For example if I received mail from "P.Barker@cs.ucl.ac.uk" I would like to be able to query the whois server at whois.cs.ucl.ac.uk and ask it whois p.barker more than I would want to ask whois bells.cs.ucl.ac.uk. Trying to do some fancy footwork in working out if the string is a domain/system name or a e-mail address is also too hard. Remember that there are a lot of two letter surnames that will clash with the ISO country codes. whois !ucdavis-dom site contacts and other information I would argue that next to noone would use this except maybe a system admin at UC Davis who knows what your NIC network name is. 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. I am also not too happy with the keywords, I would prefer symbols. Remember that non english speakers will use this system and it's about time we tried to be "friendly" towards them. I don't think I want to specify a mechanism for specifying the natural language of the quert language though :-). There needs to be a site mechanism so that you can query my server in it's "native" mode, in my case X.500 attributes. If the client queries for "help" or "?" then the server should return a complete help file. The help file should contain informaton in sufficient detail for the user to understand and access all the features of WHOIS service. If you allow "?" as a pattern matching character you can't also use it to specify help. How do you specify a query for all persons with a single character surname, or username? Mark. PS In the tradition of the Internet, I (nearly) have a prototype running. At the moment there is no help facility, pretty minimal error checking and it only implements with person lookups. The machine it's on is being upgraded at the moment but it should be back in business tomorrow. From ietf-wnils-request@ucdavis.ucdavis.edu Wed Oct 14 01:40:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09995; Wed, 14 Oct 92 01:38:45 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26087; Wed, 14 Oct 92 01:20:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08954; Wed, 14 Oct 92 01:10:54 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08715; Wed, 14 Oct 92 01:03:16 -0700 Received: from localhost by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.23) id AA07623; Wed, 14 Oct 1992 17:32:37 +0930 Message-Id: <9210140802.AA07623@jarrah.itd.adelaide.edu.au> To: jcgargano@ucdavis.ucdavis.edu Cc: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: First update to the discussion paper In-Reply-To: Your message of "Sat, 10 Oct 92 23:48:38 PDT." <9210110648.AA07308@bullwinkle.ucdavis.edu> Date: Wed, 14 Oct 92 17:32:37 +1000 From: Mark Prior X-Mts: smtp > > I would like to send information over the Internet which is protected by the > Privacy Act (students' transcripts.) If the WHOIS directory is extended to > include a public key field, it would do two things: > - the student record would be protected from prying eyes > - it would greatly reduce the logistics of maintaining and distributing keys. > > I suggest that there be two fields for public keys: one in the individual > record and the other in the department record. > Well I think this is getting off the track. I thought whois was suppose to be a simple contact information service. I would have also thought that it would be more likely that some EDI application would do this sort of thing automatically and that is more likely to follow the EDI standards that currently use X.509 authentication (and thus would have hooks into the X.500 Directory service rather than some Internet lookup service). > Second, my preference is to see the WHOIS expanded to include the > functionality of the yellow pages, the "campus operator", and the > "information desk." And this is stepping into ground already covered by the X.500 Directory (among other things). If we keep going down this track we will be accused of creating some OSI-like monster. I thought the Internet was an advocate of the KISS (Keep It Simple Stupid) principle rather than the "lets design this totally orthogonal you beaut does everything thing" principle that is so horrendous to implement that noone ever does. Mark. From ietf-wnils-request@ucdavis.ucdavis.edu Wed Oct 14 19:23:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00243; Wed, 14 Oct 92 19:18:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07847; Wed, 14 Oct 92 19:01:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29078; Wed, 14 Oct 92 18:50:58 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from ka.reg.uci.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28790; Wed, 14 Oct 92 18:43:42 -0700 Received: from [128.200.148.50] by ka.reg.uci.edu (4.1/SMI-4.1) id AA23008; Wed, 14 Oct 92 18:41:52 PDT Date: Wed, 14 Oct 92 18:41:52 PDT Message-Id: <9210150141.AA23008@ka.reg.uci.edu> From: "Richard Everman" To: mrp@itd.adelaide.edu.au Cc: ietf-wnils@ucdavis.ucdavis.edu Subject: Automating the functions of WHOIS > DELETED > > If we keep going down this track we will be accused of creating some > OSI-like monster. I thought the Internet was an advocate of the KISS > (Keep It Simple Stupid) principle rather than the "lets design this > totally orthogonal you beaut does everything thing" principle that is > so horrendous to implement that noone ever does. > > Mark As a systems analyst, I am fond of saying, "How you perceive a problem is how you solve the problem." My perception of WHOIS is that it is the personification of the directory services provided by the white pages, yellow pages, telephone operator, and the general information directory. If this means adding a few (optional) elements to automate these functions, why not? Thanks for listening. Richard Everman reverman@uci.edu Associate Registrar University of California, Irvine 215 Adm Bldg Irvine, CA 92717 (714) 856-7901 From ietf-wnils-request@ucdavis.ucdavis.edu Wed Oct 14 19:40:55 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00844; Wed, 14 Oct 92 19:34:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07885; Wed, 14 Oct 92 19:10:26 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29512; Wed, 14 Oct 92 19:03:33 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29242; Wed, 14 Oct 92 18:56:45 -0700 Received: from localhost by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.23) id AA11801; Thu, 15 Oct 1992 11:25:24 +0930 Message-Id: <9210150155.AA11801@jarrah.itd.adelaide.edu.au> To: "Richard Everman" Cc: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Automating the functions of WHOIS In-Reply-To: Your message of "Wed, 14 Oct 92 18:41:52 PDT." <9210150141.AA23008@ka.reg.uci.edu> Date: Thu, 15 Oct 92 11:25:24 +1000 From: Mark Prior X-Mts: smtp > If we keep going down this track we will be accused of creating some > OSI-like monster. I thought the Internet was an advocate of the KISS > (Keep It Simple Stupid) principle rather than the "lets design this > totally orthogonal you beaut does everything thing" principle that is > so horrendous to implement that noone ever does. > As a systems analyst, I am fond of saying, "How you perceive a problem is how you solve the problem." My perception of WHOIS is that it is the personification of the directory services provided by the white pages, yellow pages, telephone operator, and the general information directory. If this means adding a few (optional) elements to automate these functions, why not? I think extending whois is generally a bad idea, it doesn't have a powerful enough query language to be really useful. There is also the problem of finding the various servers, nor modifying data contained in the database. Probably it's most useful function is to provide a window into some other system since there are a lot of clients available for it (although the same could be said for finger). Really if you want a more flexible system then you should be looking at Gopher/WAIS/WWW et al or X.500. Mark. From ietf-wnils-request@ucdavis.ucdavis.edu Thu Oct 22 11:12:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15066; Thu, 22 Oct 92 11:07:13 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25145; Thu, 22 Oct 92 09:20:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11032; Thu, 22 Oct 92 09:13:57 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from punisher.cco.caltech.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10728; Thu, 22 Oct 92 09:05:41 -0700 Received: by punisher.caltech.edu (4.1/DEI:4.41) id AA06243; Thu, 22 Oct 92 09:05:13 PDT From: dank@cco.caltech.edu (Daniel R. Kegel) Date: Thu, 22 Oct 92 09:05:13 PDT Message-Id: <9210221605.AA06243@punisher.caltech.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Directory Hi all, I was looking thru the wnils charter, and noticed there's supposed to be an archive of the list on ftp at pub/ietf-wnils-archive@ucdavis.edu. It doesn't seem to be there. Also, I've seen a draft of the revised whois protocol spec, but I haven't seen the "Directory Resources Recommendations" document. I was hoping to see a copy of it in the archive. Can someone tell me where the archive is, or where I can get a copy of the draft "Directory Resources Recommendations" document? Thanks, Dan Kegel (dank@alumni.caltech.edu) From ietf-wnils-request@ucdavis.ucdavis.edu Thu Oct 22 11:13:22 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15138; Thu, 22 Oct 92 11:09:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25726; Thu, 22 Oct 92 10:10:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12868; Thu, 22 Oct 92 10:04:45 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from farber.harvard.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12660; Thu, 22 Oct 92 09:59:45 -0700 Received: by farber.harvard.edu (5.65/1.34) id AA17239; Thu, 22 Oct 92 12:58:57 -0400 From: ellozy@farber.harvard.edu (Mohamed Ellozy) Message-Id: <9210221658.AA17239@farber.harvard.edu> Subject: Status of project? To: ietf-wnils@ucdavis.ucdavis.edu Date: Thu, 22 Oct 92 12:58:56 EDT X-Organization: Dana-Farber Cancer Institute X-Phone: 617-732-3034, 617-632-3425 X-Mailer: ELM [version 2.3 PL11] I am trying to get our online directory services available in as many formats as possible as soon as possible. We will have a UIUC qi server running next week, and are looking into whois. I have compiled the Caltech server and tested it, and it seems to work and to be clear enough to modify as needed. Is there any chance that this project will produce something useable soon (even in beta form) or should I go ahead with what I have? In the latter case, any other suggestions for the server? Thanks. Mohamed From ietf-wnils-request@ucdavis.ucdavis.edu Thu Oct 22 12:07:55 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16849; Thu, 22 Oct 92 11:57:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26912; Thu, 22 Oct 92 11:30:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15758; Thu, 22 Oct 92 11:25:21 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15524; Thu, 22 Oct 92 11:18:06 -0700 Received: from dale.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA24378; Thu, 22 Oct 92 11:17:16 PDT From: ccjoan@bullwinkle.ucdavis.edu Date: Thu, 22 Oct 92 11:17:16 PDT Message-Id: <9210221817.AA24378@bullwinkle.ucdavis.edu> To: dank@cco.caltech.edu Subject: Re: Directory Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano Cc: ietf-wnils@ucdavis.ucdavis.edu > From: dank@cco.caltech.edu (Daniel R. Kegel) > Date: Thu, 22 Oct 92 09:05:13 PDT > To: ietf-wnils@ucdavis.ucdavis.edu > Subject: Directory > > Hi all, > I was looking thru the wnils charter, and noticed there's supposed to > be an archive of the list on ftp at pub/ietf-wnils-archive@ucdavis.edu. > It doesn't seem to be there. > > Also, I've seen a draft of the revised whois protocol spec, but I haven't > seen the "Directory Resources Recommendations" document. I was hoping > to see a copy of it in the archive. > > Can someone tell me where the archive is, or where I can get a copy of > the draft "Directory Resources Recommendations" document? > Thanks, > Dan Kegel (dank@alumni.caltech.edu) > The archive is on ucdavis.edu in archive/wnils. Sorry for the confusion. The charter does say the archive is in: pub/ietf-wnils-archive@ucdavis.edu. Are there any objections to amending the charter to reflect the actual archive or is it imperative that we reconfigure our archiving system? Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Thu Oct 22 13:23:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19416; Thu, 22 Oct 92 13:18:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01649; Thu, 22 Oct 92 12:50:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18304; Thu, 22 Oct 92 12:41:59 -0700 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17725; Thu, 22 Oct 92 12:23:46 -0700 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA24721; Thu, 22 Oct 92 15:22:53 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA01010; Thu, 22 Oct 92 15:22:53 EDT Date: Thu, 22 Oct 92 15:22:53 EDT From: clw@merit.edu Message-Id: <9210221922.AA01010@home.merit.edu> To: dank@cco.caltech.edu, jcgargano@ucdavis.ucdavis.edu Subject: Re: Directory Cc: ietf-wnils@ucdavis.ucdavis.edu I'd say amend the charter :^) simpler that way... Chris From ietf-wnils-request@ucdavis.ucdavis.edu Mon Nov 2 22:20:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07243; Mon, 2 Nov 92 22:12:11 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17287; Mon, 2 Nov 92 21:50:25 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06508; Mon, 2 Nov 92 21:41:20 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06347; Mon, 2 Nov 92 21:35:50 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA05679; Tue, 3 Nov 1992 16:05:10 +1030 Message-Id: <9211030535.AA05679@jarrah.itd.adelaide.edu.au> To: jcgargano@ucdavis.ucdavis.edu Cc: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: First update to the discussion paper In-Reply-To: Your message of "Thu, 08 Oct 92 00:36:49 PDT." <9210080736.AA05636@bullwinkle.ucdavis.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Nov 92 16:05:10 +1030 From: Mark Prior This is the first update to the discussion paper presented at the July IETF on Whois service. It incorporates suggestions from the meeting. I hope this provides a good starting point for discussion. Since I won't be at Washington I better get my 5c's worth in now (again :-). This paper acknowledges the existance of many distributed information servers, and anticipates the creation of many more. To help users locate WHOIS servers, each server should have a nameserver entry in the form "whois.domain", i.e. whois.ddn.mil. This is the thing that I thing is most important. While I don't agree that it's really worth trying to do anything to improve whois (if it's not broken then don't fix it), being able to find these resources is the biggest problem. One of the advantages of X.500 is that you can find the servers easily. There might not be a server for the organisation you are looking for but at least X.500 will indicate that fact whereas with whois you are always left wondering if you looked in the "wrong" place. 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. I don't agree with this. Domain records Domain-name Domain name registered with required the Network Information Center (NIC) I wouldn't expect this sort of record to be very comment at non-NIC whois servers. After all most organisations would only have a couple of networks registered. In any case I don't think the NIC Domain name is too helpful to the poor user anyway! They might want to ask "whois domain itd.adelaide.edu.au" but I wouldn't expect them to ask "whois domain uaeng01" whois !ucdavis-dom site contacts and other information whois domain ucdavis.edu on the site ucdavis And here to seem to agree with me! I don't favour the use of keywords when symbols would work just as well and be somewhat more language independent. I think it needs to be made clear what changes if any this proposal is trying to make. It is clear to me that we are trying to encourage the use of a "whois.domain" alias to point to a sites whois server, and we are trying to suggest the sort of queries and responses that a server should support but it's not clear if there is any requirement for the server to format it's response in a certain way. Mark. PS Is there anyone else out there or am I talking to myself again :-) PPS I have an experimental implementation (using the X.500 directory as a backend) available. I will leave it as an exercise for you to find it! :-) From ietf-wnils-request@ucdavis.ucdavis.edu Mon Nov 9 12:14:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03834; Mon, 9 Nov 92 11:57:21 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27334; Mon, 9 Nov 92 11:32:55 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03170; Mon, 9 Nov 92 11:20:31 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01976; Mon, 9 Nov 92 10:26:19 -0800 Received: from dale.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA29124; Mon, 9 Nov 92 10:25:16 PST From: ccjoan@bullwinkle.ucdavis.edu Date: Mon, 9 Nov 92 10:25:16 PST Message-Id: <9211091825.AA29124@bullwinkle.ucdavis.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Agenda for November 18 Meeting Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano Whois and Network Information Lookup Service (WNILS) Agenda Wednesday, November 18, 1992 Review of WNILS Charter and Agenda Joan Gargano Overview of Recommended Modifications to the Whois Protocol Joan Gargano Introduction of Whois++ - Architecture Peter Deutsch Distributed Whois++ Model - Centroids Chris Weider Front End to Database Integration Jim Fullton Demonstration of Whois++ Discussion of Projects Clients - DOS, MS Windows, Macintosh, X Windows Database Interfaces - SQL, X.500 Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Thu Nov 12 08:16:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12437; Thu, 12 Nov 92 08:09:57 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02942; Thu, 12 Nov 92 07:40:11 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11655; Thu, 12 Nov 92 07:31:09 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from farber.harvard.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11489; Thu, 12 Nov 92 07:22:44 -0800 Received: by farber.harvard.edu (5.65/1.34) id AA25803; Thu, 12 Nov 92 10:21:43 -0500 From: ellozy@farber.harvard.edu (Mohamed Ellozy) Message-Id: <9211121521.AA25803@farber.harvard.edu> Subject: Re: Questions about X.500/QUIPU Usage To: davy@ecn.purdue.edu (David A. Curry) Date: Thu, 12 Nov 92 10:21:42 EST Cc: wpp-camayocs@psi.com, info-ph@uxc.cso.uiuc.edu, ietf-wnils@ucdavis.ucdavis.edu In-Reply-To: <9211111700.AA00822@intrepid.ecn.purdue.edu>; from "David A. Curry" at Nov 11, 92 12:00 pm X-Organization: Dana-Farber Cancer Institute X-Phone: 617-732-3034, 617-632-3425 X-Mailer: ELM [version 2.3 PL11] Dave, Rather than answer your specific questions (we are so small that my answers would be of little use to you) I will address the broader issue: What does X.500 give you, if all you need is a phone/email lookup, that justifies its cost? My answer is: Very little. X.500 has a lot of generality built in, but it is a very expensive whois server. The main advantage it has is that it has, built into it, the equivalent of the DNS root servers. Also, your DUA talks only to your DSA, and needs no knowledge of the other DSAs out there. Current implementations of whois, and the command line (UNIX, DOS and VMS) versions of the UIUC qi/ph protocol, require the user agent to know the servers for off campus searches (and whois clients default to nic.ddn.mil rather than to the localhost). This is changing, most so for qi/ph. The servers now can (and soon most will) aquire a list of all qi servers from a host which is, informally, acting as a root nameserver. Currently there are Macintosh and X11 interfaces that use this very nicely. While there are no whois servers that advertise other servers a list of whois servers is being maintained (informally) by Matt Power of MIT, available as sipb.mit.edu:/pub/whois/whois-servers.list. While no pure whois client uses that list, Dan Kegel at JPL has produced a rather neat client that will essentially grep through a list of both whois and qi servers and use the appropriate host/service to look someone up. That client is called uwho, and an example follows: farber% uwho ellozy @ Dana-Farber 1 queries pending... ------ whois.dfci.harvard.edu Dana-Farber Cancer Institute C=US ------ ---query--- ellozy ----------- Ellozy, Mohamed S. (ME3) Mohamed_Ellozy@dfci.harvard.edu Phone number:(617) 732-3626 The whois server I use (from caltech) is trivial to install and run. It takes a bit more time to get qi to run, but nothing compared to quipu. And both use almost negligeable resources. I jumped onto the quipu bandwagon as soon as I could after the pilot was opened to non-NYSERnet sites, but am now very disillusioned. Mohamed PS: I am sending copies of this to the ph and IETF whois lists, where many of the issues I have raised are discussed. From ietf-wnils-request@ucdavis.ucdavis.edu Thu Nov 12 13:30:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20229; Thu, 12 Nov 92 12:55:53 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05788; Thu, 12 Nov 92 11:41:00 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17837; Thu, 12 Nov 92 11:33:58 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from punisher.cco.caltech.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17468; Thu, 12 Nov 92 11:20:32 -0800 Received: by punisher.caltech.edu (4.1/DEI:4.41) id AA29833; Thu, 12 Nov 92 11:19:53 PST Message-Id: <9211121919.AA29833@punisher.caltech.edu> To: ellozy@farber.harvard.edu (Mohamed Ellozy) Cc: davy@ecn.purdue.edu (David A. Curry), wpp-camayocs@psi.com, ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Questions about X.500/QUIPU Usage In-Reply-To: Your message of "Thu, 12 Nov 92 10:21:42 EST." <9211121521.AA25803@farber.harvard.edu> Date: Thu, 12 Nov 92 11:19:51 -0800 From: "Daniel R. Kegel" ellozy@farber.harvard.edu (Mohamed Ellozy) writes: >While there are no whois servers that advertise other servers a list >of whois servers is being maintained (informally) by Matt Power of >MIT, available as sipb.mit.edu:/pub/whois/whois-servers.list. Matt's efforts are also available via whois, e.g. whois -h sipb.mit.edu whois-servers Better yet, this data is in fact available from several whois servers, all of whom download it periodically from sipb. A list of such servers is also available via whois, e.g. whois -h sipb.mit.edu whois-list-servers This currently returns ; Internet whois servers that support the "whois-servers" command line ; (2 November 1992). For more information, query this server, e.g., ; whois -h sipb.mit.edu whois-servers indiana.edu whois.rsmas.miami.edu sipb.mit.edu syr.edu >While no pure whois client uses that list, Dan Kegel at JPL has produced a >rather neat client that will essentially grep through a list of both >whois and qi servers and use the appropriate host/service to look >someone up. That client is called uwho, and an example follows: Current sources for uwho are available from punisher.caltech.edu via ftp in pub/dank/uwho/2.12. - Dan K. From ietf-wnils-request@ucdavis.ucdavis.edu Thu Nov 12 15:18:22 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24944; Thu, 12 Nov 92 15:07:54 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07921; Thu, 12 Nov 92 13:52:49 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21732; Thu, 12 Nov 92 13:45:28 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from ATHENA-AS-WELL.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21197; Thu, 12 Nov 92 13:31:10 -0800 Received: from STEVE-DALLAS.MIT.EDU by Athena.MIT.EDU with SMTP id AA11492; Thu, 12 Nov 92 16:29:29 EST From: mhpower@Athena.MIT.EDU Received: by steve-dallas.MIT.EDU (5.61/4.7) id AA21446; Thu, 12 Nov 92 16:29:16 -0500 Message-Id: <9211122129.AA21446@steve-dallas.MIT.EDU> To: ellozy@farber.harvard.edu Cc: dank@cco.caltech.edu, davy@ecn.purdue.edu, wpp-camayocs@psi.com, info-ph@uxc.cso.uiuc.edu, ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Questions about X.500/QUIPU Usage Date: Thu, 12 Nov 92 16:29:13 EST >>While there are no whois servers that advertise other servers ... > whois -h sipb.mit.edu whois-servers ... > whois -h sipb.mit.edu whois-list-servers The three other servers that now support these queries sync their list copies daily with the one on sipb.mit.edu. Others are welcome. The list currently includes 114 whois servers in 18 countries, and updates have been made, on average, once a week throughout this year. Also, in response to one of Dave's original questions, 8. Do you use any "add-on" software with your Directory, such as "finger"/"whois" interfaces, ... Of the 114 whois servers, I believe that about 20 are interfaces to an organizational X.500 service. A few others were listed previously, but decided to discontinue whois support, or the entire DSA. (In general, sites are dropped from the list if I find they remain inoperable for on the order of weeks.) Finally, I know of four other X.500-based servers that I don't list, since their administrators didn't want external queries going through the whois interface. Matt From ietf-wnils-request@ucdavis.ucdavis.edu Thu Nov 12 15:43:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25527; Thu, 12 Nov 92 15:21:00 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08458; Thu, 12 Nov 92 14:32:01 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23049; Thu, 12 Nov 92 14:21:39 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from farber.harvard.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22535; Thu, 12 Nov 92 14:09:00 -0800 Received: by farber.harvard.edu (5.65/1.34) id AA09641; Thu, 12 Nov 92 17:07:52 -0500 From: ellozy@farber.harvard.edu (Mohamed Ellozy) Message-Id: <9211122207.AA09641@farber.harvard.edu> Subject: Re: Questions about X.500/QUIPU Usage To: dank@cco.caltech.edu (Daniel R. Kegel) Date: Thu, 12 Nov 92 17:07:51 EST Cc: wpp-camayocs@psi.com, ietf-wnils@ucdavis.ucdavis.edu In-Reply-To: <9211121919.AA29833@punisher.caltech.edu>; from "Daniel R. Kegel" at Nov 12, 92 11:19 am X-Organization: Dana-Farber Cancer Institute X-Phone: 617-732-3034, 617-632-3425 X-Mailer: ELM [version 2.3 PL11] > ellozy@farber.harvard.edu (Mohamed Ellozy) writes: > >While there are no whois servers that advertise other servers a list > >of whois servers is being maintained (informally) by Matt Power of > >MIT, available as sipb.mit.edu:/pub/whois/whois-servers.list. > > Matt's efforts are also available via whois, e.g. > whois -h sipb.mit.edu whois-servers > Better yet, this data is in fact available from several whois servers, all of > whom download it periodically from sipb. A list of such servers is also > available via whois, e.g. > whois -h sipb.mit.edu whois-list-servers > This currently returns > ; Internet whois servers that support the "whois-servers" command line > ; (2 November 1992). For more information, query this server, e.g., > ; whois -h sipb.mit.edu whois-servers > indiana.edu > whois.rsmas.miami.edu > sipb.mit.edu > syr.edu In my message which started this I pointed out that both qi and whois had informal mechanisms which, in fact, performed the functions that the root nameservers perform for DNS and, with different terminology, for X.500. It seems that, in fact, these mechanisms though informal are pretty solid. This leads to an obvious question: Should qi/whoisd servers query other servers? The analogy with DNS is obvious. My server has no clue what the IP address of sipb.mit.edu is, but it does not give me (the client program) the name of the MIT nameserver. My server queries other servers (root, then MIT nameserver) and returns the reqested data to me. One important point is that the list of whois servers is now too long to scroll through, and so will the list of qi servers be soon. So we will need a person @ domain type syntax. Dan has got the syntax almost right with uwho, except that I feel the smarts are in the wrong place. It would be nice if my whois server would accept a query of the form "matt power @ mit.edu", discover that it is not authoritative for mit.edu, find out who is (cache? query root?), send request to appropriate server and then response to me. Then uwho would query my server, as would each of my mail user agents and whatever other programs need directory info. I suspect that this need not lead to the complexity of DNS or X.500. I hope that those planning a new whois service think about it. Also would be worth seeing how this could fit into the existing qi. Finally, both the whois and qi protocols are fairly simple. High on my wish list is a way of doing what uwho does (find both host and service and make approrpiate query). Again, I suspect that the smarts should be in the server, not the clients. Mohamed From ietf-wnils-request@ucdavis.ucdavis.edu Thu Nov 12 17:15:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29126; Thu, 12 Nov 92 16:44:07 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09696; Thu, 12 Nov 92 16:21:07 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27359; Thu, 12 Nov 92 16:03:33 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from punisher.cco.caltech.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26913; Thu, 12 Nov 92 15:54:12 -0800 Received: by punisher.caltech.edu (4.1/DEI:4.41) id AA19767; Thu, 12 Nov 92 15:53:28 PST Message-Id: <9211122353.AA19767@punisher.caltech.edu> To: ellozy@farber.harvard.edu (Mohamed Ellozy) Cc: dank@cco.caltech.edu (Daniel R. Kegel), wpp-camayocs@psi.com, ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Questions about X.500/QUIPU Usage In-Reply-To: Your message of "Thu, 12 Nov 92 17:07:51 EST." <9211122207.AA09641@farber.harvard.edu> Date: Thu, 12 Nov 92 15:53:26 -0800 From: "Daniel R. Kegel" >Dan has got the syntax almost right with uwho, except that I feel the >smarts are in the wrong place. It would be nice if my whois server >would accept a query of the form "matt power @ mit.edu", discover that >it is not authoritative for mit.edu, find out who is (cache? query >root?), send request to appropriate server and then response to me. >Then uwho would query my server, as would each of my mail user agents >and whatever other programs need directory info. I agree that putting the smarts in a server saves the world a lot of work. uwho already has an interactive mode which can be used as a whois server; just stick it in inetd.conf, it will enter interactive mode if no query is given on the commandline. It prompts the user, and tolerates multiple queries per session, so you can also telnet to it. Does this satisfy your requirements, Mohamed? I should also mention that uwho gives you access to the KIS service as well as to whois and ph servers, although it only goes to KIS for MCI mail addresses at the moment. - Dan K. From ietf-wnils-request@ucdavis.ucdavis.edu Fri Nov 13 21:51:59 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01881; Fri, 13 Nov 92 21:39:50 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21999; Fri, 13 Nov 92 18:03:50 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01635; Fri, 13 Nov 92 17:52:07 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01229; Fri, 13 Nov 92 17:42:39 -0800 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02151 (mail destined for ietf-wnils@ucdavis.edu) on Fri, 13 Nov 92 18:43:23 -0500 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA16844; Fri, 13 Nov 92 18:36:24 EST Message-Id: <9211132336.AA16844@expresso.cc.mcgill.ca> In-Reply-To: clw@merit.edu's message as of Nov 10, 17:35 From: peterd@bunyip.com (Peter Deutsch) Date: Fri, 13 Nov 92 23:36:23 GMT-0:02 In-Reply-To: clw@merit.edu's message as of Nov 10, 17:35 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Final pre-ietf version of architecture document Sigh, I need a good night's sleep. Apologies to the list for the delay in sending this out. I have been on the road for most of the past three weeks and expected better connectivity than I had. I just haven't had time to work over the paper to the degree I had wanted, but having just given it a quick read over, I think it's actually ready to be seen by people anyways. Here's the most recent draft of a paper that presents an architectural overview and protocol specification for the basic proposed WHOIS++ service. It is clearly intended only as a point of departure for discussion and should not be used as the basis for implementations at this point, pending discussion at the IETF meeting next week. This is a first draft, providing an architectural overview and first description of the proposed WHOIS++ service. This includes a proposed command set and command syntax, as well as a first draft of a response syntax. This paper should now give you all something definite to shoot at, and perhaps will help those who are new to the WHOIS++ project understand where we are trying to go with it. Part I is a general exposition and overview, and in it I reference the paper being written by Joan Gargano. I suspect that there is additional material in this that should be moved over or cut. Barring that, perhaps we might consider splitting the document again. Part II is the meat and potatoes of the paper. It specifies the set of valid system commands (see Table I), the format of the search command (see Table II) and the various response formats available (see table III for a summary of response modes and Table IV for samples). Appendix A includes the (almost) complete BNF for the command syntax. This is the part that contains all the "specification" bits. Still missing is a BNF for the response formats, but these are explained in grimey detail in the text and since this is obviously only my crack at a straw man and entirely open to debate at this point, I thought I'd just toss it out for a bit of discussion and get to the BNF later. That's about it for now. I'd particularly like feedback on the proposed response format. I recognize that the paper makes quite a few statements that are still wide open to debate (eg. about the use of Booleans). Regard everything as negotiable, simply put down to be a target for debate. Also, my editorial comments, etc are in [* ... *] You will see these as sidebar comments as you go. Finally, I still have close to zero on centroids in this paper. This topic is covered in a companion paper that has already been posted. See you all next week in Washington... Now, off to catch a few winks.... - peterd ---------------------------------------------------------------------- Network Working Group Peter Deutsch, FIRST DRAFT peterd@bunyip.com, Bunyip Information Systems. August 19, 1992 (other contributors to follow) Architecture of the WHOIS++ service ----------------------------------- Part I - Introduction ---------------------- Purpose and Motivation ---------------------- The current NIC WHOIS service is used to provide a very limited directory service, serving information about a small number of Internet users registered with the DDN NIC. In addition, it has been expanded to also serve information about a variety of services and other information. This service allows users to issue searches for individual strings within individual records, as well as searches for individual record handles (that is, unique identifiers associated with each record) using a very simple protocol. This basic service was described in RFC 954. Despite its utility, the current NIC WHOIS service obviously can not function as a general White Pages service for the entire Internet. Given the huge number of users, the obvious problems with reliability and the huge volume of traffic that a full scale directory service is expected to generate, such a centralized architecture is obviously not practical for a generalized Internet directory service. This document is part of a project to extend the simple WHOIS model to address the needs for a simple, light-weight directory service. A general outline of the service and a description of the motiviation for this service are included in In this document we describe our extensions to the current NIC WHOIS service. These extensions are intended to allow users to publish and locate information about other users, services and related information from hosts operating across the Internet. Throughout this document, our extensions to the basic service will be referred to as "WHOIS++" to distinguish it from the original WHOIS service. The WHOIS++ service is intended to be an extension to the extremely simple protocol described in RFC 954. These extensions use an extremely simple data model and a correspondingly simple query protocol to allow users to satisfy their queries with a minimum of effort or resources. The basic architecture of WHOIS++ allows distributed maintenance of the directory contents and the use of an automated yellow pages service for locating WHOIS servers. This Yellow Pages service is described in a companion document . The Basic Information Model --------------------------- Our extensions to the existing WHOIS service are centred upon a recommendation to structure user information around a series of standardized templates, similar to those described by . We also offer a set of extensions to the trivial protocol described in RFC 954 to allow the user to constrain searches to desired attributes or template types, in addition to the existing commands for specifying handles or simple strings. Although not intended as a replacement for the more elaborate directory services now being deployed, it is expected that the minimalist approach we have taken will find application where the high cost of configuring and operating traditional White Pages services can not currently be justified. Note that this system is intended to be easy to set up and operate, and additional templates may be created and used with little effort. Also note that the new architecture makes no assumptions about the search and retrieval mechanisms used within individual servers. Operators are free to use fast indexing software or even provide gateways to other directory services to store and retrieve information. Operators are also free to use other services to automate the creation and maintenance of databases. The WHOIS++ server simply functions as a known front end, offering a simple data model and communicating through a well known port and protocol. The format of replies have been structured to allow the use of more elaborate clients for generating searches and displaying the results, but some effort has been made to keep responses at to some degree readible by humans. The actual implemention details of of an individual WHOIS search engine are left to the imagination of the implementor. It is hoped that this approach will encourage experimentation and the development of improved search engines. Scope of this document ----------------------- In this paper we describe the architecture of the WHOIS++ service and present details of the WHOIS++ protocol extensions. Details of the system's data model is also included. describes the motivation and scope of this project in more detail and makes recommendations for a minimal set of information templates to be supported by each server. A separate paper describes the details of the flooding algorithm and associated protocols. The Current WHOIS Service --------------------------- The existing WHOIS service allows the user to specify simple searches within a single database. Options allow the user to constrain these searches. For example, the user may search only on specfied handles, specified mailboxes, or on all strings and handles in the database. A number of sites have brought up additional WHOIS server and some have added additional options to specify further search constraints or request help. A recent informal survey of Internet sites found over 100 hosts offering some form of WHOIS service. Unfortunately there has been little or no coordination of features or command syntax. In this paper we proposed standardizing such extensions. The current WHOIS Information Model ------------------------------------ The current WHOIS service is based upon an extremely simple data model. The NIC WHOIS database consists of a series of individual records, each of which is identified by a single unique identifer (the "handle"). Each record contains one or more lines of information. Currently, There is no structure or implicit ordering of this information, although by implication each record is concerned with information about a single user or service. We are implemented two basic changes to this model. First, we have structured the information within the database as collections of attribute/value pairs, with each individual record containing a specified set of these attributes. Secondly, we have introduced typing of the database records. In effect, each record is based upon one of a limited number of templates, each containing a finite and specified number of attirbute fields. This will allow us to limit our searches to specific collections, such as information about users, services, abstracts of papers, descriptions of software, etc. As a final extension, we require that each individual WHOIS++ database on the Internet be assigned a unique handle, analogous to the handle associated with each database record. The entire WHOIS++ database structure is shown in Fig. 1. [* Ideally, these database handles will be registered through the IANA, ensuring their uniqueness. This will allow us to specify each WHOIS++ entry on the Internet as a unique record handle/WHOIS handle pair. *] A unique registered handle is preferable to using the host's IP address, since it is conceivable that the WHOIS++ server for a particular domain may move over time. If we preserve the unique WHOIS++ handle in such cases we have the option of using it for resource discovery and networked information retrieval. We believe that organizing information around a series of such templates will make it easier for administrators to gather and maintain this information and thus encourage them to make such information available. At the same time, as users become more familiar with the attributes available within specific templates they will be better able to specify their searches, leading to a more useful service. ______________________________________________________________________________ | | | | | _______ _______ _______ | | handle3 |.. .. | handle6 |.. .. | handle9 |.. .. | | | _______ | _______ | _______ | | | handle2 |.. .. | handle5 |.. .. | handle8 |.. .. | | | _______ | _______ | _______ | | | handle1 |.. .. | handle4 |.. .. | handle7 |.. .. | | | |.. .. | |.. .. | |.. .. | | | ------- ------- ------- | | Template Template Template | | Type 1 Type 2 Type 3 | | | | + Single unique WHOIS database handle | | | | | | Fig.1 - Structure of a single WHOIS++ database. | | | | Notes: - Entire database is identified by a single unique WHOIS handle. | | - Each record has a single unique handle and a specific set | | of attributes, determined by the template type used. | | - Each value associated with an attribute can be any ASCII string | | up to a specified length. | | | ------------------------------------------------------------------------------ The WHOIS++ Yellow Pages ------------------------- Without a functional services registry users will obviously have difficulty in locating individual Internet services. As part of the complete WHOIS++ architecture, in we describe a simplify Yellow Pages registry service. This service features proactive data gathering and periodic verification of servers so status information can be offered to the user. Beyond WHOIS++ -------------- A flooding algorithm is used to propagate information from individual records across a distributed database combining information from a number of WHOIS servers. This mechanism is used to address concerns about scaling and redundancy. [* obviously need a lot more on centroids here *] The WHOIS++ Architecture -------------------------- ---------------------------------------------------------------------- ____ ____ root | | | | directory | | | | service ---- ---- ____ ____ whois | | | | index | | | | service ---- ---- ____ ____ ____ individual | | | | | | whois servers | | | | | | ---- ---- ---- Fig. 2 - Overall system architecture. ---------------------------------------------------------------------- Getting Help ------------ Another extension to the basic WHOIS service is a requirement for a basic HELP command, allowing users to find out information about the individual server and the entire WHOIS++ service. This is done with a simple extension to the extended information model by defining a HELP template format. The operator of each WHOIS service is required to have, as a minimum, a single general HELP template. Details of the HELP template is included in Minimum HELP Required ----------------------- Every WHOIS++ server is required to have at least two records of type HELP. one with Subject "HELP" and one with Subject "HELPHELP". The first must contain a general introductory help message about the service and the second a general introductory help message about HELP itself. Executing the command: HELP will result in the display of the HELP template with subject "HELP". Executing the command: HELP HELP will result in the display of the HELP template with subject "HELPHELP". Executing the command: HELP will result in a search through all available help templates for a record with the matching "searchstring". Privacy and Security Issues ----------------------------- WHOIS++ is intended to be a simple, generalized and unauthenticated template-oriented browsing service available to all Internet users. Site administrators should NOT make confidential information about their users available through this service, even if the WHOIS server is not publicized. At the same time, given the unauthenticated nature of the service users are cautioned against putting too much faith in the information served. Users looking for a secure, authenticated and robust service are advised to check out the work being done on generalized directory services, where such considerations have been given more weight (and have consequentally added additional weight to the resulting service). [* editorial comment - I doubt I'll get away with the above statement, but it makes me feel good so I'll leave it in for now! :-) *] Part II - The WHOIS++ Protocol -------------------------------- The WHOIS++ protocol specifies the interactions between a WHOIS client and a WHOIS server supporting the WHOIS++ extensions. These extensions are designed to be backwards compatible with existing servers, in the sense that a new server receiving any of the older commands specified in RFC 954 will behave in the same manner as the original NIC WHOIS server. Obviously, it is not possible to ensure desired behaviour if one of the extended commands is sent to an older WHOIS server, since the requested functionality is simply not there. Still, it is possible to store whether the WHOIS++ command set is supported as an attribute for each WHOIS server in any services registry. Thus, in practice this should not be a problem. In addition, any such command sent to an older WHOIS server would simply be treated as a search term, and thus no harm should result. The small number of older servers, and the probability that at least some of the older servers will be converted as newer servers become available, means that backwards compatibility is not expected to be a problem in practice. The WHOIS++ Command set ------------------------ There are two types of WHOIS++ commands - system commands and the WHOIS++ search command. System Commands ---------------- System commands are commands to the server for information or to control its operation. These include commands to list the template types available, to obtain a single blank template of any available type, to obtain a list of the search methods that are supported on that server and a command to obtain help. There are also commands to obtain the current version of the WHOIS++ protocol supported and to obtain a brief description of the service, which is intended to support the automated registration of the service by yellow pages directory services. Table I lists the set of valid WHOIS++ system commands. ---------------------------------------------------------------------- Short Form Long Form Functionality -------------------------------------------------------------------- ? HELP [ [',' ]] system help LIST [ [',' ]] List templates supported by this system SHOW [',' ] Show contents of templates specified CONSTRAINTS list search methods supported by this server or other system constraints (eg maxhits) VERSION return current version of the protocol supported [* is this really needed? *] DESCRIBE Describe this server, formating the response using the standard IAFA"Services" template Table I - Valid WHOIS++ SYSTEM commands. ---------------------------------------------------------------------- Format of the Search Command ----------------------------- A search command consists of one or more search terms, which act as specifiers for the selection of records from the WHOIS++ database. Such specifiers are cumulative, that is, each search term is an additional specification that a record must satisfy before it will be returned to the user as a valid response to the query. There is currently no plans for Boolean operations (logical AND, OR or NOT), although this capability could be added if there is sufficient demand. [* This is obviously still open to debate *] A search command consists of one or more search terms, followed by an optional set of global search constraints. Search constraints that apply to every search term are specified as global constraints. In addition, the format of server responses may be changed from the specified default behaviour by setting a specific global constraint. Format of a Search Term ------------------------ Each search term consists of one of the following: 1) A search string, followed by an optional comma and set of specific search constraints. 2) A search term specifier (as listed in Table II), followed by '=', followed by a search string, followed by an optional comma and set of specific search constraints. 3) An abbreviated search term specifier, followed by a search string, followed by an optional comma and set of specific search constraints. 4) A combination of attribute name, followed by '=', followed by a search string, followed by an optional comma and set of specific search constraints. In addition to the historical search specifiers to specify a search on content, handle or mailbox provided in RFC 954, there are also identifiers to select on template type or attribute name. In keeping with the spirit of RFC 954, all identifiers have an associated single character prefix that may be used in place of the "=" format of the same identifier. If no term identifier is provided, then the search will be applied to all template names, handles, attribute names and attribute values. This corresponds to an identifier of SEARCH_ALL. When the user specifies the search term using the form: " = " This is treated as equivalent to the combined terms: "ATTRIBUTE = ; VALUE = " Note that in this case, "" can not be one of the specifiers "ATTRIBUTE", "VALUE", "HANDLE" or "TEMPLATE". For discussion of the system reply format, and selecting the appropriate format, see the section "Server Responses". Format of a Search String -------------------------- [* The actual format of a search string is not yet specified, as there is a discussion to be had concerning the use of non-ASCII (esp. but no limited to other European languages) in search strings and even attribute names, etc. We must allow for this, but this document is merely flagging this need for now. This sounds like fruitful grounds for Working Group discussions... *] Search Term Constraints ------------------------- Specific search constraints are intended to be hints or recommendations to the search engine on how to perform that part of the search. Thus, a user might specify a search constraint as "exact match", or "substring match". The CONSTRAINTS system command is used to list the search constraints supported by an individual server. [* Note: The best way to handle this is probably with either a specified list of keywords or by referring to an IANA registry of supported search types... *] If a server cannot satisfy the specified constraint there is a mechanism for informating the user in the reply, using system messages. In such cases, the search is still performed, and the server ignores unsupported constraints. ---------------------------------------------------------------------- Valid specifiers: ----------------- Short Long Form Functionality -------------------------------------------------------------------- . ATTRIBUTE Confine search to attribute fields # VALUE Confine search to attribute values ! HANDLE Confine search to handles. ^ TEMPLATE Confine search to template names * SEARCH-ALL Search everything A search term takes one of the following forms: 1) [',' ] 2) = [',' ] 3) [',' ] 4) = [',' ] Which is equivalent to the compound terms: ATTRIBUTE = ; VALUE = Table II - Search command specifiers. ---------------------------------------------------------------------- Server Response Modes ---------------------- [* we can easily support additional response modes here. *] There are currently a total of four different response modes possible for WHOIS++ servers. These are FULL, ABRIDGED, HANDLE or SUMMARY. The syntax of each output format is specified in more detail in the following section. 1) A FULL format response provides the complete contents of each template matching the specified query, including the template type and handle for each record. 2) An ABRIDGED format response provides a brief summary, including (as a minimum) the record handle and the specific information in the corresponding record that matched the query. [* this needs work *] 3) A HANDLE format response returns only a list of handles that matched the specified query. 4) A SUMMARY response provides only a brief summary of information about the number of matches and the list of template types in which the matches occured. By default, a WHOIS++ server will provide a FULL response when there is a single record matching the specified query, an ABRIDGED response when there between two and ten records matching the query and a SUMMARY response when there is more than ten records matching the specified query. The user may override these defaults by specifying the appropriate keywords as global constraints to a search command (see below). [* These numbers were chosen psuedo-randomly and are obviously open to debate... *] The server response modes are summarized in Table III. Format of Responses -------------------- Each response consists of an optional free form introductory text message, followed by any optional system generated messages, followed by a formatted response message, followed by any optional system generated messages, followed by an optional free form closing text message. That is: [ ]* ['%' ]* ['%' ]* [ ]* There is no limit on the total length or format of either the introductory or closing text message, although each line should consist of no more than 81 characters, including the terminating newline character. If there are no matches to a query, the system is not required to generate any output as a formatted response, although it may still generate system messages and/or a closing text message. All optional system generated messages must begin with a '%' as the first character and must be no more than 81 characters long, including the terminating newline character. There is no limit to the number of system messages that may be generated. Syntax of a Formatted Response ------------------------------ All formatted responses consist of a START line, followed by a response-specific section, followed by a TERMINATION line. It is permissible to insert any number of lines consisting solely of newlines within a formatted response to improve readibility. A START line consists of a line beginning with a '#' in the first column, followed by zero or more white space characters (SPACE or TAB), followed by one of the following keywords FULL, ABRIDGED, HANDLE or SUMMARY. Where the keyword is FULL, ABRIDGED or HANDLE, this is then followed by one or more white space characters, followed by a count of the number of matches found for that query, followed by zero or more white space characters, followed by a newline. A START line must contain no more than 81 characters, including the terminating newline character. A TERMINATION line consists of a line beginning with a '#' in the first column, followed by zero or more white space characters (SPACE or TAB), followed by the keyword END, followed by zero or more white space characters, followed by a newline. A TERMINATION line must contain no more than 81 characters, including the terminating newline character. A response-specific section will be one of the following: 1) FULL Format Response 2) ABRIDGED Format Response 3) HANDLE Format Response 4) SUMMARY Format Response The details of each are specified in the following sections: A FULL format response ------------------------ A FULL format response consists of a series of responses, each consisting of a FORMAT specifier line, followed by the complete template information for the matching record. Each FORMAT specifier line consists of a '#' in the first column, followed by zero or more white space characters, followed by the name of the corresponding template type, followed by one or more white space characters, followed by the handle for that record, followed by zero or more white space characters, followed by a newline. A FORMAT specifier must contain no more than 81 characters, including the terminating newline character. [* Note this implicitly puts a limit on the length of a template name. We will need to set limits for this, and probably want to allow lines longer than 80 characters. I've put the 81 char limit in as a placeholder. *] The template information for each record will be returned as a series of lines consisting of a single space, followed by the corresponding line of the record. The line of the record shall consist of the attribute name, followed by a ':', followed by at least one space, followed by the value of that attribute, followed by a newline. Each such line shall be limited to no more than 81 characters, including the terminating newline. If a line (including the required leading single space) would exceed 81 characters, it is to be broken into lines of no more than 81 characters, with each continuation line beginning with a "+" character. ABRIDGED Format Response ------------------------ An ABRIDGED format response consists of a single set of responses, consisting of a single line excerpt of the template information from each matching record. The excerpt information shall include, as a minimum, the template type and handle of the record, as well as the portion of the information that caused the match. The abridged template information for each record will be returned as a series of lines, each of which must consist of a single space, followed by the abridged line of the record. Each line shall be limited to no more than 81 characters, including the terminating newline. If a line (including the required single space, would exceed 81 characters, it is to be broken into lines of no more than 81 characters, with the remainder following on the subsequent line, with the space replaced by a "+" character. HANDLE Format Response ----------------------- A HANDLE format response consists of a single set of responses, consisting of a single line listing the handle and template type for each matching record. Each line shall start with at least one space, followed by the handle, followed by at least one space, followed by the template type, followed by zero or more white space characters and terminated by a newline. Each such line must contain no more than 81 characters, including the terminating newline character. If a line (including the required first space) would exceed 81 characters, it shall be split into multiple lines, with each continuation line beginning with a '+' instead of a space. SUMMARY Format Response ----------------------- A SUMMARY format response consists of a single set of responses, consisting of a line listing the number of matches to the specified query, followed by a list of all template types which satisfied the query at least once. The first line shall begin with the string "matches: ", be followed by the number of responses to the query and terminated by a newline. The second line shall begin with the string "templates: ", be followed by the name of the first template type which matched the query, followed by a newline. Each succeeding line shall include the name of the next template type matching the query, terminated by a newline. System Generated Messages -------------------------- Any line beginning with a '%' in the first column is to be treated as a System generated message. System generated messages may occur immediately before, within or immediately after the formatted response section of the response. System generated messages displayed before or after the formatted response section are expected to refer to operation of the system or refer to the entire query. System generated messages within the output of an individual record during a FULL reponse are expected to refer to that record only, and could (for example) be used to indicate problems with that record of the response. Compatibility with Older WHOIS Servers --------------------------------------- Note that this format, although potentially more verbose, is still in a human readible form. Responses from older systems that do not follow this format are still conformant, since their responses would be interpreted as being equivalent to optional text messages, without a formatted response. Clients written to this specification would display the responses as a advisory text message, where it would still be readible by the user. ---------------------------------------------------------------------- Format Functionality ----------------------------------------------------- FULL Returns complete template information for each record that matches the specified query. Each such record is separated by a line that specifies the template type and handle for that record. ABRIDGED Returns a one line abridged response for each record that matches the specified query. HANDLE Returns a list of handles and corresponding template types for each record that matches the specified query. SUMMARY Returns only a brief summary of number of matches and the corresponding template types which matched the specified query. Note: Default is a FULL response for a single match, an ABRIDGED response when there is between two and ten matches and a SUMMARY response when there are more than ten matches. These may be overridden by specifying the response format desired as a global contraint. Table III - Summary of WHOIS++ Response Formats. ---------------------------------------------------------------------- Some Examples: -------------------- 1) A FULL format response: # FULL 3 # USER PD45 First Name: Peter Last Name: Deutsch email: peterd@bunyip.com # USER AE1 First Name: Alan Last Name: Emtage email: bajan@bunyip.com # SERVICES WWW1 Type: World Wide Web Location: the world # END -------------------- 2) An ABRIDGED format response: # ABRIDGED 3 Peter Deutsch (PD45) peterd@bunyip.com Alan Emtage (AE1) bajan@bunyip.com World Wide Web (WWW1) the world # END -------------------- 3) A HANDLE format response: # HANDLE 3 PD45 User AE1 User WWW1 Services # END -------------------- 4) A SUMMARY HANDLE format response: # SUMMARY Matches: 175 Templates: User Services Abstracts # END Table IV - Some sample responses. ---------------------------------------------------------------------- Appendix A - The WHOIS++ BNF Grammar --------------------------------------- Here is the complete BNF grammar for the WHOIS++ extensions: [* Well, almost complete. See "Notes" at the end *] WHOIScommand ::= | SYScommand ::= [ [',' ]] | "show" [',' ] | "constraints" | "version" syscmdname1 ::= "help" | "?" | "list" WHOISquery ::= [';' ]* [':' ] term ::= | | | generalterm ::= [ ',' ] specificterm ::= '=' [ ',' ] specificname ::= "template" | "handle" | "attribute" | "value" shortterm ::= [ ',' ] shortname ::= '^' | '!' | '.' | '' | '#' | '*' globalcnstrnts ::= [ ]* | [ ]0-1 responses ::= "full" | "abridged" | "handle" | "summary" aconstraint ::= (a set of specifiers for constraints. Expect these to be a list of valid search methods... ) searchstring ::= TBD (some string that does not include or '?' but does include extended characters) To come: - BNF for response formats. - more details on searchstring - more details on what a constraint ---------------------------------------------------------------------- -- From ietf-wnils-request@ucdavis.ucdavis.edu Fri Nov 13 22:20:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03281; Fri, 13 Nov 92 22:15:55 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23040; Fri, 13 Nov 92 21:50:48 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02099; Fri, 13 Nov 92 21:45:07 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from punisher.cco.caltech.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01830; Fri, 13 Nov 92 21:38:31 -0800 Received: by punisher.caltech.edu (4.1/DEI:4.41) id AA26310; Fri, 13 Nov 92 21:38:07 PST Message-Id: <9211140538.AA26310@punisher.caltech.edu> To: peterd@bunyip.com (Peter Deutsch) Cc: ietf-wnils@ucdavis.ucdavis.edu, dank@cco.caltech.edu Subject: Re: Final pre-ietf version of architecture document In-Reply-To: Your message of "Fri, 13 Nov 92 23:36:23 GMT." <9211132336.AA16844@expresso.cc.mcgill.ca> Date: Fri, 13 Nov 92 21:38:05 -0800 From: "Daniel R. Kegel" Peter, do leave in the 'weight' barbs, they're honest & not too sharp. In many current whois servers, one does whole-name searches by setting the first name off from the last with a comma, like so: einstein, Albert This is incompatible with your proposed use of comma to set off modifiers from the main part of the query, I think. Am I right? I would miss this part of present practise if it were legislated out of existence. - Dan K. From ietf-wnils-request@ucdavis.ucdavis.edu Sat Nov 14 17:11:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27890; Sat, 14 Nov 92 17:03:49 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26757; Sat, 14 Nov 92 16:40:55 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26739; Sat, 14 Nov 92 16:34:02 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25825; Sat, 14 Nov 92 16:11:45 -0800 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08243 (mail destined for ietf-wnils-request@ucdavis.edu) on Sat, 14 Nov 92 19:10:53 -0500 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA19663; Sat, 14 Nov 92 19:03:54 EST Message-Id: <9211150003.AA19663@expresso.cc.mcgill.ca> In-Reply-To: "Daniel R. Kegel"'s message as of Nov 13, 21:38 From: peterd@bunyip.com (Peter Deutsch) Date: Sun, 15 Nov 92 00:03:52 GMT-0:02 In-Reply-To: "Daniel R. Kegel"'s message as of Nov 13, 21:38 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: "Daniel R. Kegel" Subject: Re: Final pre-ietf version of architecture document Cc: ietf-wnils@ucdavis.ucdavis.edu, dank@cco.caltech.edu [ you wrote: ] > > Peter, > do leave in the 'weight' barbs, they're honest & not too sharp. > > In many current whois servers, one does whole-name searches by setting > the first name off from the last with a comma, like so: > einstein, Albert > This is incompatible with your proposed use of comma to set off > modifiers from the main part of the query, I think. > Am I right? I would miss this part of present practise if it were > legislated out of existence. There have been a number of comments on the punctuation I'd chosen on the first go-round and we'll probably want to change several of them. As another example, someone complained about the use of ";", since this makes command line clients for UNIX get most confused. We need to discuss how much such O/S specific issues should be considered and then identify the worst offenders. I don't see this as detracting from the general scheme, and we've already got a frontend so didn't want to redo it until we'd had some feedback. I'm sure we can restore the comma to its rightful place... - peterd -- From ietf-wnils-request@ucdavis.ucdavis.edu Sat Nov 14 18:31:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01198; Sat, 14 Nov 92 18:24:00 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26990; Sat, 14 Nov 92 18:01:07 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29762; Sat, 14 Nov 92 17:52:22 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29661; Sat, 14 Nov 92 17:49:27 -0800 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA04082; Sat, 14 Nov 92 20:48:52 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA07367; Sat, 14 Nov 92 20:48:51 EST Date: Sat, 14 Nov 92 20:48:51 EST From: clw@merit.edu Message-Id: <9211150148.AA07367@home.merit.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: WHOIS++ Index Service Gang: Here's the final version of the Index service paper Chris Weider WNILS Working Group Chris Weider INTERNET-DRAFT Merit Network, Inc. Jim Fullton UNC Chapel Hill Simon Spero 11/10/92 UNC Chapel Hill Architecture of the Whois++ Index Service Status of this memo: The authors describe an archtecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. 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." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This Internet Draft expires May 10, 1993. 1. Purpose: The WHOIS++ directory service [GDS, 1992] is intended to provide a simple, extensible directory service predicated on a template-based information model and a flexible query language. This document describes an architecture designed to link together many of these WHOIS++ servers into a distributed, searchable wide area directory service. 2. Scope: This document details a distributed, easily maintained architecture for providing a unified index to a large number of distributed WHOIS++ servers. This architecture can be used with systems other than WHOIS++ to provide a distributed directory service which is also searchable. 3. Motivation and Introduction: It seems clear that with the vast amount of directory information potentially available on the Internet, it is simply unfeasible to build a centralized directory to serve all this information. Therefore, we should look at building a distributed directory service. If we are to distribute the directory service, the easiest (although not necessarily the best) way of building the directory service is to build a hierarchy of directory information collection agents. In this architecture, a directory query is delivered to a certain agent in the tree, and then handed up or down, as appropriate, so that the query is delivered to the agent which holds the information which fills the query. This approach has been tried before, most notably in some implementations of the X.500 standard. However, there are two major flaws with the approach as it has been taken. This new Index Service is designed to fix these flaws. 3.1 The search problem Current implementations of this hierarchical architecture require that a search query issued at a certain location in the directory agent tree be replicated to _all_ subtrees, because there is no way to tell which subtrees might contain the desired information. It is obvious that this has rather extreme scaling problems, and in fact the search facility has been turned off in the X.500 architecture because of this problem. Our new WHOIS++ architecture solves this problem by having a set of 'forward information' at each level of the tree. That is, each level of the tree has some idea of where to look lower in the tree to find the requested information. Consequently, the search tree can be pruned enormously, making search feasible at all levels of the tree. We have chosen a certain set of information to hand up the tree as forward information; this may or may not be exactly the set of information required to build a truly searchable directory. However, it seems clear that without some sort of forward information, the search problem becomes intractable. 3.2 The location problem Current implementations of this hierarchical architecture also encode details about the directory agent hierarchy in the location information for a specific entry. With search turned off, this requires a user to know exactly how the hierarchy of servers is laid out and how they are named, which leads to acrimonious debate about the shape of the name space and really massive headaches whenever it becomes apparant that the current namespace is unsuited to the current usages and must be changed. The new Index Service gets around this by a) not enforcing a true hierarchy on the directory agents, b) dissociating the directory service from the information served, and c) allowing new hierarchies to be built whenever necessary, without destroying the hierarchies already in place. Thus a user does not need to know in advance where in the hierarchy the information served is contained, and the information a user enters to guide the search does not ever have to explicitly show up in the hierarchy. Although there are provisions in the WHOIS++ query syntax to watch the directory service as it hand the query around, and consequently to divine the structure of the directory service hierarchy, it really is not relevant to the user, and does not ever have to be taken into consideration. 3.3 The Yellow Pages problem Current implementations of this hierarchical architecture have also been unsuited to solving the Yellow Pages problem; that is, the problem of easily and flexibly building special-purpose directories (say of molecular biologists) and of automatically maintaining these directories once they have been built. In particular with the current systems, one has to build into the name space the attributes appropriate to the new directory. Since our new Index Service very easily allows directory servers to pick and choose between information proffered by a given entry server, and because we have an architecture which allows for automatic polling of data, Yellow Pages capabilities fall very naturally out of the design. Although the ability to search all levels of the tree(s) gets us a long way towards the Yellow Pages, it is this capacity to locate, gather, and maintain information in a distributed and selective way that really solves the problem. 4. Components of the Index Service: 4.1 WHOIS++ servers The whois++ service is described in [GDS, 1992]. As that service specifies only the query language, the information model, and the server responses, whois++ services can be provided by a wide variety of databases and directory services. However, to participate in the Index Service, that underlying database must also be able to generate a 'centroid' for the data it serves. 4.2 Centroids as forward knowledge The centroid of a server is comprised of a list of the templates and attributes used by that server, and a word list for each attribute. The word list for a given attribute contains one occurrence of every word which appears at least once in that attribute in some record in that server's data, and nothing else. For example, if a whois++ server contains exactly three records, as follows: Record 1 Record 2 Template: User Template: User First Name: John First Name: Joe Last Name: Smith Last Name: Smith Favourite Drink: Labatt Beer Favourite Drink: Molson Beer Record 3 Template: Domain Domain Name: foo.edu Contact Name: Mike Foobar the centroid for this server would be Template: User First Name: Joe John Last Name: Smith Favourite Drink: Beer Labatt Molson Template: Domain Domain Name: foo.edu Contact Name: Mike Foobar It is this information which is handed up the tree to provide forward knowledge. As we mention above, this may not turn out to be the ideal solution for forward knowledge, and we suspect that there may be a number of different sets of forward knowledge used in the Index Service. However, the directory architecture is in a very real sense independent of what types of forward knowledge are handed around, and it is entirely possible to build a unified directory which uses many types of forward knowledge. 4.3 Index servers and Index server Architecture A whois++ index server collects and collates the centroids (or other forward knowledge) of either a number of whois++ servers or of a number of other index servers. An index server must be able to generate a centroid for the information it contains. 4.3.1 Queries to index servers An index server will take a query in standard whois++ format, search its collections of centroids, determine which servers hold records which may fill that query, and then forward the query to the appropriate servers. 4.3.2 Index server distribution model and centroid propogation The diagram below illustrates how a tree of index servers is created for a set of whois++ servers. whois++ index index servers servers servers for for _______ whois++ lower-level | | servers index servers | A |__ |_______| \ _______ \----------| | _______ | D |__ ______ | | /----------|_______| \ | | | B |__/ \----------| | |_______| | F | /----------|______| / _______ _______ / | | | |- | C |--------------| E | |_______| |_______| In the portion of the index tree shown above, whois++ servers A and B hand their centroids up to index server D, whois++ server C hands its centroid up to index server E, and index servers D and E hand their centroids up to index server F. The number of levels of index servers, and the number of index servers at each level, will depend on the number of whois++ servers deployed, and the response time of individual layers of the server tree. These numbers will have to be determined in the field. 4.3.4 Centroid propogation and changes to centroids Centroid propogation is initiated by an authenticated POLL command (sec. 4.2). The format of the POLL command allows the poller to request the centroid of any or all templates and attributes held by the polled server. After the polled server has authenticated the poller, it determines which of the requested centroids the poller is allowed to request, and then issues a CENTROID-CHANGES report (sec. 4.3) to transmit the data. When the poller receives the CENTROID-CHANGES report, it can authenticate the pollee to determine whether to add the centroid changes to its data. Additionally, if a given pollee knows what pollers hold centroids from the pollee, it can signal to those pollers the fact that its centroid has changed by issuing a DATA-CHANGED command. The poller can then determine if and when to issue a new POLL request to get the updated information. The DATA-CHANGED command is included in this protocol to allow 'interactive' updating of critical information. 4.3.5 Query handling and passing algorithm When an index server receives a query, it searches its collection of centroids, and determines which servers hold records which may fill that query. As whois++ becomes widely deployed, it is expected that some index servers may specialize in indexing certain whois++ templates or perhaps even certain fields within those templates. If an index server obtains a match with the query _for those template fields and attributes the server indexes_, it is to be considered a match for the purpose of forwarding the query. When the index server has completed its search to match the query to a server, it then forwards the request as shown in 5.4. Each server in the chain can then use the authentication information included in the FORWARDED-QUERY command to determine whether to continue forwarding the query. Also, a whois++ query can specify the 'trace' option, which sends to the user a string containing the IANA handle and an identification string for each index server the query is handed to. 5. Syntax for operations of the Index Service: 5.1 Data changed syntax The data changed template look like this: DATA-CHANGED: Version-number: // version number of index service software, used to insure // compatibility Time-of-latest-centroid-change: // time stamp of latest centroid change, GMT Time-of-message-generation: // time when this message was generated, GMT Server-handle: // IANA unique identifier for this server Best-time-to-poll: // For heavily used servers, this will identify when // the server is likely to be lightly loaded // so that response to the poll will be speedy, GMT Authentication-type: // Type of authentication used by server, or NONE Authentication-data: // data for authentication END DATA-CHANGED // This line must be used to terminate the data changed // message 5.2 Polling syntax POLL: Version-number: // version number of poller's index software, used to // insure compatibility Start-time: // give me all the centroid changes starting at this time, GMT End-time: // ending at this time, GMT Template: // a standard whois++ template name, or the keyword ALL, for a // full update. Field: // used to limit centroid update information to specific fields, // is either a specific field name, a list of field names, // or the keyword ALL Server-handle: // IANA unique identifier for the polling server. // this handle may optionally be cached by the polled // server to announce future changes Authentication-type: // Type of authentication used by poller, or NONE Authentication-data: // Data for authentication END POLL // This line must by used to terminate the poll message 5.3 Centroid change report CENTROID-CHANGES: Version-number: // version number of pollee's index software, used to // insure compatibility Start-time: // change list starting time, GMT End-time: // change list ending time, GMT Server-handle: // IANA unique identifier of the responding server Authentication-type: // Type of authentication used by pollee, or NONE Authentication-data: // Data for authentication Compression-type: // Type of compression used on the data, or NONE Size-of-compressed-data: // size of compressed data if compression is used Operation: // One of 3 keywords: ADD, DELETE, FULL // ADD - add these entries to the centroid for this server // DELETE - delete these entries from the centroid of this // server // FULL - the full centroid as of end-time follows Multiple occurrences of the following block of fields: Template: // a standard whois++ template name Field: // a field name within that template Data: // the word list itself, one per line, cr/lf terminated end of multiply repeated block END CENTROID-CHANGES // This line must be used to terminate the centroid // change report 5.4 Forwarded query FORWARDED-QUERY: Version-number: // version number of forwarder's index software, used to // insure compatibility Forwarded-From: // IANA unique identifier of the server forwarding query Forwarded-time: // time this query forwarded, GMT (used for debugging) Trace-option: // YES if query has 'trace' option listed, NO if not. // used at message reception time to generate trace information Query-origination-address: // address of origin of query Body-of-Query: // The original query goes here Authentication-type: // Type of authentication used by queryer Authentication-data: // Data for authentication END FORWARDED-QUERY // This line must be used to terminate the body of the // query 6 Author's Addresses Chris Weider clw@merit.edu Industrial Technology Institute, Pod G 2901 Hubbard Rd, Ann Arbor, MI 48105 O: (313) 747-2730 F: (313) 747-3185 Jim Fullton fullton@mdewey.ga.unc.edu 310 Wilson Library CB #3460 University of North Carolina Chapel Hill, NC 27599-3460 O: (919) 962-9107 F: (919) 962-5604 Simon Spero ses@sunsite.unc.edu 310 Wilson Library CB #3460 University of North Carolina Chapel Hill, NC 27599-3460 O: (919) 962-9107 F: (919) 962-5604 From ietf-wnils-request@ucdavis.ucdavis.edu Fri Nov 20 04:31:59 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15299; Fri, 20 Nov 92 04:28:43 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01373; Fri, 20 Nov 92 03:59:45 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13608; Fri, 20 Nov 92 03:50:15 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13072; Fri, 20 Nov 92 03:40:08 -0800 Received: from dale.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA28213; Fri, 20 Nov 92 03:38:58 PST From: ccjoan@bullwinkle.ucdavis.edu Date: Fri, 20 Nov 92 03:38:58 PST Message-Id: <9211201138.AA28213@bullwinkle.ucdavis.edu> To: jkrey@isi.edu, ietf-wnils@ucdavis.ucdavis.edu Subject: Minutes Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano Whois and Network Information Lookup Service (WNILS) Minutes November 18, 1992 I. Introduction and Overview Joan Gargano spoke briefly about the impetus for starting the working group and development of the Whois++ application. This was followed by presentations by the developers. II. Architecture of Whois++ Peter Deutsch presented an overview of the Whois++ architecture. Peter described the prototype system, the currently supported query syntax and areas for improvement. III.Centroids Chris Weider provided an overview of the mechanism used to build a distributed directory service called "centroids". Simon Spero continued with a discussion of the underlying theory of centroids which has been used by other groups studying information retrieval issues. IV. Sample Server Jim Fullton presented a brief overview of the Whois++ server developed at CNRI. Jim describe his system which was built using standard Unix utilities. Response times of 15 seconds to query a database of 30,000 records was reported, however Jim felt significant improvements could be achieved with software designed and coded to optimize the system. Servers for testing are available at CNRI and UC Davis. It is anticipated about 10 new servers will be in place within a couple of weeks. V. Questions The floor was opened for questions and general discussion of the protocol. VI. Future The Whois++ developers solicited input about desired features. The following work was recommended. 1. A feature to allow servers to pass information about servers that poll them to optimize searching. 2. A description of printer output format. 3. There needs to be a clearinghouse for templates. It was recommended this be performed by CNIDR. 4. Privacy and security features. 5. A method for handling replication of services. 6. Further discussion about usernames and attributes. 7. A method for using synonyms with queries. 8. A method to abort searches and continue searches. 9. Provide the ability to store and pass images. 10. A way to limit the attributes returned by a search. 11. A method for tagging attributes. Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Sat Nov 21 14:41:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16089; Sat, 21 Nov 92 14:37:20 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05384; Sat, 21 Nov 92 14:09:53 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14852; Sat, 21 Nov 92 14:01:03 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from punisher.cco.caltech.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14562; Sat, 21 Nov 92 13:53:52 -0800 Received: by punisher.caltech.edu (4.1/DEI:4.41) id AA13487; Sat, 21 Nov 92 13:53:36 PST Message-Id: <9211212153.AA13487@punisher.caltech.edu> To: clw@merit.edu Cc: ietf-wnils@ucdavis.ucdavis.edu, spaf@cs.purdue.edu Subject: Re: WHOIS++ Index Service In-Reply-To: Your message of "Sat, 14 Nov 92 20:48:51 EST." <9211150148.AA07367@home.merit.edu> Date: Sat, 21 Nov 92 13:53:34 -0800 From: "Daniel R. Kegel" I read and liked the index server proposal. I'm a little worried about security and space problems with the Centroid concept as proposed: >4.2 Centroids as forward knowledge >The centroid of a server is comprised of a list of the templates and >attributes used by that server, and a word list for each attribute. >The word list for a given attribute contains one occurrence of every >word which appears at least once in that attribute in some record in that >server's data, and nothing else. The name is misleading, isn't it? Rather than embodying the center of the name space, doesn't it emphasize the outliers? That is, it spends as many bits on the noisiest, least common names as on the most common names, and therefore might grow uncomfortably large as more and more names are added. Seems to me that the problem of checking to see whether a name is in a Centroid is the same problem as checking to see whether a password is in a dictionary. Gene Spafford has shown that a hash table approach has size, speed, and security advantages, which I think might be important for the index service. In particular, I suspect sites like MIT would violently object to handing anybody a plaintext centroid, but would have fewer problems handing out a hash table version of the same. -Dan Kegel (Dank@cco.caltech.edu) >Date: Sat, 15 Feb 92 20:31:22 EST >>From: Gene Spafford >For over a year, I've been working on a multi-hash scheme for >rejecting passwords, related to what you described in your posting. >A paper was presented on this at the last National Computer Security >Conference in DC, and an expanded version is to appear in the journal >"Computers & Security" (one of the next two issues). >If you send me a surface mail address, I can send you a tech report >version of the conference paper. >Gene Spafford >NSF/Purdue/U of Florida Software Engineering Research Center, >Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398 >Internet: spaf@cs.purdue.edu phone: (317) 494-7825 From ietf-wnils-request@ucdavis.ucdavis.edu Sat Nov 21 15:50:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18504; Sat, 21 Nov 92 15:47:01 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05633; Sat, 21 Nov 92 15:19:43 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17241; Sat, 21 Nov 92 15:11:00 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from SunSite.unc.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16912; Sat, 21 Nov 92 15:01:24 -0800 Received: from localhost.oit.unc.edu by SunSite.unc.edu (4.1/TAS/11-16-88) id AA10905; Sat, 21 Nov 92 17:59:18 EST Message-Id: <9211212259.AA10905@SunSite.unc.edu> To: "Daniel R. Kegel" Cc: clw@merit.edu, ietf-wnils@ucdavis.ucdavis.edu, spaf@cs.purdue.edu Subject: Re: WHOIS++ Index Service In-Reply-To: Your message of "Sat, 21 Nov 92 13:53:34 PST." <9211212153.AA13487@punisher.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 21 Nov 92 17:59:18 -0500 From: Simon Spero "Daniel R. Kegel" writes: > >The name is misleading, isn't it? Rather than embodying the center >of the name space, doesn't it emphasize the outliers? >That is, it spends as many bits on the noisiest, least common names >as on the most common names, and therefore might grow uncomfortably >large as more and more names are added. Daniel- Centroids are a concept from the information retrieval world; basically, one model often used for modelling similarities between documents is the "vector space" model. In this model, the terms/concepts in a document are considered to be the directions in a position vector (warning - don't try and visualise 50,000-space. UNC is not responsible for any fused cerrebellums.). In physics, the centroid of a group of objects is the point at which the masses of the constituent objects are considered to act; in concept space, the centroid is the point in vector space which represents all the documents in the cluster. A good introduction to these concepts can be found in Gerard Salton's "Automated text processing" (adison wesley) Centroids do give some privacy, as you can't tell which attributes are related (i.e. you can tell that UNC has a Spero, and that UNC has some WAIS hackers, but you can't tell that the two are the same). The problem with just having a black box function which only allows probes for presence or absence is that makes merging two separate centroids impossible given the presence of indefinite length keys, and NP-hard otherwise. Simon From ietf-wnils-request@ucdavis.ucdavis.edu Sat Nov 21 21:02:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28747; Sat, 21 Nov 92 20:52:58 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06612; Sat, 21 Nov 92 20:29:51 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27697; Sat, 21 Nov 92 20:20:18 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from punisher.cco.caltech.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27384; Sat, 21 Nov 92 20:13:02 -0800 Received: by punisher.caltech.edu (4.1/DEI:4.41) id AA03155; Sat, 21 Nov 92 20:12:38 PST Message-Id: <9211220412.AA03155@punisher.caltech.edu> To: Simon Spero Cc: "Daniel R. Kegel" , clw@merit.edu, ietf-wnils@ucdavis.ucdavis.edu, spaf@cs.purdue.edu, dank@cco.caltech.edu Subject: Re: WHOIS++ Index Service In-Reply-To: Your message of "Sat, 21 Nov 92 17:59:18 EST." <9211212259.AA10905@SunSite.unc.edu> Date: Sat, 21 Nov 92 20:12:36 -0800 From: "Daniel R. Kegel" >The problem with just having a black box function which only allows probes >for presence or absence is that makes merging two separate centroids impossible >given the presence of indefinite length keys, and NP-hard otherwise. I am proposing that the hash tables - which are certainly not black boxes - be sent from whois server to index server. They can be merged in linear time. They would be smaller than the actual centroid (if Spafford's work is any guide). While not really increasing security very much, the small amount of shrouding they provide might satisfy the folks at MIT. -Dan From ietf-wnils-request@ucdavis.ucdavis.edu Sun Nov 22 12:30:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01034; Sun, 22 Nov 92 12:21:09 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00345; Sun, 22 Nov 92 11:59:42 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25148; Sun, 22 Nov 92 11:32:24 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from [18.72.1.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25048; Sun, 22 Nov 92 11:29:22 -0800 Received: from ROSEBUD.MIT.EDU by Athena.MIT.EDU with SMTP id AA16107; Sun, 22 Nov 92 14:28:32 EST From: mhpower@Athena.MIT.EDU Received: by rosebud.MIT.EDU (AIX 3.1/UCB 5.61/4.7) id AA06500; Sun, 22 Nov 92 14:28:28 -0500 Message-Id: <9211221928.AA06500@rosebud.MIT.EDU> To: dank@cco.caltech.edu Cc: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: WHOIS++ Index Service Date: Sun, 22 Nov 92 14:28:26 EST >I am proposing that the hash tables - which are certainly not black boxes - >be sent from whois server to index server. Using hashed values in the index servers seems to preclude effective use of server search constraints. For example, peterd's paper suggests > Thus, a user >might specify a search constraint as "exact match", or "substring match". >The CONSTRAINTS system command is used to list the search constraints >supported by an individual server. The hashed value of a substring probably won't be a substring of the hashed value of the entirety. This becomes even less likely if we go from "substring match" to "fuzzy match". >While not really increasing security very much, the small amount of shrouding >they provide might satisfy the folks at MIT. I'm not the "folk at MIT" referred to here (i.e., I don't administer a directory service for MIT), but there do seem to be a number of security and privacy issues that sites should consider before shipping out a centroid. Some may be irrelevant if participants in the index service are sufficiently trustworthy. This isn't a complete solution, though, if the centroid will be sent in plain text (i.e., because of problems with exporting encryption software to all the countries that may want to participate). Here, I mean reversible encryption of the entire centroid -- something entirely different from the hash-table idea. Anyway, here are a few that I've thought of: -- you'd like users to be able to query on an e-mail address and get back a real name, but you don't want to ship a centroid disclosing all your e-mail addresses, since -- someone might send junk mail to all of them -- they're valid login names on externally attackable machines -- they include all of your host names, which aren't otherwise available (e.g., via DNS zone transfers) -- they roughly specify job descriptions (e.g., all the engineers have e-mail addresses username@eng.foobar.com) -- given the length of the word list for an attribute, the total number of words (e.g., how many names when the duplicates are included) can be estimated fairly well. You don't want people to know how many names you have, since -- you're a public-access site and don't want competitors to find out how many customer accounts you have -- you're a privately held company and don't want it widely known how many employees you have, for various competitive reasons -- you're a small company (obviously these are becoming more and more prevalent on the Internet), and you don't want an outsider to get a list of everyone's lastname, since they could try to contact all your employees and offer them jobs elsewhere Matt From ietf-wnils-request@ucdavis.ucdavis.edu Sun Nov 22 16:21:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09349; Sun, 22 Nov 92 16:11:10 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01372; Sun, 22 Nov 92 15:50:12 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08207; Sun, 22 Nov 92 15:40:46 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from punisher.cco.caltech.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07906; Sun, 22 Nov 92 15:31:12 -0800 Received: by punisher.caltech.edu (4.1/DEI:4.41) id AA25555; Sun, 22 Nov 92 15:30:44 PST Message-Id: <9211222330.AA25555@punisher.caltech.edu> To: mhpower@athena.mit.edu Cc: dank@cco.caltech.edu, ietf-wnils@ucdavis.ucdavis.edu Subject: Re: WHOIS++ Index Service In-Reply-To: Your message of "Sun, 22 Nov 92 14:28:26 EST." <9211221928.AA06500@rosebud.MIT.EDU> Date: Sun, 22 Nov 92 15:30:43 -0800 From: "Daniel R. Kegel" Matt writes: >Using hashed values in the index servers seems to preclude effective >use of server search constraints. Not necessarily. A hash table indexed by triple letter combinations would allow fuzzy searching (and nothing else) while still providing some shrouding. The table could be miniscule- about 30*30*30 bits, or 4 kilobytes- and would stay that small regardless of how big the whois database got. (I'm not sure whether it would support other search constraints- but then, the index is just a way to guide the search, it doesn't have to support every constraint.) Companies who want to obfusicate the size of their staff could add 'salt' to the hash table more convincingly than they could 'salt' a plain-text centroid, I think. Um, I'll shut up if nobody else is interested in discussing problems with or alternatives to the plain-text centroid, but I thought I ought to at least mention my misgivings. - Dan Kegel (dank@cco.caltech.edu) From ietf-wnils-request@ucdavis.ucdavis.edu Sun Nov 22 16:50:57 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10519; Sun, 22 Nov 92 16:48:34 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01540; Sun, 22 Nov 92 16:30:01 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09816; Sun, 22 Nov 92 16:22:45 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from SunSite.unc.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09650; Sun, 22 Nov 92 16:17:49 -0800 Received: from localhost.oit.unc.edu by SunSite.unc.edu (4.1/TAS/11-16-88) id AA18555; Sun, 22 Nov 92 19:15:51 EST Message-Id: <9211230015.AA18555@SunSite.unc.edu> To: "Daniel R. Kegel" Cc: mhpower@athena.mit.edu, ietf-wnils@ucdavis.ucdavis.edu Subject: Re: WHOIS++ Index Service In-Reply-To: Your message of "Sun, 22 Nov 92 15:30:43 PST." <9211222330.AA25555@punisher.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 Nov 92 19:15:51 -0500 From: Simon Spero Hashing very large dictionaries into a 4Kb table is going to get unseemly numbers of collisions. The information hiding mechanism that I mentioned before (just say who you are, and make them come to you for stuff you don't want to publish) seems to offer the best compromise. If people find that they are l losing out by not being in the directory, then they will offer more information. The architecture can cope with the whole continuum Simon From ietf-wnils-request@ucdavis.ucdavis.edu Mon Nov 23 07:20:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04273; Mon, 23 Nov 92 07:17:17 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04040; Mon, 23 Nov 92 06:49:40 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03605; Mon, 23 Nov 92 06:41:33 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from arthur.cs.purdue.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03556; Mon, 23 Nov 92 06:37:32 -0800 Received: from uther.cs.purdue.edu by arthur.cs.purdue.edu (5.65c/PURDUE_CS-1.2) id ; Mon, 23 Nov 1992 09:36:54 -0500 Received: from localhost by uther.cs.purdue.edu (5.65c/PURDUE_CS-1.2) id ; Mon, 23 Nov 1992 09:36:53 -0500 Message-Id: <199211231436.AA24738@uther.cs.purdue.edu> To: "Daniel R. Kegel" Cc: clw@merit.edu, ietf-wnils@ucdavis.ucdavis.edu Subject: Re: WHOIS++ Index Service In-Reply-To: Message from "Daniel R. Kegel" of "Sat, 21 Nov 92 13:53:34 -0800" <9211212153.AA13487@punisher.caltech.edu> Date: Mon, 23 Nov 92 09:36:53 EST From: Gene Spafford I can't glean enough detail from the e-mail I've gotten via cc's to understand the problem, but I'll outline the algorithm I've been using for my work. It's an old technique, known as a Bloom filter. It can also be referred to as a "probabilistic membership checker" because it gives you a probably-true/definitely-false membership test. Basically, one creates one or more large hash tables. Then, for each word to be added, the word is run through several independent hash functions. The corresponding bits are set in the table. To look up a word, it is run through the same functions and all corresponding bits are examined. If any bit is reset (not set), then the word was never entered into the filter. If all bits are set, the word can be assumed to *probably* have been entered. By adjusting the number of hash functions, the number of bits per table, and the number of independent tables, one can achieve an arbitrary level of confidence in a positive determination. Additions and probes are constant time. Duplicates are automatically filtered. "Near" matches are not easily accomodated, but transformations using something like a phonetic spelling allow some collapsing of similar values. Deletions are not possible -- the filter needs to rebuilt (more than one word can cause any bit to be set). If the same size table is used with identical functions, merging two tables is a simple "or" operation on the two tables. For instance, having a local name-table and a global table can be done, with the global table being the simple "or" performed on all the local tables. That's it in brief. If you need more specific references, let me know. --spaf PS. I'm glad my paper sparked some interest! From ietf-wnils-request@ucdavis.ucdavis.edu Mon Nov 23 11:30:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11648; Mon, 23 Nov 92 11:14:06 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06208; Mon, 23 Nov 92 10:41:40 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09977; Mon, 23 Nov 92 10:36:27 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09397; Mon, 23 Nov 92 10:23:44 -0800 Received: from dale.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA05017; Mon, 23 Nov 92 10:23:06 PST From: ccjoan@bullwinkle.ucdavis.edu Date: Mon, 23 Nov 92 10:23:05 PST Message-Id: <9211231823.AA05017@bullwinkle.ucdavis.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Amsterdam IETF Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano > To: wgchairs@NRI.Reston.VA.US, bofchairs@NRI.Reston.VA.US > From: Megan Davies > > M E M O R A N D U M > > TO: Working Group/BOF Chairs > FROM: IETF Secretariat > SUBJECT: Projected attendance at Amsterdam IETF (July 1993) > > So that we can make appropriate provisions for the upcoming European IETF > in Amsterdam (July 12-16, 1993), we are asking the Working Group/BOF Chairs > to poll their groups for the following information: > > 1. Do you plan on holding a session of your working group at the Amsterdam > meeting? I expect this group to still be intact and working in Amsterdam. > 2. How many folks in your working group session at D.C. expect to attend the > session of your group which meets in Amsterdam? How many of you expect to attend the Amsterdam meeting? And: > 3. How many folks would plan to attend if the meeting fee was raised in order > to compensate for additional meeting expenses? Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Mon Nov 23 11:30:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11678; Mon, 23 Nov 92 11:14:51 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06148; Mon, 23 Nov 92 10:32:27 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09608; Mon, 23 Nov 92 10:28:37 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09007; Mon, 23 Nov 92 10:15:13 -0800 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA09643; Mon, 23 Nov 92 13:14:27 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA23705; Mon, 23 Nov 92 13:14:26 EST Date: Mon, 23 Nov 92 13:14:26 EST From: clw@merit.edu Message-Id: <9211231814.AA23705@home.merit.edu> To: dank@cco.caltech.edu, mhpower@athena.mit.edu Subject: Re: WHOIS++ Index Service Cc: ietf-wnils@ucdavis.ucdavis.edu Dan: One of the primary benefits of the Index Server architecture is that it is independent of the forward information handed around. Therefore, I think that it is entirely appropriate to discuss alternatives to plain-text centroids. Also, although it make the servers more complex, I firmly believe that we will have a directory mesh with more than one type of forward information passed around. I just got back, so I'll be able to discuss this more fully in a bit. Chris From ietf-wnils-request@ucdavis.ucdavis.edu Tue Nov 24 23:41:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15797; Tue, 24 Nov 92 23:36:32 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29075; Tue, 24 Nov 92 22:50:14 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13713; Tue, 24 Nov 92 22:40:36 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13382; Tue, 24 Nov 92 22:32:00 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA04912; Wed, 25 Nov 1992 17:01:14 +1030 Message-Id: <9211250631.AA04912@jarrah.itd.adelaide.edu.au> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Peter's proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 92 17:01:13 +1030 From: Mark Prior Did any changes to Peter's draft get made in Washington or is it safe for me to start transforming my X.500 based whois server? Mark. From ietf-wnils-request@ucdavis.ucdavis.edu Wed Nov 25 00:52:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18723; Wed, 25 Nov 92 00:47:49 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29500; Wed, 25 Nov 92 00:20:00 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17332; Wed, 25 Nov 92 00:12:10 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16895; Wed, 25 Nov 92 00:03:01 -0800 Received: from dale.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA07318; Wed, 25 Nov 92 00:02:16 PST From: ccjoan@bullwinkle.ucdavis.edu Date: Wed, 25 Nov 92 00:02:16 PST Message-Id: <9211250802.AA07318@bullwinkle.ucdavis.edu> To: mrp@itd.adelaide.edu.au Subject: Re: Peter's proposal Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano Cc: ietf-wnils@ucdavis.ucdavis.edu > Did any changes to Peter's draft get made in Washington or is it safe > for me to start transforming my X.500 based whois server? No changes were made to any of the documents, although additions and clarifications were suggested. The first release of the code is scheduled to be available by January 15 based upon the current documents. Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Wed Nov 25 10:04:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09412; Wed, 25 Nov 92 09:58:55 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02069; Wed, 25 Nov 92 08:10:44 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05151; Wed, 25 Nov 92 08:02:54 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04878; Wed, 25 Nov 92 07:56:19 -0800 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18156 (mail destined for ietf-wnils-request@ucdavis.edu) on Wed, 25 Nov 92 10:55:30 -0500 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA20179; Wed, 25 Nov 92 10:48:28 EST Message-Id: <9211251548.AA20179@expresso.cc.mcgill.ca> In-Reply-To: jcgargano@ucdavis.edu's message as of Nov 25, 0:02 From: peterd@bunyip.com (Peter Deutsch) Date: Wed, 25 Nov 92 15:48:27 GMT-0:02 In-Reply-To: jcgargano@ucdavis.edu's message as of Nov 25, 0:02 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: ietf-wnils-request@ucdavis.ucdavis.edu, mrp@itd.adelaide.edu.au Subject: Re: Peter's proposal Cc: ietf-wnils@ucdavis.ucdavis.edu [ you wrote: ] > > > Did any changes to Peter's draft get made in Washington or is it safe > > for me to start transforming my X.500 based whois server? > > No changes were made to any of the documents, although additions and > clarifications were suggested. The first release of the code is scheduled > to be available by January 15 based upon the current documents. Ooops, sorry Joan. I didn't see your posting. I did leave with the impression that the Jan.15 release would incorporate the suggested additions. This will of course depend upon how much time we can find to work on it, but I think it both feasible and desirable to include the suggested additions in the first major release. - peterd -- From ietf-wnils-request@ucdavis.ucdavis.edu Wed Nov 25 10:04:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09414; Wed, 25 Nov 92 09:59:02 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02058; Wed, 25 Nov 92 08:09:48 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05140; Wed, 25 Nov 92 08:02:44 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04749; Wed, 25 Nov 92 07:53:13 -0800 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18115 (mail destined for ietf-wnils-request@ucdavis.edu) on Wed, 25 Nov 92 10:52:28 -0500 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA20164; Wed, 25 Nov 92 10:45:27 EST Message-Id: <9211251545.AA20164@expresso.cc.mcgill.ca> In-Reply-To: Mark Prior's message as of Nov 25, 17:01 From: peterd@bunyip.com (Peter Deutsch) Date: Wed, 25 Nov 92 15:45:25 GMT-0:02 In-Reply-To: Mark Prior's message as of Nov 25, 17:01 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: Mark Prior , ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Peter's proposal [ you wrote: ] > > Did any changes to Peter's draft get made in Washington or is it safe > for me to start transforming my X.500 based whois server? There were a number of enhancements and extensions added which I will try to fold into the draft in the next couple of days. My current target is to get the draft out before Friday, but people have heard me say _that_ before! The changes are just about all extensions. For example, we're adding a "polled-by" command, so you can find indexing servers which are tracking a specific site. This will allow clients to "walk up" the tree, finding additional servers automatically. We're also adding a new output format of type "POINTER", which will allow a site to return a pointer to another site which might have the answer needed. This would be returned by an indexing server, or by a leaf WHOIS server as a hint to the client about where an answer might reside. There's quite a bit more and I've got it all on slides, notes and scraps of paper. Also, Joan posted a summary a couple of days ago as part of the minutes. Again, I need a few days of cleaning up before I can finish reworking the document. So, short answer is "not quite yet". We're shooting for a general release of our pilot public domain server, with all the changes merged in, plus Open Look, Windows etc clients by January 15. This will be a packaged tar file ready to install, hopefully with documentation. The strawman doc should be out by the end of November... - peterd -- From ietf-wnils-request@ucdavis.ucdavis.edu Wed Nov 25 17:41:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28410; Wed, 25 Nov 92 17:31:33 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08611; Wed, 25 Nov 92 16:51:08 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25989; Wed, 25 Nov 92 16:34:35 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25102; Wed, 25 Nov 92 16:14:12 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 16:14:12 -0800 Message-Id: <9211260014.AA25102@ucdavis.ucdavis.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04878; Wed, 25 Nov 92 07:56:19 -0800 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18156 (mail destined for ietf-wnils-request@ucdavis.edu) on Wed, 25 Nov 92 10:55:30 -0500 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA20179; Wed, 25 Nov 92 10:48:28 EST Message-Id: <9211251548.AA20179@expresso.cc.mcgill.ca> In-Reply-To: jcgargano@ucdavis.edu's message as of Nov 25, 0:02 From: peterd@bunyip.com (Peter Deutsch) Date: Wed, 25 Nov 92 15:48:27 GMT-0:02 In-Reply-To: jcgargano@ucdavis.edu's message as of Nov 25, 0:02 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: ietf-wnils-request@ucdavis.edu, mrp@itd.adelaide.edu.au Subject: Re: Peter's proposal Cc: ietf-wnils@ucdavis.edu [ you wrote: ] > > > Did any changes to Peter's draft get made in Washington or is it safe > > for me to start transforming my X.500 based whois server? > > No changes were made to any of the documents, although additions and > clarifications were suggested. The first release of the code is scheduled > to be available by January 15 based upon the current documents. Ooops, sorry Joan. I didn't see your posting. I did leave with the impression that the Jan.15 release would incorporate the suggested additions. This will of course depend upon how much time we can find to work on it, but I think it both feasible and desirable to include the suggested additions in the first major release. - peterd -- From ietf-wnils-request@ucdavis.ucdavis.edu Wed Nov 25 17:41:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28475; Wed, 25 Nov 92 17:32:43 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08754; Wed, 25 Nov 92 17:06:56 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26786; Wed, 25 Nov 92 16:55:09 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26304; Wed, 25 Nov 92 16:44:02 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA11124; Thu, 26 Nov 1992 11:12:59 +1030 Message-Id: <9211260042.AA11124@jarrah.itd.adelaide.edu.au> To: peterd@bunyip.com (Peter Deutsch) Cc: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Peter's proposal In-Reply-To: Your message of "Wed, 25 Nov 92 15:45:25 GMT." <9211251545.AA20164@expresso.cc.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Nov 92 11:12:59 +1030 From: Mark Prior So, short answer is "not quite yet". We're shooting for a general release of our pilot public domain server, with all the changes merged in, plus Open Look, Windows etc clients by January 15. This will be a packaged tar file ready to install, hopefully with documentation. The strawman doc should be out by the end of November... Well as long as you remember that there are other people out there who want to implement the server using their own system. I don't want the situation where I have to reverse engineer your server! Mark. From ietf-wnils-request@ucdavis.ucdavis.edu Thu Nov 26 08:00:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01543; Thu, 26 Nov 92 07:54:29 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11591; Thu, 26 Nov 92 07:29:40 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00393; Thu, 26 Nov 92 07:20:16 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29898; Thu, 26 Nov 92 07:10:42 -0800 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29341 (mail destined for ietf-wnils@ucdavis.edu) on Thu, 26 Nov 92 10:09:46 -0500 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA23383; Thu, 26 Nov 92 10:02:42 EST Message-Id: <9211261502.AA23383@expresso.cc.mcgill.ca> In-Reply-To: Mark Prior's message as of Nov 26, 11:43 From: peterd@bunyip.com (Peter Deutsch) Date: Thu, 26 Nov 92 15:02:40 GMT-0:02 In-Reply-To: Mark Prior's message as of Nov 26, 11:43 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: Mark Prior Subject: Re: Peter's proposal Cc: ietf-wnils@ucdavis.ucdavis.edu [ you wrote: ] . . . > By reverse engineer I didn't mean decompile an existing server, I > meant having to use it as a source of the protocol specification. I > want to ensure that everyone has a level playing field in which to > start their implementation. > > >From your initial proposal there are things that I cannot do, such as > restrict the line lengths when handles are involved. I can guarantee > that my handles will be >80 characters long. I hope there was someone > from the X.500 community at the meeting who raised this issue. This is exactly why we've started circulating the spec at such an early stage. I certainly don't expect people to be determining the spec by examining our code, and if that's what people have to do you can reast assured that the IESG would reject the draft. To advance up the standards track we'll need a solid spec _and_ multiple interacting implementations. BTW, no one from the X.500 world raised the issue of line lengths, although to be fair, the draft went out very late and few people have had the chance to study it closely. At the same time, I want to remind everyone that this is _not_ X.500, nor Oracle, nor any other source of data. We are proposing our own WHOIS++ format which is intended for communication among WHOIS++ clients and servers. Our output format is such that I hope information from any other system is convertible to it, which is why we have a mechanism for folding long lines (since we'd assumed that such lines would exist) but we didn't try to "fix" X.500 any more than we tried to "fix" WAIS (which is the database engine in our pilot). In the particular case of the line length restrictions, they were put in as a place-holder after discussion with a couple of people who had told me they would be writing clients. These people seemed to think a strongly formatted output would help ease their job so I put in the existing restriction pending discussion about whether such a restriction would be needed at all, and if so what it should look like. There are a number of places such as this in the documents. I will say that the advantage of specifying fixed, 80 column lines is that those using a command line client could expect the screen not to wrap in peculiar ways and client authors could predict what they would be receiving. If no one sees the worth for this, then we'll drop it without regret, since _I_ don't need it for the frontend I'm working on. On the other hand, if the rough consensus is that such restrictions are useful then they should probably stay. Remember, the line-wrapping convention doesn't mean you can't have longer output, only that it must be folded for sending. The leading '+' in the first column makes this obvious when it's happened, so smart clients can always rebuild it and I had hoped that it would still be readible by the naked eye. How about it - doesn't anyone else care one way or the other? Now's the time to speak up. - peterd -- From ietf-wnils-request@ucdavis.ucdavis.edu Thu Nov 26 15:30:14 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16588; Thu, 26 Nov 92 15:23:35 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12721; Thu, 26 Nov 92 14:59:42 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16088; Thu, 26 Nov 92 14:50:40 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from pandora.sf.ca.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15920; Thu, 26 Nov 92 14:45:23 -0800 Newsgroups: list.ietf.wnils Path: mitra From: Mitra Subject: Re: Peter's proposal Organization: Pandora Systems Date: Thu, 26 Nov 1992 22:40:58 GMT Message-Id: X-Newsreader: TIN [version 1.1 PL6] References: <9211261502.AA23383@expresso.cc.mcgill.ca> Apparently-To: Thanks for the copy of the proposal Peter, here are some comments on it . Sorry if I'm revisiting some of the discussion. Abridged Mode: Why does this HAVE TO return the information that matched t the query, I believe that the fields returned should be a function of the template, or be specifiable by the user. For example if I'm searching for members of XYZ organization, I probably dont want that listed, but do want the names of the people. Selecting which mode to return: Allowing the user to specify this may not be the right response, in Z39.50 you can specify upper and lower bounds so for example the user could specify: 1-3 FULL, 4-22 ABRIDGED >22 SUMMARY I'm not sure how to do this in the protocol, maybe a pair of numbers 3;22 Format of responses: Since this format is really close to the tag ":" value format beloved of RGC's 822, 1036 etc why has the choice been taken to define a new format. It would be more consistent to have the format be each tag at the start of a line (no leading space) and use leading white-space as the indication of a continution line rather than the "+" you suggest. The SUMMARY record isnt adequately specified for reading by machine, e.g. a smart client, you say "Each succeeding line shall INCLUDE the name of the next template type" If you mean the line shall BE the name of the next template type then fine. I think the SUMMARY would be better defined to include the number of hits from each template. Hope this is usefull. - Mitra From ietf-wnils-request@ucdavis.ucdavis.edu Thu Nov 26 23:40:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23791; Thu, 26 Nov 92 23:33:25 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13748; Thu, 26 Nov 92 23:09:38 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22885; Thu, 26 Nov 92 23:02:04 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22767; Thu, 26 Nov 92 22:58:49 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA22487; Fri, 27 Nov 1992 17:28:03 +1030 Message-Id: <9211270658.AA22487@jarrah.itd.adelaide.edu.au> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Comments on the Architecture Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Nov 92 17:28:02 +1030 From: Mark Prior Firstly a couple of small points. 1. "describe" is missing from the BNF, it should be listed as a SYScommand (I think). 2. The characters ":", ";", and "," should be excluded from the search strings, otherwise parsing the command is a real hassle. The document describes the format of the responses to search queries but it is unclear what format should be used for the other queries have produce a response (ie help, list, show, contraints, version and describe). Are these to be treated as unformatted text messages, system messages or should there be a fifth style of formatted response or should there be additional formatted response types for each of them? At the moment I have my server using unformatted for help, constraints and describe and system messages for the others, but I think I would favour multiple formatted responses instead. Using system responses is probably a bad idea as it will make things difficult for clients to distinguish between diagnostics and the actual response. All I think is necessary is a header "# [ ]* " and the standard termination line (where is the command name ( "HELP" is printed even if the user used "?")). Mark. From ietf-wnils-request@ucdavis.ucdavis.edu Tue Dec 1 04:00:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02437; Tue, 1 Dec 92 03:52:25 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01645; Tue, 1 Dec 92 03:19:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01327; Tue, 1 Dec 92 03:10:36 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from [150.80.254.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01235; Tue, 1 Dec 92 03:08:05 -0800 Received: from cosmos.aic.co.jp ([150.80.4.1]) by aic-wide.aic.co.jp (4.1/2.7W) id AA04817; Tue, 1 Dec 92 20:07:12 JST Received: from beat.aic.co.jp by cosmos.aic.co.jp (4.0/6.4J.6-92/2) id AA02894; Tue, 1 Dec 92 20:07:10 JST Received: by beat.aic.co.jp (4.1/6.4J.6-91/1/29) id AA00555; Tue, 1 Dec 92 20:07:10 JST Date: Tue, 1 Dec 92 20:07:10 JST From: Thomas Johannsen Return-Path: Message-Id: <9212011107.AA00555@beat.aic.co.jp> To: ietf-wnils@ucdavis.ucdavis.edu Subject: [GDS, 1992] ? Chris et al, I found time to have a first look at your document "Architecture of the Whois++ Index Service". Though I'm not through yet, I think it's quite interesting. Unfortunately, I was not able to resolve the reference "[GDS, 1992]". I'm afraid I missed some of the related discussion on this list - could somebody please point me to the background info for your WHOIS++ directory service? Thank you - Thomas +---------------------------------------------------------------------+ | Thomas Johannsen Internet: thomas@aic.co.jp | | AIC Systems Lab. BITNET: JOHANNSE at DDDTU1 | | 6-6-3 Minami Yoshinari Fax: +81 22 279 3640 | | 989-32 Sendai (Japan) X.500-ufn: Johannsen, AIC, JP | +---------------------------------------------------------------------+ From ietf-wnils-request@ucdavis.ucdavis.edu Tue Dec 1 23:50:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11954; Tue, 1 Dec 92 23:40:56 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12644; Tue, 1 Dec 92 22:59:31 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10428; Tue, 1 Dec 92 22:55:10 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from [150.80.254.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09996; Tue, 1 Dec 92 22:40:35 -0800 Received: from cosmos.aic.co.jp ([150.80.4.1]) by aic-wide.aic.co.jp (4.1/2.7W) id AA18429; Wed, 2 Dec 92 15:39:17 JST Received: from beat.aic.co.jp by cosmos.aic.co.jp (4.0/6.4J.6-92/2) id AA00644; Wed, 2 Dec 92 15:39:09 JST Received: by beat.aic.co.jp (4.1/6.4J.6-91/1/29) id AA00394; Wed, 2 Dec 92 15:39:15 JST Date: Wed, 2 Dec 92 15:39:15 JST From: Thomas Johannsen Return-Path: Message-Id: <9212020639.AA00394@beat.aic.co.jp> To: clw@merit.edu Subject: index service architecture In-Reply-To: Mail from 'clw@merit.edu' dated: Tue, 1 Dec 92 10:17:47 EST Cc: ietf-wnils@ucdavis.ucdavis.edu > Thomas: > Hi! Here's the paper referenced in GDS, 1992. > > I am eager to hear any comments you may have on the whois++ system. > Regards, > > Chris Chris, thank you for sending peterd's proposal. Now I know what the index service paper is related to. Meanwhile I was able to trace back the discussion on this list for a couple of days and saw a couple of comments. I have nothing to add to that "Architecture of the WHOIS++ Service" paper. As this is a general approach for all kinds of queries (that is: querying for all kind of data), I'd love to see it applied to a couple of templates. What templates have already been defined and how will addition of templates and/or attributes be handled in future? Sooner or later one might have to come to a similiar OID concept as for OSI objects. Regarding the index paper, I regretfully have to admit that I'm not very familiar with the theory of database systems. We certainly agree in the statement that centralized databases can no longer cope with the huge amount and complexity of data. With a little bit of X.500 background, I'm naturally not supposed to take a neutral position here :-) "3.1 The search problem Current implementations of this hierarchical architecture [obviously related to: hierarchy of directory information collection agents - Thomas] require that a search query issued at a certain location in the directory agent tree be replicated to _all_ subtrees, because there is no way to tell which subtrees might contain the desired information. It is obvious that this has rather extreme scaling problems, and in fact the search facility has been turned off in the X.500 architecture because of this problem. ..." 1. Sending queries to all subtrees (i.e. subordinated agents) does IMHO not produce a scaling problem by itself. There is a very definite limit to such a search (after having reached all - i.e. a finite number of - leafs). With appropiate underlying technique one can carry out several searches at the same time. 2. I haven't heard of 'search facility having been turned off in X.500'. It is true that you can't do a subtree search for person from a global root position by issuing one command. But, you can do it from any other level and (with a bit more cleverness) even from the root. There are programs searching _the whole Directory_ for certain objects (without knowing the position of these objects!) in field operation. I'm not going to say X.500 (in its current form) is _the_ one and only distributed database. However, I would like to encourage rather improvements on one technology instead of setting up a bunch of special purpose database systems because one can't agree on a common. I am convinced a _unique global information system_, holding data about persons, services, documents, xyz-objects and drawing interconnections between related objects is a worthy goal. The architecture you propose tries to model an (artificially?) flat name space into a hierarchy of servers, but at the same time to hide this hierarchy from users. I am wondering if one would miss hierarchy for some queries (e.g. searching for a book only in California). If I got the idea of centroids correctly, top-level index servers get flooded by centroids (how else do they know which subtree holds a match). I'm afraid this may lead to a scaling problem. However, it is definitely desireable to speed up searches by indexing all data. Just that I haven't seen a good index mechanism yet ;-) Please excuse my ignorance, but isn't it possible to attach index policy to X.500 (provided we know _how_ to index) and then using _an already running service_ ? Now I'm ready to be shot :-) Thomas From ietf-wnils-request@ucdavis.ucdavis.edu Wed Dec 2 15:21:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13383; Wed, 2 Dec 92 15:05:36 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20294; Wed, 2 Dec 92 13:09:45 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08966; Wed, 2 Dec 92 13:03:08 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08561; Wed, 2 Dec 92 12:50:53 -0800 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA01341; Wed, 2 Dec 92 15:46:35 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA01309; Wed, 2 Dec 92 15:45:20 EST Date: Wed, 2 Dec 92 15:45:20 EST From: clw@merit.edu Message-Id: <9212022045.AA01309@home.merit.edu> To: clw@merit.edu, thomas@aic.co.jp Subject: Re: index service architecture Cc: ietf-wnils@ucdavis.ucdavis.edu Thomas: O.K., my opening salvo :^) > >Current implementations of this hierarchical architecture [obviously related >to: hierarchy of directory information collection agents - Thomas] require >that a search query issued at a certain location in the directory agent tree >be replicated to _all_ subtrees, because there is no way to tell which >subtrees might contain the desired information. It is obvious that this has >rather extreme scaling problems, and in fact the search facility has been >turned off in the X.500 architecture because of this problem. ..." > >1. Sending queries to all subtrees (i.e. subordinated agents) does IMHO not > produce a scaling problem by itself. There is a very definite limit to > such a search (after having reached all - i.e. a finite number of - > leafs). > With appropiate underlying technique one can carry out several searches > at the same time. Well, one of the major problems with the X.500 architecture is the fact that the *only* way to guide a search is through the name space. I struggled with this problem 18 months ago when I tried to start doing Yellow Pages in the Directory. I ended up having to munge the namespace with things like @o=Internet@ou=K-12 Educators. While this is certainly implementable for a small number of special purpose directories, it is frankly unmaintainable for any size that would allow us to have the kind of directory service that we all want. Also, this necessitates that any search for attributes not contained in the name space (for example, for all people who are High Energy Physicists) *must* be global, unless it has been encoded in the name space. Even granting that a global search terminates *sometime*, my prediction is that the vast majority of searches will require global propogation. Will the X.500 directory be able to withstand the load??? This argument is also applicable to any given subtree, for example: looking for every HEP in the U.S.... Analogously, we could do networking today by simply propogating every packet on the net to every host on the net. A given packet will certainly get where it needs to go sometime... The question here is one of scale and response time. What will the response time be for a global query? What about charging mechanisms? If I have to issue and be charged for a global query everytime I need to find something, I won't use the service. Period. Also, how does the NADF naming scheme fit into this system? People have been arguing for the past 8 months (at least) about 'listing vs. registration', For example, a company's ability to be found depends critically on its location in the namespace. It seems to me that one needs a directory to use the Directory! > >2. I haven't heard of 'search facility having been turned off in X.500'. It is > true that you can't do a subtree search for person from a global root > position by issuing one command. But, you can do it from any other level > and (with a bit more cleverness) even from the root. There are programs > searching _the whole Directory_ for certain objects (without knowing > the position of these objects!) in field operation. Sorry, I should have clarified this. I should add the words 'at high levels in the tree'. Even with these programs that search the whole Directory, what sort of load does this impose?? How widely spread is the expertise for doing these types of searches? >I'm not going to say X.500 (in its current form) is _the_ one and only >distributed database. However, I would like to encourage rather >improvements on one technology instead of setting up a bunch of special >purpose database systems because one can't agree on a common. I am >convinced a _unique global information system_, holding data about >persons, services, documents, xyz-objects and drawing interconnections >between related objects is a worthy goal. Let me start off by saying that I too have a vision of a global information service, and I think that it is a worthy goal. But I think X.500 is not a technology which can provide this service. There are _so_ many things lacking, not the least of which is widespread public confidence that X.500 will work, that I think it is time to start exploring other alternatives. We could certainly build a supercomputer using extremely clever arrangements of vacuum tubes. But is it worth it? How will X.500 win back the large group of people who have tried it and given up on it? When I spoke at Interop, in the Global Information Services session, we had a crowd of at least 500 people. A large percentage of them raised their hands when I asked how many people had tried X.500 and given up on it. What about the '92 standard? My impression is that it contains some things that even the ISODE consortium think is unimplementable (access lists???). Also, the last I heard was that the CCITT was going off the 4 year release program for new versions of the standard... if this is true, I don't think that many of these problems will *ever* get fixed in the standard. The interest we have had in the WHOIS++ services has been phenomenal. My personal opinion is that WHOIS++ will take off the way Gopher has, because we've made it extremely cheap to buy into. But Tim Howes and I are already co-chairing a group to start integrating the two directory services together. > >The architecture you propose tries to model an (artificially?) flat name >space into a hierarchy of servers, but at the same time to hide this >hierarchy from users. I am wondering if one would miss hierarchy for some >queries (e.g. searching for a book only in California). One big advantage of the Index Service is that one can build any hierarchy one likes on top of the low-level servers by fixing which index servers ask which other ones for which information. That was something that Steve Hardcastle-Kille picked up on right away. Multiple hierarchies can be built up on the same data, and once they have been built, they are self-maintaining. Additionally, we have the mechanisms here so that part of the directory service can contain indexing information on other parts of the directory. This indexing information can (for example) index information contained in abstracts associated with the low level servers, so one could find the index server for California. > >If I got the idea of centroids correctly, top-level index servers get >flooded by centroids (how else do they know which subtree holds a match). >I'm afraid this may lead to a scaling problem. However, it is definitely >desireable to speed up searches by indexing all data. Just that I haven't >seen a good index mechanism yet ;-) Please excuse my ignorance, but isn't >it possible to attach index policy to X.500 (provided we know _how_ to >index) and then using _an already running service_ ? I'm sure it's quite possible. Who's going to do it? By allowing the data to index itself, as we do with the whois++ index mechanism, (and also as WAIS does), we don't need to wait for the 'perfect indexing scheme'. > >Now I'm ready to be shot :-) > >Thomas > I sincerely hope that I didn't give offence with any of my remarks. I think that these sorts of discussions are exactly what is needed to get to where we'd all like to be. Chris From ietf-wnils-request@ucdavis.ucdavis.edu Thu Dec 3 18:44:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12394; Thu, 3 Dec 92 18:38:39 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13247; Thu, 3 Dec 92 17:49:40 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10354; Thu, 3 Dec 92 17:41:23 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from bullwinkle.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09739; Thu, 3 Dec 92 17:24:16 -0800 Received: from parapente.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.03) id AA20842; Thu, 3 Dec 92 17:23:17 PST From: ccjoan@bullwinkle.ucdavis.edu Date: Thu, 3 Dec 92 17:23:17 PST Message-Id: <9212040123.AA20842@bullwinkle.ucdavis.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: WNILS Archives Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano I updated the archives on silo.ucdavis.edu. Copies of all of the WNILS documents can be found in pub/ietf/wnils. These same files are available through gopher to gopher.ucdavis.edu. Also, FYI, you'll see I've created part of an IETF gopher that contains information I'm interested in and maybe it will be of interest to you as well. 1. Charters/ 2. Future.Meetings. 3. NNSC.Server.Help. 4. On.Line.Info.Access. 5. Registration.Form. 6. URI/ 7. WNILS/ Peter and Allan, Where would I find the URI papers? IAFA? Bunyip.com wouldn't let me in. Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Thu Dec 3 22:20:55 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19660; Thu, 3 Dec 92 22:10:33 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15012; Thu, 3 Dec 92 21:49:28 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18664; Thu, 3 Dec 92 21:41:38 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from [150.80.254.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18369; Thu, 3 Dec 92 21:32:36 -0800 Received: from cosmos.aic.co.jp ([150.80.4.1]) by aic-wide.aic.co.jp (4.1/2.7W) id AA11414; Fri, 4 Dec 92 14:31:31 JST Received: from beat.aic.co.jp by cosmos.aic.co.jp (4.0/6.4J.6-92/2) id AA14839; Fri, 4 Dec 92 14:31:19 JST Received: by beat.aic.co.jp (4.1/6.4J.6-91/1/29) id AA00772; Fri, 4 Dec 92 14:31:29 JST Date: Fri, 4 Dec 92 14:31:29 JST From: Thomas Johannsen Return-Path: Message-Id: <9212040531.AA00772@beat.aic.co.jp> To: clw@merit.edu Subject: Re: index service architecture In-Reply-To: Mail from 'clw@merit.edu' dated: Wed, 2 Dec 92 15:45:20 EST Cc: ietf-wnils@ucdavis.ucdavis.edu Chris, I had to be away from my machine yesterday nearly all day :-( and can response only now. > Also, this necessitates that any search for attributes not contained in the > name space (for example, for all people who are High Energy Physicists) > *must* be global, unless it has been encoded in the name space. Even granting > that a global search terminates *sometime*, my prediction is that the > vast majority of searches will require global propogation. Will the X.500 > directory be able to withstand the load??? I don't know ;-) So far, most DSAs are not very busy. > time. What will the response time be for a global query? What about charging > mechanisms? If I have to issue and be charged for a global query everytime > I need to find something, I won't use the service. Period. You're absolutely right that many applications don't think of charging nowadays. When _real_ charging starts, we will all have to buy more disks for local chache copy of the Net :-) Saying this, I want to ask whether whois++ has any concept of replication/caching now? > Also, how does the NADF naming scheme fit into this system? People have > been arguing for the past 8 months (at least) about 'listing vs. registration', > For example, a company's ability to be found depends critically on its > location in the namespace. The ability to be listed. You can find it everywhere (by searching). > Let me start off by saying that I too have a vision of a global information > service, and I think that it is a worthy goal. Fine. > But I think X.500 is not a > technology which can provide this service. There are _so_ many things > lacking, not the least of which is widespread public confidence that X.500 > will work, that I think it is time to start exploring other alternatives. > [...] > How will X.500 win back the large group of people who have tried it and given > up on it? I'd like to discuss technical reasons instead of polls. > The interest we have had in the WHOIS++ services has been phenomenal. > My personal opinion is that WHOIS++ will take off the way Gopher has, because > we've made it extremely cheap to buy into. But Tim Howes and I are already > co-chairing a group to start integrating the two directory services together. It is amazing how gopher spreads. However, I have the bad feeling that the data organization is more a piecemeal work of clever engineering than a clear concept. Will that scale? > One big advantage of the Index Service is that one can build any hierarchy > one likes on top of the low-level servers by fixing which index servers > ask which other ones for which information. [..] Multiple hierarchies > can be built up on the same data, and once they have been built, they are > self-maintaining. I admit you've got a good point here. Question: Who is allowed to set up special index servers, where are they held (i.e. can/will they be used by all whois++ clients) and registered? > I sincerely hope that I didn't give offence with any of my remarks. Not at all. > I think > that these sorts of discussions are exactly what is needed to get to > where we'd all like to be. I agree. Thomas From ietf-wnils-request@ucdavis.ucdavis.edu Fri Dec 4 10:33:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16558; Fri, 4 Dec 92 10:25:21 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18761; Fri, 4 Dec 92 09:16:51 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13675; Fri, 4 Dec 92 09:05:56 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from ATHENA-AS-WELL.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13390; Fri, 4 Dec 92 08:59:24 -0800 Received: from HODGE.MIT.EDU by Athena.MIT.EDU with SMTP id AA26902; Fri, 4 Dec 92 11:58:29 EST From: mhpower@Athena.MIT.EDU Received: by hodge (5.57/4.7) id AA01043; Fri, 4 Dec 92 11:58:25 -0500 Message-Id: <9212041658.AA01043@hodge> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: index service architecture In-Reply-To: <9212040531.AA00772@beat.aic.co.jp> Date: Fri, 04 Dec 92 11:58:21 EST > ... Question: Who is allowed to set up >special index servers, where are they held (i.e. can/will they be used by >all whois++ clients) and registered? I'd expect that all index servers will end up at companies that can accept a contractual specification on handling clients' index data. Maybe everyone will nominally be "allowed to" set up servers at first. Ultimately, though, it seems that the constraints on index-service providers will be driven bottom-up by requirements of larger companies wishing to join the architecture. In this view, a company can't prescribe the authorized uses of its index data only by its immediate poller. It has to ensure that this poller's pollers won't include, say, index-server.foo.edu, which happens to be maintained by some student-hacker group. And so on, up the tree. Contractual data-handling requirements at just a handful of leaf nodes could easily propagate to nearly all the others. Before this architecture becomes pervasive, I suspect a lot of money will change hands, and often in the directory of lawyers rather than our friends the "Computer Operatives". Matt From ietf-wnils-request@ucdavis.ucdavis.edu Fri Dec 4 11:45:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19049; Fri, 4 Dec 92 11:34:45 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20106; Fri, 4 Dec 92 10:51:16 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17354; Fri, 4 Dec 92 10:46:16 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17085; Fri, 4 Dec 92 10:39:50 -0800 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA24199; Fri, 4 Dec 92 13:38:54 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA26100; Fri, 4 Dec 92 13:38:54 EST Date: Fri, 4 Dec 92 13:38:54 EST From: clw@merit.edu Message-Id: <9212041838.AA26100@home.merit.edu> To: ietf-wnils@ucdavis.ucdavis.edu, mhpower@Athena.MIT.EDU Subject: Re: index service architecture Matt: I think that there's a slightly different possibility... Once some security is introduced into the protocol at the bottom level servers, the indexing information may propogate freely, with only the access to the final data locked off. In this view, one would want to insure that people knew that you had some data, but then charge them for access to the actual data itself. Chris From ietf-wnils-request@ucdavis.ucdavis.edu Sun Dec 6 01:00:52 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17899; Sun, 6 Dec 92 00:54:11 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00784; Sun, 6 Dec 92 00:19:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16262; Sun, 6 Dec 92 00:10:16 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from taunivm.tau.ac.il by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15923; Sun, 6 Dec 92 00:00:13 -0800 Message-Id: <9212060800.AA15923@ucdavis.ucdavis.edu> Received: from VM.BIU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R1) with BSMTP id 2372; Sun, 06 Dec 92 09:57:29 IST X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender. Received: from VM.BIU.AC.IL (HANK) by VM.BIU.AC.IL (Mailer R2.07) with BSMTP id 5686; Sun, 06 Dec 92 09:50:15 IST Date: Sun, 06 Dec 92 09:47:57 IST From: Hank Nussbacher Subject: Phonetic search capability for whois++ To: ietf-wnils@ucdavis.ucdavis.edu I scanned the draft and was suprised that it does not include a phonetic search capability (I only joined this list yesterday so if this has already been discussed just ignore it). Is there any plans to add such a capability? Thanks, Hank From ietf-wnils-request@ucdavis.ucdavis.edu Sun Dec 6 08:30:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02587; Sun, 6 Dec 92 08:29:33 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01730; Sun, 6 Dec 92 08:09:41 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01617; Sun, 6 Dec 92 08:00:16 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from SunSite.unc.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01304; Sun, 6 Dec 92 07:50:25 -0800 Received: from localhost.oit.unc.edu by SunSite.unc.edu (4.1/TAS/11-16-88) id AA12757; Sun, 6 Dec 92 10:48:22 EST Message-Id: <9212061548.AA12757@SunSite.unc.edu> To: Hank Nussbacher Cc: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Phonetic search capability for whois++ In-Reply-To: Your message of "Sun, 06 Dec 92 09:47:57 +0700." <9212060800.AA15923@ucdavis.ucdavis.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 06 Dec 92 10:48:22 -0500 From: Simon Spero Do you mean soundex style fuzzy matching? That's not only in the spec, it's in the prototype! s. From ietf-wnils-request@ucdavis.ucdavis.edu Mon Dec 7 12:29:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19269; Mon, 7 Dec 92 12:18:51 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09733; Mon, 7 Dec 92 11:30:26 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17897; Mon, 7 Dec 92 11:26:10 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17478; Mon, 7 Dec 92 11:10:56 -0800 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22786 (mail destined for ietf-wnils@ucdavis.edu) on Mon, 7 Dec 92 14:09:47 -0500 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA13703; Mon, 7 Dec 92 14:00:27 EST Message-Id: <9212071900.AA13703@expresso.cc.mcgill.ca> In-Reply-To: Hank Nussbacher's message as of Dec 6, 9:47 From: peterd@bunyip.com (Peter Deutsch) Date: Mon, 7 Dec 92 19:00:25 GMT-0:02 In-Reply-To: Hank Nussbacher's message as of Dec 6, 9:47 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: Hank Nussbacher , ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Phonetic search capability for whois++ [ you wrote: ] > > I scanned the draft and was suprised that it does not include a phonetic > search capability (I only joined this list yesterday so if this has already > been discussed just ignore it). Is there any plans to add such a capability? As usual, this is an area that we have tried to anticipate, without trying to nail down all details before we could have a suitable discussion through the working group. This particular topic will be covered by the "search term constraints" section, which still needs considerable fleshing out. As Simon has already posted, the pilot being worked on by our group already includes a "fuzzy" search option, and we do intend to make this one of the recommended search types. I also suspect that a list of "required" constraints is probably called for, along with a list of "optional" or "experimental" ones, although this has not yet received a lot of attention. FYI, here's the current wording on the "Search term Constraints" section, which is the section I see being beefed up to include such a list... - peterd ---------------------------------------------------------------------- Search Term Constraints ------------------------- Specific search constraints are intended to be hints or recommendations to the search engine on how to perform that part of the search. Thus, a user might specify a search constraint as "exact match", or "substring match". The CONSTRAINTS system command is used to list the search constraints supported by an individual server. [* Note: The best way to handle this is probably with either a specified list of keywords or by referring to an IANA registry of supported search types... *] If a server cannot satisfy the specified constraint there is a mechanism for informating the user in the reply, using system messages. In such cases, the search is still performed, and the server ignores unsupported constraints. -- From ietf-wnils-request@ucdavis.ucdavis.edu Mon Dec 7 14:47:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22949; Mon, 7 Dec 92 14:36:20 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11591; Mon, 7 Dec 92 14:03:41 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21877; Mon, 7 Dec 92 13:56:46 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from kona.CC.McGill.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21426; Mon, 7 Dec 92 13:40:05 -0800 Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24950 (mail destined for ietf-wnils-request@ucdavis.edu) on Mon, 7 Dec 92 16:38:23 -0500 Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA14034; Mon, 7 Dec 92 16:29:03 EST Message-Id: <9212072129.AA14034@expresso.cc.mcgill.ca> In-Reply-To: Mitra's message as of Nov 26, 22:40 From: peterd@bunyip.com (Peter Deutsch) Date: Mon, 7 Dec 92 21:29:01 GMT-0:02 In-Reply-To: Mitra's message as of Nov 26, 22:40 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: Mitra , Subject: Re: Peter's proposal I'm finally finding a few minutes to respond to the various comments that have come in on this list concerning the WHOIS++ drafts. I'm taking these in no particular order (or rather, the order in which I can find them in my overflowing mailbox... :-) Note that I've not consulted with the other authors on this, so my replies currently represent only my interpretation of things. Consensus to follow (I hope...) - peterd ---------------------------------------------------------------------- [ Mitra wrote: ] > > > Thanks for the copy of the proposal Peter, here are some comments on it . > Sorry if I'm revisiting some of the discussion. > > Abridged Mode: Why does this HAVE TO return the information that matched t > the query, I believe that the fields returned should be a function of the > template, or be specifiable by the user. For example if I'm searching > for members of XYZ organization, I probably dont want that listed, but > do want the names of the people. The thought here was to allow the client program to give some context on the hit, since in many cases it will be a false hit. Seeing the appropriate line will allow (hopefully) rapid filtering. If this is not thought needed, alternatives can certainly be proposed, but this was wanted for a specific feature, so I'd propose extending the formats to others, not replacing it. > Selecting which mode to return: Allowing the user to specify this may not > be the right response, in Z39.50 you can specify upper and lower bounds > so for example the user could specify: 1-3 FULL, 4-22 ABRIDGED >22 SUMMARY > I'm not sure how to do this in the protocol, maybe a pair of numbers 3;22 The reason I want it under human control is because in our experience with archie, people want more control over what the silly machine will be telling them than is usually given them. In the longer run I expect this will translate to greater flexibility in the clients but in the shorter term it means people can set up the output the way they want. We can certainly extend the existing CONSTRAINT syntax to allow something like you're suggesting, although I'm not sure how far we should take this into the realms of complexity. I'll try to put something into the next draft and people can shoot at it. > Format of responses: Since this format is really close to the tag ":" value > format beloved of RGC's 822, 1036 etc why has the choice been taken to define > a new format. It would be more consistent to have the format be > each tag at the start of a line (no leading space) and use leading white-space > as the indication of a continution line rather than the "+" you suggest. Hmmm, I'm going to take a risk and answer this without going back to my notes, bear with me if I say something more stupid than usual. Keep in mind that the design of this system is driven by a (hopefully) clearly defined model in which all database entries are typed templates or records of a specified format. Also, remember that the design was intended to be backwards compatible with the existing WHOIS service. Now, I've read the MIME spec, and think it an excellent piece of work and I'm passingly familiar with RFC822, but these docs do not share our underlying assumptions about how the information being served is to be represented and this is why we elected to develop a new query protocol and output format from scratch. Where possible, we will pick up existing work, but I personally didn't want us to try to crowbar in existing pieces where it didn't quite fit just to ensure backwards compatibility with the "wrong" documents. Having siad that, the output format specified has the property that existing WHOIS clients are conformant. Hopefully, we preserve "readibility" for those using telnet or whois as their access method while allowing machine parsing of system and database info. I think we succeeded in this (although of course that's open to debate). > The SUMMARY record isnt adequately specified for reading by machine, e.g. a > smart client, you say "Each succeeding line shall INCLUDE the name of the > next template type" If you mean the line shall BE the name of the next template > type then fine. I'll work on this. There are a number of places like this and they'll hopefully be cleaned up in the next go-round (Real Soon Now). > I think the SUMMARY would be better defined to include the number of hits > from each template. I thought it did. The wording is: # SUMMARY Returns only a brief summary of number of matches # and the corresponding template types which # matched the specified query. This was supposed to be read as "template type: matches". Of course, this may not agree with other parts, but I'll try to make sure it's consistent when I do the next editing pass. > Hope this is usefull. Definitely. Thanks. - peterd -- From ietf-wnils-request@ucdavis.ucdavis.edu Tue Dec 8 09:35:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17644; Tue, 8 Dec 92 09:22:49 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17646; Tue, 8 Dec 92 06:49:57 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14102; Tue, 8 Dec 92 06:41:29 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from THUD.CS.UTK.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13858; Tue, 8 Dec 92 06:30:12 -0800 Received: from LOCALHOST.cs.utk.edu by thud.cs.utk.edu with SMTP (5.61++/2.7c-UTK) id AA16852; Tue, 8 Dec 92 09:29:05 -0500 Message-Id: <9212081429.AA16852@thud.cs.utk.edu> To: ietf-wnils@ucdavis.ucdavis.edu Cc: wade@cs.utk.edu, lewis@cs.utk.edu Subject: whois++ sample server Date: Tue, 08 Dec 92 09:29:04 EST From: Reed Wade Hi, We're looking to reimplement an existing directory service and would like to get hold of the existing prototype whois++ code. It is for the xnetib whois service which gets a lot of use and so may be a useful test of whois++. We don't mind dealing with prerelease code. thanks, Reed Wade wade@cs.utk.edu From ietf-wnils-request@ucdavis.ucdavis.edu Mon Jan 11 10:26:32 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19974; Mon, 11 Jan 93 10:15:13 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08192; Mon, 11 Jan 93 08:50:13 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15637; Mon, 11 Jan 93 08:44:05 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15094; Mon, 11 Jan 93 08:32:23 -0800 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA06321; Mon, 11 Jan 93 11:31:20 -0500 Date: Mon, 11 Jan 93 11:31:20 -0500 From: "Chris Weider" Message-Id: <9301111631.AA06321@merit.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Forwarded message on Whois++ > From huitema@mitsou.inria.fr Tue Jan 5 02:52:03 1993 > Received: from mitsou.inria.fr by merit.edu (5.65/1123-1.0) > > id AA22397; Tue, 5 Jan 93 02:52:01 -0500 > Received: by mitsou.inria.fr > > (5.65c/IDA-1.2.8) id AA08164; Mon, 4 Jan 1993 17:38:58 +0100 > Message-Id: <199301041638.AA08164@mitsou.inria.fr> > To: clw@merit.edu > Subject: Re: root knowledge > In-Reply-To: Your message of "Thu, 17 Dec 92 17:19:46 EST." > <9212172219.AA23040@home.merit.edu> > Date: Mon, 04 Jan 93 15:19:23 -0500 > From: Christian Huitema > Status: R > Chris, > Thank you for having sent me the set of documents describing > "WHOIS++". It certainly look like a useful service, and is certainly > quite promising. In fact, if a network of whois++ servers could > complement the DNS, we would not need to deploy X.500. > Well, after the good words, I believe you certainly can use a > couple of "constructive" remarks. I guess you would not have > asked my advice otherwise... The remarks are in fact on three > points: the level of aggregation that can be introduced in the > "centroid" mechanism, the relation between the DNS and the > "record" identifications, and the "formatted text" nature of the > protocol. > I see the "centroid" mechanism as the basis of your proposal, and > I regret that the only arguments you present here are based on > "hand waving", e.g. "it is entirely possible to build a unified > directory which uses many types of forward knowledge" and on a > "proof by a small scale experiment". I understand your forward > knowledge as a generalisation of a "key word" approach: you > aggregate all keywords that can be associated with various > attribute types in a given server, and, if I understoud correctly, > flood the network with these informations. IMHO, I dont believe > this will scale. At a very minimum, you would need an estimation > of the expected size of these centroids. In fact, a scalable solution > probably requires a possibility to "forget the details", i.e. pass only > the "most helpful facts". X.500 aggregates pretty harshly, as it > summarize a whole tree by a set of name parts; one can certainly > do better than that... but please tell us more about the details! > >From a "marketing" point of view, the whois++ service cannot be > developped "ex-nihilo". I dont find the request that IANA gives > unique ids to all servers very realistic. Why then don't you just > use DNS names? Similarly, records could be identified as a > combination of a domain name -- the area where the record is > stored -- and a "unique id". Something like: > > "1234@whois-srv.foo.com" > A side effect would be a possibility to insert a record look-up > mechanism, which would be useful for server that simply index > data coming from various source. And that would help the > positioning of WHOIS++ as another Internet service, > complementary to the DNS. > When reading the first draft of the response formats, I observed > that you went to a great length of trouble to maintain > compatibility with punch card readers. Indeed, there is some > rationale beyond sending 80 chars per line of ascii text -- it was > an implict requirement of electronic mail for several years. But, > well, we changed that. I would suggest that you seriously study > the technologies developped around MIME, e.g. quoted text, > tagged documents, alphabet designation, etc. That, again, would > help positioning WHOIS++ as a good Internet citizen. > I hope these comments will help the WNILS group. In any case, I > will pass the work to the nearby X.500 team; they may be > interested in deriving a WHOIS++ server from their X.500 servers > -- the data base technology and data collection mechanism should > be reusable. > Christian Huitema> > > PS. > Please forward my comments to the WNILS mailing list. :v From ietf-wnils-request@ucdavis.ucdavis.edu Mon Feb 8 20:43:57 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06189; Mon, 8 Feb 93 20:36:51 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17909; Mon, 8 Feb 93 19:59:47 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04518; Mon, 8 Feb 93 19:51:34 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from SunSite.unc.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04181; Mon, 8 Feb 93 19:44:01 -0800 Received: by SunSite.unc.edu (4.1/TAS/11-16-88) id AA11705; Mon, 8 Feb 93 22:42:32 EST Date: Mon, 8 Feb 93 22:42:32 EST From: Simon Spero Message-Id: <9302090342.AA11705@SunSite.unc.edu> To: ietf-wnils@ucdavis.ucdavis.edu Subject: how X.500 really works No comment. Simon ------ Tar Heel Information Services - Nothing but Net. ------ Newsgroups: news.misc,alt.internet.services From: kjenks@gothamcity.jsc.nasa.gov Subject: Re: weird idea: e-mail "phone book" Message-ID: <1993Feb9.003428.8661@aio.jsc.nasa.gov> References: <#743!bp@rpi.edu> Date: Tue, 9 Feb 1993 00:34:28 GMT Stephen Andrew Weinstein (weinss@sage4c.its.rpi.edu) wrote: : Let's set up on one machine, somewhere on the internet, accessible by telnet, : an alphabetical listing (by name) of all e-mail addresses, worldwide (ideally : Compuserve and bitnet as well). Alternatively, we could have one file for : each unique last name and make it available by anonymous FTP. [...] You've just outlined the "X.500 Directory Services" project of the CCITT, an international communications standards organization. Good idea. Maybe you can help the CCITT -- they're bogged down in the implementation right now. If you want more information, I can get you in touch with the right people. You're absolutely right. Keeping the directory current and accurate will be a nightmare. -- Ken Jenks, NASA/JSC/GM2, Space Shuttle Program Office kjenks@gothamcity.jsc.nasa.gov (713) 483-4368 "We at NASA develop cutting-edge technology for our aeronautics and space programs. We view technology transfer as a way of life. It's one of our top priorities." -- Daniel S. Goldin, NASA Administrator From ietf-wnils-request@ucdavis.ucdavis.edu Tue Feb 9 16:00:56 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18982; Tue, 9 Feb 93 15:41:27 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27962; Tue, 9 Feb 93 13:54:06 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14751; Tue, 9 Feb 93 13:38:31 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from @.dfci.harvard.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13611; Tue, 9 Feb 93 13:04:03 -0800 Received: by farber.harvard.edu (5.65/1.34) id AA09545; Tue, 9 Feb 93 16:01:09 -0500 From: ellozy@farber.harvard.edu (Mohamed Ellozy) Message-Id: <9302092101.AA09545@farber.harvard.edu> Subject: History of directory services on Internet To: tcp-ip@nic.ddn.mil Date: Tue, 9 Feb 93 16:01:07 EST Cc: osi-ds@cs.ucl.ac.uk, info-ph@ux1.cso.uiuc.edu, ietf-wnils@ucdavis.ucdavis.edu X-Organization: Dana-Farber Cancer Institute X-Phone: 617-632-3034, 617-632-3425 X-Mailer: ELM [version 2.3 PL11] I will be giving a talk on current directory services on the Internet (whois, CSO nameserver, quipu, and the use of gopher as a common directory user agent for multiple protocols) and would like to give as much historical context as possible. I would appreciate both pointers to documents and personal reminiscences. Many thanks. Mohamed PS: Pointers to the future (e. g. whois++) would also be appreciated. From ietf-wnils-request@ucdavis.ucdavis.edu Thu Mar 4 20:28:04 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15213; Thu, 4 Mar 93 20:18:29 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07450; Thu, 4 Mar 93 19:51:27 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14104; Thu, 4 Mar 93 19:48:07 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from mocha.bunyip.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13768; Thu, 4 Mar 93 19:38:50 -0800 Received: from [192.197.208.2] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04518 (mail destined for ietf-wnils@ucdavis.edu) on Thu, 4 Mar 93 22:37:15 -0500 Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0) id AA07573; Thu, 4 Mar 93 22:36:02 -0500 Message-Id: <9303050336.AA07573@expresso.bunyip.com> From: peterd@expresso.bunyip.com (/usr/spool/mail/peterd) Date: Thu, 4 Mar 1993 22:36:01 -0500 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: ietf-wnils@ucdavis.ucdavis.edu Subject: Call for comments and some thoughts... g'day all, Well, after _considerable_ delay I'm now actively working on the next draft of the WHOIS++ document and I hope to have another revision out in the next couple of days. I'll follow this up by putting some more time into the GDS server code, still stuck in alpha release waiting for me to fold in the suggestions from the last IETF (obviously I'd like a stable document before I go back to coding). If all goes well we should have a bare-bones release by some time next week, barring screams and cries from the crowd about what I write here. But first this note to try and get people focused a bit on some of the open problems I perceive with what we have so far in the WHOIS++ project. These include: - questions about how to do multilingual and multiple character set support. - how to handle security - a proposed extension to the original "centroids" idea to make it more flexible and useful for building generalized indexers. - Codifying error messages so clients can handle servers that "die gracefully". I suspect that its time we looked at some of the possible error conditions and start specifying appropriate return codes for messages, although I I wont get into too much detail on this topic in this note. I'll try to focus primarily on multiple language support and a proposed authentication mechanism. I'll also be folding in those suggestions we received at the last IETF into the doc and I'll try to address these in another message before I post the final version of the document since I want people to discuss my proposed solutions and let me know if I'm going off the rails. These proposals were summarized in the wnils minutes and I'll return to them in another posting, since this one will be long enough as it is and I do want to get home tonight. I was lucky enough to spend a week with Chris Weider in February (we both attended the NORDUnet conference in Helsinki and had quite a bit of time together looking for Chris' lost luggage, etc... :-) and he and I swapped ideas around for WHOIS++ quite a bit. Chris hasn't seen this posting yet, so I can't claim he's endorsing everything out of hand. Still, I hope I'm faithful to our original ideas. Obviously, comments, feedback etc most welcome. Multiple Language Support -------------------------- First, multiple character set support. This is obviously a hot topic in the Nordic countries, and Europe in general, and from what I heard in Helsinki there seems to be a general consensus that the way MIME has addressed the problem (in a word, allowing the sender to specify the character set to use) seems like a good one. My suggestion is to couple this approach with the simple WHOIS++ constraints mechanism to allow users to specify the character set desired (eg. CHARSET=US-ASCII. I believe doing this gives us all we need for a first cut (and their approach to CONTENT-TYPE can be purloined as well, but more on that when we address graphics in sound...) At the same time, as we've already found with our work on archie, it would be nice if we could have some mechanism for specifying language for returned messages. And note that this is _not_ the same as specifying character sets, but refers to the language of communication (and since the term "character set comes up a lot in this posting I'll use "charset" from now on for brevity). Bake to the point. What we'd like to do is provide some means to allow a site to customize responses by providing the ability to serve response messages in multiple languages. The goal is to provide a mechanism to allow bilingual, or even multilingual servers to be set up, with the user selecting which language response messages will come back in. Charset selection then comes into play for rendering these messages in a format that can be displayed. To address these concerns I propose adding additional global constraints to allow the user to specify both the charset and the language to be used, as well as additional commands to allow the client to query and obtain info about languages and charsets (and eventually content-types) supported. If a specified selection is not available, an appropriate error message would be returned, indicating which requested constraint was not available. There is then the follow-on question as to whether the search should go ahead and be returned if either a charset or language is not available, using a default language or charset. Personally, I think I'd vote to keep it simple and abandon a search on error in all cases. Client cycles are cheap and they can always be used to regenerate and automatically retry a failed query using a second choice. I think it more important to minimize the time spent in transactions to help keep the load on the servers down. The simple connect and forget model works very well in Gopher and I think should drive us here, too. Another question on language - Is there any value in allowing the user to specify more than one charset to be used for sending queries? This obviously comes into play when trying to do pattern matching if you're storing the information using a different character set. I see a value in allowing a user to send a query string encoded in any desired 8 bit charset, with a suitable constraint term to permit the client identify which one is being used. In this scheme, the site admin is free to store data using any encoding they want since the idea is to translate queries into the host language when they come in. Note that if we do it right, users don't have to know which charset is used to store info internally, only which translation tables are available and which will be the default if none is supplied. Also, it should be obvious that this is an optional feature and not all servers should be required to support all charsets on input and output. All we need ask is that they support the basic queries used to identify which onese_are_ supported, translate correctly the ones claimed to be supported and fail gracefully on those that are not. Sounds easy enough. Bernt Budde (I hope I'm spelling that right) suggested to me in Finland that if the database is stored in a single 8 bit format, all we need is specify a charset mapping from the search string's encoding into the interal format and we can handle any encoding gracefully. He also pointed out that some 7 bit codes other than ASCII use the ASCII-equivalents to "{}/\[]@`" for their own purposes, all of which got me thinking towards the solution that I'm proposing here. Again, as with Chris, he hasn't seen the final result of my musings so I don't claim he supports this idea, but he did help inspire these suggestions by giving me information that helped bring the problem into focus for me and I wanted to give credit where credit is due. (Although I should also point out that Bernt is also the one who suggested that we should require every server to include the "favorite cookie" attribute into every template, so he's not entirely without fault or blemish in my eyes! =8^0 So to summarize, I propose allowing the user to specify (optionally) either or both of _two_ charsets, one for search string encoding (for incoming queries) and one for output encoding (for replies), plus a constraint for selecting an optional language for messages, if available. There will also be a command for informing a client of the selected charsets and languages available in each case, plus the default used at that site (an appropriately graceful failure mechanism will also be specified). Such a query might look like this: : INCHARSET=ISO-LATIN1, OUTCHARSET=US-ASCII The mechanism to inform the client which output languages are available and a constraint specifier to permit selecting other than the default would look something like the following (and obviously the choice of which language to use as the default will be left to the server operator. I think our guiding principal should be to hardwire in the absolutely bare minimum throughout). : CHARSET=US-ASCII, LANGUAGE=francais (in these examples the constraints CHARSET and OUTCHARSET are being used interchangibly for no apparent reason other than it's getting late and I'm tired... :-) Looking this over, it may start to look and sound like a bit of a whistle (or is it a bell? :-) to Americans but I definitely will use this myself here in Quebec and can see it being of use to many other people. I'd really like to provide all of this. Thoughts, anyone? Is there a better way? Am I missing something? Is this dumb?? Security and Authentication ----------------------------- Now, on to security. Basically, I think no one disputes the need for some security and authentication mechanisms to protect all or part of certain databases from prying eyes. On my recent trip to Europe I also had the chance to talk with Mark McCahill of the Gopher team (who was also talking at NORDUnet) about how _they_ were adding security to Gopher+ and I think their approach can be of use to us (note also that they got the spelling wrong - they left off a '+'!! ;-) Their retrofit is to provide a mechanism for indicating to the server that authentication is needed, and which scheme to use, at which point the client and the server enter into a (possibly multiple step) authentication transaction prior to the search "send-receive" transaction which is the norm. This multiple step authentication "pre-transaction" performs whatever steps are needed to authenticate, depending upon the scheme to be used and if the client passes the test the session continues as if it were a simple transaction. I think this should be an adequate procedure for us (again, at least for the first pass). I also again think that the global constraints mechanism makes it trivial for us to do it this way. The idea would be to provide a mechanism for the server to inform the client about the type of authentication schemes are available or required. If a user attempted an ordinary query, it would fail with an appropriate return code and the session ends. If the user wants to authenticate, it would use a constraint term to specify the mechanism being used, plus any other optional or required information specific to the scheme being used. Thus, suppose that the server is to use a simple password authentication scheme to protect the data from prying eyes. Each query would then include a constraint of the form: : AUTHENTICATE=simple-password If this is supported, the server would simple prompt for a password before performing a search. If this were not successful, an error would occur and the server closes the connection with an appropriate error message. Another example might be: : AUTHENTICATE=name-password the server would then prompt for both a name _and_ a password. Again, either failure to request the appropriate authentication, or a failed authentication, would result in an error message and the server would close the connection. I think the scheme can handle most of what we need for a first pass implementation. For example, here's a more complex example which assumes that the server supports an authenticated ticket scheme. The idea here is for the client to indicate (using the AUTHENTICATE constraint) that it will use public key encryption of a random number to authenticate itself. The server sends such a number to the client, the client decodes, processes and reencodes using the server's public key. Once this has been verified by the server the session is okayed. We might further assume (for no good reason other than it illustrates the use of additional constraints) that to do this the client needs to supply a user ID and namespace indicator as additional constraints (and keep in mind that I'm making this particular scheme up as I go along. please cut me some slack... :-) In this case the client must thus supply additional constraints for USER (in this case "foobar") and ID-TYPE ("ISOC-KEY"). The AUTHENTICATE constraint implies that the server will need the additional constraints ( and yes, I'm assuming the client knows, or has been told, the server's public key picky, picky...) And again note that this is only an example of a possible mechanism to illustrate the use of the constraints mechnism, not a real proposal for an authentication scheme. I'm just too lazy tonight to go find the kerberos doc and bone up on a real scheme.... Anyways, the server might receive something like: : USER=foobar, AUTHENTICATE=ticket, ID-TYPE=isoc-key This would be read as user foobar wants to authenticate using the ticket scheme and the key to use would be foobar's ISOC-issued public key (again, excuse the handwaving.) The server would now generate some large random number, encrypt it using, say the RSA algorithm, and send it to the client. The client decrypts it, adds one and reencrypts using the server's known public key, then sends the number back. The server decodes and verifies the number, then the session continues as originally specified since all is right with the universe. The idea here is that the authentication mechanism should be extensible, in the same way the character set proposal is. We want something that will grow and adapt to multiple authentication mechanisms as we think about it a bit while still being easy to build, test and deploy. I think this porposal would fill the bill. Partial Views -------------- Partial views onto a template could also be supported in this scheme (partials are one of the things requested during the meeting at the last IETF). The way I see this working would be to allow server operators to define and name subset views of various templates, which would then be made available for different classes of authenticated users. In effect, views are published on a per name basis. If a user successfully passes authentication for the requested view then the query goes ahead, otherwise, the server once again fails gracefully with an appropriate error. So, again - thoughts? Is this going to be flexible and powerful enough? Of course, I haven't yet looked at how kerberos would fit in here but I don't see that it would break (or is it late and I'm too tired? :-) And of course, WHOIS++ is definitely picking up baggage as it grows, but the suggestions I'm giving here seem like a consistent and simple enough approach in principal that I certainly think it will be fairly easy to implement (he said with a silly grin on his face). If anyone sees serious holes in any of this I'd like to hear about it ASAP. I plan to work on the server over the next few days to splice these features in, so if nobody likes the approach I'd like to know now! In the meantime, I'll try to get a summary of the suggestions from the meeting out in the next few days, as well. My target is to get something back to the rest of the implementation team by the middle of next week, since I'm off to Interop on the 10th. I'm not sure how much more the others want to do before we turn our code loose onto the net, but I hope this posting will stimulate some activity among a few people and get us a step closer to a "real" release. More later. I'm looking forward to some discussion and feedback. - peterd -- ------------------------------------------------------------------------------- One should never ascribe to malice that which can be adequately explained by incompetance... - This may be original, I can't remember ------------------------------------------------------------------------------- --- End of forwarded message from Mail Delivery Subsystem -- ------------------------------------------------------------------------------- One should never ascribe to malice that which can be adequately explained by incompetance... - This may be original, I can't remember ------------------------------------------------------------------------------- From ietf-wnils-request@ucdavis.ucdavis.edu Fri Mar 5 10:23:06 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12248; Fri, 5 Mar 93 10:05:47 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13560; Fri, 5 Mar 93 09:30:36 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11172; Fri, 5 Mar 93 09:28:16 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from blacks.jpl.nasa.gov by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10749; Fri, 5 Mar 93 09:12:24 -0800 Received: from localhost.jpl.nasa.gov by blacks.jpl.nasa.gov (4.1/SMI-4.1) id AA21205; Fri, 5 Mar 93 09:05:10 PST Message-Id: <9303051705.AA21205@blacks.jpl.nasa.gov> To: peterd@expresso.bunyip.com Cc: ietf-wnils@ucdavis.ucdavis.edu, dank@blacks.jpl.nasa.gov Subject: Re: Call for comments and some thoughts... In-Reply-To: Your message of "Thu, 04 Mar 93 22:36:01 EST." <9303050336.AA07573@expresso.bunyip.com> Date: Fri, 05 Mar 93 09:05:10 PST From: dank@blacks.jpl.nasa.gov I wholeheartedly support the idea of being able to select the output language used for messages. Here's why I want it. Imagine a client which is embedded in a email processing package; the client is invoked to resolve an e-mail address of the form hans.blow@somewhere.de; it queries somewhere.de for hans blow's address; somewhere.de replies e-post-adresse: hansblow@x.somewhere.de The client was expecting e-mail-address: hansblow@x.somewhere.de is unable to parse the result, and returns an error message to the user saying "Mail undeliverable". With the proposed multilingual support, the client can specify English as the output language, the server will respond with template field tags in English, and the mail will go through. - Dan Kegel (dank@blacks.jpl.nasa.gov) From ietf-wnils-request@aggie.ucdavis.edu Sun Mar 7 23:34:44 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21133; Sun, 7 Mar 93 23:27:19 -0800 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA06763; Sun, 7 Mar 93 22:50:57 -0800 Sender: ietf-wnils-request@aggie.ucdavis.edu Received: from bullwinkle.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06743; Sun, 7 Mar 93 22:43:07 -0800 Received: from parapente.ucdavis.edu.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.04) id AA19888; Sun, 7 Mar 93 22:41:38 PST From: ccjoan@bullwinkle.ucdavis.edu Date: Sun, 7 Mar 93 22:41:38 PST Message-Id: <9303080641.AA19888@bullwinkle.ucdavis.edu> To: ietf-wnils@aggie.ucdavis.edu, mkheath@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.04) id AA23322; Sat, 6 Mar 93 07:48:05 PST Received: from fox.cs.vt.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17304; Sat, 6 Mar 93 07:42:52 -0800 Received: by fox.cs.vt.edu (5.57/Ultrix3.0-C) id AA21838; Sat, 6 Mar 93 10:37:28 -0500 Date: Sat, 6 Mar 93 10:37:28 -0500 From: fox@fox.cs.vt.edu (Edward A. Fox) Message-Id: <9303061537.AA21838@fox.cs.vt.edu> To: EMR1@vms.cis.pitt.edu Subject: proposal re workshop Cc: irnet@fox.cs.vt.edu Edie, I am writing to you as Conference Chair for ACM SIGIR '93 to request that in your upcoming announcement, you include information about a workshop that we are proposing for July 1, 1993. I am not sure about the room situation, but hope that this draft will allow you to proceed with the printer, and will allow the people who are cc'd on this message to send me comments and suggestions for refinement of the workshop announcement. Dear Message Recipients, For those of you who have heard something about this, please consider it an update, calling for further comment. For those of you who are new, please consider this as a request for advice and assistance. If possible, I hope you will be able to come to the workshop, or send others from your groups. Please let me know ASAP if that might be possible. Most urgent, however, is comments on the announcement of this workshop. Publicity for SIGIR '93 is going to the printer soon, and though we may be able to make minor changes next week, any major changes must be handled very quickly. Later, I hope we can use email and other means to spread word about this workshop, so it will be a great success! Thank you all for your time and assistance! Regards, Ed Fox (Chair of ACM SIGIR) PS Please suggest email addresses of people to add to my mailing list irnet@fox.cs.vt.edu and feel free to send comments there is you prefer. - - ------please review the announcement below and send me comments- - -- INFORMATION RETRIEVAL AND THE NETWORKS (IRNET'93): A RESEARCH WORKSHOP Information access involving networks is one of the most important growth areas in the broad field of information technology. This workshop will bring together researchers and developers to discuss network-based information services in both general and specific terms, drawing upon those attending ACM SIGIR '93 and the communities related to: * Archie * Digital Libraries * Gopher * HyperPage * Knowbots * NNTP/Usenet * Prospero * Veronica * WAIS * WWW (WorldWideWeb) * X-Mosaic * Z39.50 along with other related initiatives, protocols, systems, and services. Attendees will include persons with an active interest in network-based information systems and relevant research. Presentations will include design and implementation of client-server architectures, resource discovery, distributed file systems and services, development of integrated network tools, and innovative applications of more basic technologies, such as bulletin board systems and electronic mail. Workshop format involves a plenary session from 8:30-11:30 a.m., with invited speakers, each of them addressing a major theme in the area of wide-area networking. After some discussion, the workshop will break up into groups, starting with a working lunch. The selection of groups and participants in those groups will be based on short interest statement sent to the program committee, since we expect interest in this workshop to exceed limitations of hotel space available. The workshop will conclude with brief summary presentations by group leaders. Notes from the plenary talks and from the interest statements will be provided to attendees and made available afterwards for online access. In addition to discussion of the initiatives, protocols, systems, and services listed above, other topics of interest include: * scaling - to handle more users, more databases or documents, bigger databases, larger data items (e.g., multimedia) * efficiency - algorithms, data structures, simulations, experiments * effectiveness - evaluation methods, studies, designs * interfaces - platforms, user needs, development methods, evaluations, integration with other applications * limitations and future plans for enhancement * progress in developing standards or using existing ones * technical details relating to protocols, implementations * user studies, application surveys, innovative uses * integration - plans, designs, requirements, implementations of systems to integrate information access over the networks * novel applications using network-enabled information access technology. If you are interested in attending, please prepare a 1-page statement of interest, covering your background and experience, and touching on the topics listed above. Program Committee includes: George Brett Edward Fox, Chair Brewster Kahle Clifford Lynch Craig Stanfill Craig Summerhill Chris Tomer, Co-chair and local arrangements coordinator For more information or to submit your 1-page interest statement, contact: Edward A. Fox Dept. of Computer Science 562 McBryde Hall Blacksburg, VA 24061-0106 FAX: 703/231-6075 Internet: fox@fox.cs.vt.edu BITNET: foxea@vtcc1 (that is a one, not el) From ietf-wnils-request@ucdavis.ucdavis.edu Mon Mar 8 00:20:51 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22803; Mon, 8 Mar 93 00:15:04 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06951; Sun, 7 Mar 93 23:49:42 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21637; Sun, 7 Mar 93 23:40:47 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21337; Sun, 7 Mar 93 23:32:25 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA16996; Mon, 8 Mar 1993 17:00:44 +0930 Message-Id: <9303080730.AA16996@jarrah.itd.adelaide.edu.au> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Call for comments and some thoughts... In-Reply-To: Your message of "Thu, 04 Mar 1993 22:36:01 CDT." <9303050336.AA07573@expresso.bunyip.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 08 Mar 1993 17:00:43 +0930 From: Mark Prior Now, on to security. Basically, I think no one disputes the need for some security and authentication mechanisms to protect all or part of certain databases from prying eyes. My my how things change! At the BOF way back in Boston it seemed that the rationale for creating this group (and it certainly wasn't clear that there was any concensus that the group should be created but that's another story) was that the whois service could be improved if the format of the responses returned from any given server was standardised. This led to a charter that states "The purpose of the Whois and Network Information Lookup Service (WNILS) Working Group is to expand and define the standard for WHOIS services, to resolve issues associated with the variations in access and to promote a consistent and predictable service across the network." Then we had a posting from PeterD (which still isn't an official I-D) that besides creating a whole new protocol says "At the same time, given the unauthenticated nature of the service users are cautioned against putting too much faith in the information served. Users looking for a secure, authenticated and robust service are advised to check out the work being done on generalized directory services, where such considerations have been given more weight (and have consequentally added additional weight to the resulting service)." Now we have this section on security and authentication. Come on now Peter either this is a clean up of whois or it's a directory service and I can't see how you can honestly say that this group is chartered to do that (besides the fact that at the BOF it was made pretty clear that it wasn't going to be a directory service and the name was changed from DREGS to WNILS to avoid that confusion). Could someone explain why this group seems to have been hijacked into doing something other than what it is chartered to do. Mark. PS And there better not be any last minute pseudo Internet Drafts issued just before the IETF meeting either. I would like them issued before Tuesday 23th of March so that I can actually print them and read them on my 2 day flight to Columbus. From ietf-wnils-request@ucdavis.ucdavis.edu Mon Mar 8 14:08:27 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22445; Mon, 8 Mar 93 13:59:18 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15755; Mon, 8 Mar 93 13:03:33 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20199; Mon, 8 Mar 93 12:52:47 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from mocha.bunyip.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19325; Mon, 8 Mar 93 12:27:15 -0800 Received: from [192.197.208.2] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07285 (mail destined for ietf-wnils@ucdavis.edu) on Mon, 8 Mar 93 14:45:07 -0500 Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0) id AA13764; Mon, 8 Mar 93 14:35:39 -0500 Message-Id: <9303081935.AA13764@expresso.bunyip.com> From: peterd@expresso.bunyip.com (/usr/spool/mail/peterd) Date: Mon, 8 Mar 1993 14:35:37 -0500 In-Reply-To: Mark Prior's message as of Mar 8, 17:00 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Mark Prior , ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Call for comments and some thoughts... Hello Mark, Sorry, but errr, hello? I must say I was a little surprised by the tone and thrust of your posting. I don't have a lot of time to reply to it, so this may seem a little rushed and rude but what you wrote certainly seems worthy of a response ASAP, since I'm trying to get a draft out and I want to make sure people are not put off from commenting on what I've sent so far by your posting. Rest assured that there's nothing personal in what I've written here. [ you wrote: ] } Now, on to security. Basically, I think no one disputes } the need for some security and authentication mechanisms } to protect all or part of certain databases from prying } eyes. } } My my how things change! } } At the BOF way back in Boston it seemed that the rationale for } creating this group (and it certainly wasn't clear that there was any } concensus that the group should be created but that's another story) I suppose it wouldn't help if I pointed out that the motto of the IETF is "rough consensus and working code"? It is my understanding of the IETF process that we do not require that 100 percent of the population agree on _anything_, provided there is rough consensus that an action is appropriate. As someone who was in Boston _I_ certainly seem to recall that there was rough consensus to explore the possibility of improving the WHOIS White Pages service and given the interest in the working group and the response to the work we've done so far I certainly think that we've _still_ got consensus that this work is appropriate. Given that the IESG approved the charter, they must have thought so, too. Now, let's return to the sentences of my posting you quote above. # Now, on to security. Basically, I think no one disputes # the need for some security and authentication mechanisms # to protect all or part of certain databases from prying # eyes. Since you seem a little hostile to what I wrote, are you disputing the need for security in WHOIS++? After all, it does appear as item four in the recommendations in the minutes of the Washington meeting and it is something that many people who have seen the architecture have asked about. Or are you objecting to improving WHOIS because of some deeper principle? You're welcome to argue that WHOIS shouldn't have security, but that would mean justifying your recommendation in a posting. } was that the whois service could be improved if the format of the } responses returned from any given server was standardised. This led to } a charter that states } } "The purpose of the Whois and Network Information Lookup Service } (WNILS) Working Group is to expand and define the standard for WHOIS } services, to resolve issues associated with the variations in access } and to promote a consistent and predictable service across the } network." Well, I fail to see a problem here. The name of the working group is "Whois and Network Information Lookup Service Working Group", which implies (at least to me) that Network Information Lookup Services are part of the charter, and given the wording, they are to be developed in conjunction with work to expand and improve the basic WHOIS model. Are you claiming that what we have so far is not an extension to WHOIS, or that it is not an Information Lookup Service? I need some help here. I should point out also that from the quoted passage we are also mandated to "_expand_ and define the standard for WHOIS services.." (note my added emphasis on `expand') which implies to me that extensions to the service, where appropriate, are part of the charter, too. So, although WHOIS has no security, it would seem appropriate, if a rough consensus agrees, that we look at adding it to the expanded service. Hence my posting, which is a proposal for a mechanism to add such an extension. And yes, I posted an overview of what I wanted to do first in an attempt to garner consensus before wasting time on wordsmithing something that others don't want. If you don't agree with the proposed mechanism, say so. If you have an alternative, let's hear it, but I think the time to say that such a working group is not wanted or needed is past. I vote we get on with doing what we've been chartered to do and not waste time with political discussions. } Then we had a posting from PeterD (which still isn't an official I-D) } that besides creating a whole new protocol says Okay, I'll address this back-handed comment first. My original draft was posted to the working group just before the last IETF as a focus for discussion and to attempt to garner support for the approach taken by one group of us for improvements and enhancements we perceive are needed. There is nothing stopping you from posting a similar document, if you wish, or posting technical comments on the parts you disagree with. I thought that was the way a working group was _supposed_ to work, or am I missing something here? And I should point out that I'm not sure _why_ my document (well, `our' document, since I'm only the wordsmith on this for a group of people who I think share similar views) is not yet an Internet Draft, since I'm not the working group chair. I assume it's mainly because I have a real life and occasionally I visit it around Christmas to see how it's doing without me. I also have a new company to help run and occasionally I visit that, too. Thus, I didn't get the changes from Washington folded in yet. Well, I'm back into the fray now and since I promised to fold in the changes and suggestions made at the last IETF, I am now doing that. As part of the process I started soliciting comments on what we're proposing before we launch the next draft, which will hopefully ensure that we have "rough consensus" earlier than we might otherwise see. After all, isn't the point of this to get out a better network information lookup service? That's why _I'm_ working on it... } "At the same time, given the unauthenticated nature of the service } users are cautioned against putting too much faith in the information } served. Users looking for a secure, authenticated and robust service } are advised to check out the work being done on generalized directory } services, where such considerations have been given more weight (and } have consequentally added additional weight to the resulting } service)." } } Now we have this section on security and authentication. Yup, prepared precisely at the request of the participants of the last working group meeting and following comments and postings on the original proposal you quoted. Look at page 516 of the printed minutes, third bullet down. Yeesh... } } Come on now Peter either this is a clean up of whois or it's a } directory service and I can't see how you can honestly say that this } group is chartered to do that (besides the fact that at the BOF it } was made pretty clear that it wasn't going to be a directory service } and the name was changed from DREGS to WNILS to avoid that confusion). Or perhaps a clean-up of WHOIS _is_ a directory service? Or do you claim that WHOIS is _not_ a White Pages directory service? Maybe you can clarify the distinction you seem to be making, as I don't get it. I might add that _I_ was the one who suggested that we change the name at the Boston BOF since I perceived (at the time as an outside observer) that the meeting was being held up by silly debates over names, instead of addressing substative issues. You may not believe that the current WHOIS is a "directory service", but since it gives substantially the same information as X.500 when asked substantially the same questions, and assuming that in fact X.500 _is_ a "directory service", I fail to catch the distinction. I still think if you're hung up on the word you're free to not use it and call WHOIS an "Internet Information Lookup Service". That's what it is... Now, we've made no bones about it from the beginning, our intention in the original group was to extend WHOIS to make it more flexible and useful to the community. Hence the slightly silly name (with the obvious pun on C++, which is in my mind a rather yucky extension to C to add support for objected oriented programming. Personally, I prefer Objective C, but I thought "Objective WHOIS" just wasn't as funny...) To do this, we've implemented a new architecture and offer a more extensible, powerful data model which builds, among other things, upon the work of the IAFA group to standardize information templates (and yes on earlier efforts at directory services and other online services such as Gopher, archie and WAIS). We've also tried to learn from some of the mistakes of these other systems, in the hope that what comes out at the end of the process is a better, more useful service than anything we have now. Do you have a problem with any of this? Now, given that the working group charter has been accepted by the IETF process, our architecture was discussed at the last IETF and that no less than three draft documents describing it have now been circulating for several months (on this mailing list and as postings and presentations to interested parties) and given that everyone presumably wants to see the community have viable Internet Information Lookup Services ASAP, no matter what they're called and no matter who builds them, I don't personally see any problems with what we have so far. If you do, please post them. At the same time, I don't see how you can imply (as you seem to be doing) that we're trying to slip one over on the Internet community by offering our own solution to what seems to be a hard problem. From what I've seen, many people welcome the approach we've taken (which is to strive for simplicity, ease of implementation and extensibility) and if you object to something in our architecture, or in how we're implementing it so far, do say so. But please spare me the veiled hints that somehow we're up to something. If what we build has no value, nobody's going to use it. If what we build satisfies a need, people will use it. End of story. } Could someone explain why this group seems to have been hijacked into } doing something other than what it is chartered to do. Errr, hijacked? We were tasked with coming up with improvements to WHOIS and we have proposals for doing this. We were then asked to come up with extensions for security and multilingual support and I've a proposal for doing so. Before writing up a spec (which is obviously some work and an area where misunderstandings can be costly in terms of time and lost effort) I'm circulating my proposal for comments to the appropriate working group. I fail to see any hijacking here, unless this is an attempt by the X.500 community to short-circuit the project because it is perceived as a threat to their established efforts? Remember, the point is not to get anybody's favorite protocol adopted despite lack of user acceptance, nor to protect any one person's favorite architecture from competing visions. I thought the idea was to ensure that we have the best Internet possible for the most number of people. If there are better ways to do something, tell me. But please be up front about it and let's avoid the insinuations, okay? Of _course_ some of what we are proposing overlaps into areas of work done by the X.500 community. This is no surprise, since WHOIS _is_ a primitve WHITE PAGES directory service and we're now working on changes and enhancements to it. If you don't think this work is needed say so, or simply don't participate and don't use the results of our work. If you think our technical approach is flawed, say so. But please don't attempt to convince me that the X.500 community has a perpetual lock on Directory Services at the IETF and that the Internet community cannot explore alternatives, enhancements or improvements to what has already been done in the past. That's simply obstructionism. } PS And there better not be any last minute pseudo Internet Drafts } issued just before the IETF meeting either. I would like them issued } before Tuesday 23th of March so that I can actually print them and } read them on my 2 day flight to Columbus. Well, as I've already stated the whole point of the posting last week was to avoid this by getting comments in from those who (like me) had let this work slip onto the back burner so that I can finish the draft ASAP. If you have any _technical_ comments on what's in the current proposals, why not post them, rather than attacking the process in this way? Seems to me that this would be more productive, given how little time we all have to do what is essentially volunteer work. And as a final comment on this, please recall that we went from some good ideas on the bar napkins in Boston to an alpha implementation of a server and three documents in draft by Washington. Sorry if we didn't send out copies of everything weeks in advance, but quite frankly they simply weren't available. The working group now has at least one proposal on the table and we're now working on the next step, which is refinement and discussion of proposals. You're welcome to comment on what is being proposed or suggest your own changes, but please let's spare outselves internecine turf wars. We've a network to build. - peterd -- ------------------------------------------------------------------------------- One should never ascribe to malice that which can be adequately explained by incompetence... - This may be original, I can't remember ------------------------------------------------------------------------------- From ietf-wnils-request@ucdavis.ucdavis.edu Tue Mar 9 01:30:13 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15639; Tue, 9 Mar 93 01:19:59 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24570; Tue, 9 Mar 93 00:50:24 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14269; Tue, 9 Mar 93 00:41:43 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14145; Tue, 9 Mar 93 00:37:36 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA27368; Tue, 9 Mar 1993 18:06:00 +0930 Message-Id: <9303090836.AA27368@jarrah.itd.adelaide.edu.au> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Call for comments and some thoughts... In-Reply-To: Your message of "Mon, 08 Mar 1993 14:35:37 EST." <9303081935.AA13764@expresso.bunyip.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 09 Mar 1993 18:05:59 +0930 From: Mark Prior } Now, on to security. Basically, I think no one disputes } the need for some security and authentication mechanisms } to protect all or part of certain databases from prying } eyes. } } My my how things change! } } At the BOF way back in Boston it seemed that the rationale for } creating this group (and it certainly wasn't clear that there was any } concensus that the group should be created but that's another story) I suppose it wouldn't help if I pointed out that the motto of the IETF is "rough consensus and working code"? It is my understanding of the IETF process that we do not require that 100 percent of the population agree on _anything_, provided there is rough consensus that an action is appropriate. As someone who was in Boston _I_ certainly seem to recall that there was rough consensus to explore the possibility of improving the WHOIS White Pages service and given the interest in the working group and the response to the work we've done so far I certainly think that we've _still_ got consensus that this work is appropriate. Given that the IESG approved the charter, they must have thought so, too. While I agree with the motto I don't agree we even had "rough concensus" in Boston and was quite surprised that a WG group appeared in Washington. It seemed to me that there were at least three groups involved in the discussion in Boston. 1. You, Joan, etc 2. Me, Steve Kille, etc 3. People caught in the cross fire :-) It seemed to me that the discussion was going nowhere fast. Anyway as you said ... Now, let's return to the sentences of my posting you quote above. # Now, on to security. Basically, I think no one disputes # the need for some security and authentication mechanisms # to protect all or part of certain databases from prying # eyes. Since you seem a little hostile to what I wrote, are you disputing the need for security in WHOIS++? After all, it does appear as item four in the recommendations in the minutes of the Washington meeting and it is something that many people who have seen the architecture have asked about. Or are you objecting to improving WHOIS because of some deeper principle? You're welcome to argue that WHOIS shouldn't have security, but that would mean justifying your recommendation in a posting. I assumed that if this proposal is to build on whois and make it (continue to be) usable then it should be a simple, lightweight package that leverages off some other Directory, whether that be WAIS, X.500, Oracle whatever. In this scenario there should be no need for whois to provide any security as this is provided by the underlying Directory. Whois is just a convenient standardisation of the interface to this Directory. Are you claiming that what we have so far is not an extension to WHOIS, or that it is not an Information Lookup Service? I need some help here. I am claiming that the direction you seem to be driving this proposal in is too far. Whois is a simple one shot lookup service. The user supplies their query to the system and the server responds with any information it thinks satisfies the request. When you add in an authentication mechanism you are moving away from this simplicity by adding a more complex interaction between client and server. This I think is wrong. I should point out also that from the quoted passage we are also mandated to "_expand_ and define the standard for WHOIS services.." (note my added emphasis on `expand') which implies to me that extensions to the service, where appropriate, are part of the charter, too. Well I would emphasise "whois standard" too. What you are proposing isn't whois, it is something larger and more complex. } Then we had a posting from PeterD (which still isn't an official I-D) } that besides creating a whole new protocol says Okay, I'll address this back-handed comment first. My original draft was posted to the working group just before the last IETF as a focus for discussion and to attempt to garner support for the approach taken by one group of us for improvements and enhancements we perceive are needed. There is nothing stopping you from posting a similar document, if you wish, or posting technical comments on the parts you disagree with. I thought that was the way a working group was _supposed_ to work, or am I missing something here? I wasn't commenting on some slackness on your part, I was commenting on the fact that I am trying to do an experimental implementation and I went looking for the I-D and couldn't find it where I would have expected it. In fact I only found one of the documents in the internet drafts area on munnari.oz.au, the third one! It is very hard to comment on a document if you can't find the sucker or if you think there has got to be something newer than a proposal dated August 19, 1992. Would you care to post it again so at least we can talk about the same thing, and those people who may have joined the list after Washington can get it easily (the charter document describes an archive that doesn't exist). } Come on now Peter either this is a clean up of whois or it's a } directory service and I can't see how you can honestly say that this } group is chartered to do that (besides the fact that at the BOF it } was made pretty clear that it wasn't going to be a directory service } and the name was changed from DREGS to WNILS to avoid that confusion). Or perhaps a clean-up of WHOIS _is_ a directory service? Or do you claim that WHOIS is _not_ a White Pages directory service? Maybe you can clarify the distinction you seem to be making, as I don't get it. My idea of whois is a known interface to a Directory Service not one in it's own right. Now, given that the working group charter has been accepted by the IETF process, our architecture was discussed at the last IETF and that no less than three draft documents describing it have now been circulating for several months I assume you mean the following documents - Joan's posting posted on 8th October 92 Your's posted on 13th November 92 Chris' posting posted on 14th November 92 At the same time, I don't see how you can imply (as you seem to be doing) that we're trying to slip one over on the Internet community by offering our own solution to what seems to be a hard problem. From what I've seen, many people welcome the approach we've taken (which is to strive for simplicity, ease of implementation and extensibility) and if you object to something in our architecture, or in how we're implementing it so far, do say so. Simplicity! Where? You keep adding to the poor thing. Having tried implementing it I would say that the grammer could do with simplifying for a start. If you don't think this work is needed say so, or simply don't participate and don't use the results of our work. Well at Boston I did say I didn't think it was needed but given that this thing is going ahead I am trying to make sure that it doesn't get out of hand. And as a final comment on this, please recall that we went from some good ideas on the bar napkins in Boston to an alpha implementation of a server and three documents in draft by Washington. Sorry if we didn't send out copies of everything weeks in advance, but quite frankly they simply weren't available. Well I'm not sure how you expect people who are also as busy as you are to make any sort of rational judgement and comments on a draft if it is released on the weekend before the IETF like two of them were last time. It is especially hard for those of us who either have to travel half way around the planet to attend or have to try to arrange with someone else to make comments on their behalf. Mark. From ietf-wnils-request@ucdavis.ucdavis.edu Tue Mar 9 12:32:58 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08530; Tue, 9 Mar 93 12:18:30 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01079; Tue, 9 Mar 93 11:20:32 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06234; Tue, 9 Mar 93 11:10:22 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from mocha.bunyip.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05277; Tue, 9 Mar 93 10:42:18 -0800 Received: from [192.197.208.2] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08922 (mail destined for ietf-wnils@ucdavis.edu) on Tue, 9 Mar 93 13:40:35 -0500 Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0) id AA14751; Tue, 9 Mar 93 13:39:16 -0500 Message-Id: <9303091839.AA14751@expresso.bunyip.com> From: peterd@expresso.bunyip.com (/usr/spool/mail/peterd) Date: Tue, 9 Mar 1993 13:39:14 -0500 In-Reply-To: Mark Prior's message as of Mar 9, 18:05 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Mark Prior , ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Call for comments and some thoughts... Hi again, } I suppose it wouldn't help if I pointed out that the motto } of the IETF is "rough consensus and working code"? . . . . . . } While I agree with the motto I don't agree we even had "rough } concensus" in Boston and was quite surprised that a WG group appeared } in Washington. It seemed to me that there were at least three groups } involved in the discussion in Boston. } 1. You, Joan, etc } 2. Me, Steve Kille, etc } 3. People caught in the cross fire :-) } It seemed to me that the discussion was going nowhere fast. Actually, to keep the timeline accurate, I began working with Joan and the others _after_ that BOF. Yes, I participated in the conversations that night (as anyone who knows me will attest, I seem to have opinions about almost everything) but I don't want to leave the impression that there was any organized WHOIS-related activity before that BOF (I'm proud of how fast we put our proposals together!). I quite literally had no idea what we would be discussing before I walked into the room that night. When I first showed up I actually felt I was one of the people "caught in the cross fire" (those who were there might remember that I sat between Steve Kille and those down the front... :-) I _do_ agree that the discussion didn't seem to be going anywhere fast for a while, but that doesn't mean either that nothing was accomplished or that there was not a rough consensus to continue at the end of the meeting. For what it's worth I think part of the problem was that the X.500 people and the WHOIS people were there for different reasons and were talking about different things. I see no problem with that but it helps if we keep the players straight. . . . } Since you seem a little hostile to what I wrote, are you } disputing the need for security in WHOIS++? After all, it } does appear as item four in the recommendations in the } minutes of the Washington meeting and it is something that } many people who have seen the architecture have asked } about. Or are you objecting to improving WHOIS because of } some deeper principle? You're welcome to argue that WHOIS } shouldn't have security, but that would mean justifying } your recommendation in a posting. } } I assumed that if this proposal is to build on whois and make it } (continue to be) usable then it should be a simple, lightweight } package that leverages off some other Directory, whether that be WAIS, } X.500, Oracle whatever. Actually, the way we have architected our proposal implementors or operators are certainly free to leverage off other systems, such as Oracle, or X.500 or whatever. On the other hand, under our proposal you are not _required_ to do so, which I happen to believe is one of our strengths. We attempt to standardize where it matters (communications protocol, information model) while leaving decisions about security level or database implementation and access details to those who care about such things. I think this was one of the big failings in the original X.500 effort, in that they attempted to standardize such things as database system or template contents and this hobbled deployment ("favorite drink"? Really...) What we have done is defined a model for the service, and the associated protocol to access information represented in that model. Anyone is free to define a mapping between their own model and WHOIS++, and I hope and expect that people will do so, to allow rapid population with data (which I think is critical to the success of any new service). Those more comfortable with tree browsing models can use them. Those more comfortable with using systems such as X.500 directly can ignore us if the information is available to them from their X.500 client. And yes, although the idea has been fought tooth and nail for two years, the X.500 community is free to build gateways to other people's information and serve it through their protocol, if they wish. Call it genetic diversity of directory services, which I think is a "Good Thing (tm)". } . . . In this scenario there should be no need for } whois to provide any security as this is provided by the underlying } Directory. Whois is just a convenient standardisation of the interface } to this Directory. Well, I happen to disagree. Since we don't want to _require_ the use of any particular underlying access method, we have to provide all the functionality that our service is to offer up front. Now, someone may choose to implement such a feature by merely gatewaying and mapping to an underlying service, but we can't assume that such an underlying service is either: a) universally available (aren't there currently only something like 170 X.500 servers on the net? 1,000 Gophers? 800 WAIS servers? Nobody's ubiquitous yet, nor will they ever be I think...), b) extensible enough to handle all the things we might want to add later (can I add additional authentication to WAIS? How does that tie in to Gopher? Who wants to care?) Thus, I propose a couple of simple, extensible mechanisms for WHOIS++ and suggest we leave the implementation details to the implementors. } Are you claiming that what we have so far is not an } extension to WHOIS, or that it is not an Information } Lookup Service? I need some help here. } } I am claiming that the direction you seem to be driving this proposal } in is too far. Whois is a simple one shot lookup service. The user } supplies their query to the system and the server responds with any } information it thinks satisfies the request. When you add in an } authentication mechanism you are moving away from this simplicity by } adding a more complex interaction between client and server. This I } think is wrong. There are several points I'd like to make here. First, "driving to far" is your opinion. I obviously disagree, since I think our architecture has a lot of promise and the potential to address several open problems I perceive in the field and I would like to experiment with it to see how far it can go. My company has already found several internal applications for it outside the realm of an Internet White Pages service and from talks and correspondance I've had, I gather others have as well. This is to me the mark of a good solution, since it hints we might be generalizing in the right direction. Nothing wrong with that, is there? Second, the _current_ WHOIS is a one-shot service. We're working on extensions so there's nothing wrong with experimenting with multiple iteration transactions if it buys us something (like authentication). Heck, I even have a proposal (which I've held back on so far) that we add a "HOLD" constraint, which would instruct the server not to drop the link after a reply (perhaps keeping it open for a predetermined period for followup queries). This optional feature could be used by clients that know they will want to perform multiple queries to a single server. I'm not yet convinced that this is needed or desirable (witness Gopher's success without it) but I certainly see nothing wrong with discussing it. After all, we're chartered to look at extensions and that is an extension, too. Let's not knacker ourselves before we even begin through lack of ambition. Third, the various mechanisms I'm proposing are _optional_, which means that nobody's required to implement or use them. Again, in my mind that's one of our strengths. We require little but we allow a lot. A bare-bones server doing only the required minimum can still be built in a few weekends. We have an existance proof of this already. } I should point out also that from the quoted passage we } are also mandated to "_expand_ and define the standard for } WHOIS services.." (note my added emphasis on `expand') } which implies to me that extensions to the service, where } appropriate, are part of the charter, too. } } Well I would emphasise "whois standard" too. What you are proposing } isn't whois, it is something larger and more complex. Sigh. Fine, don't use it. If you're right, and the extensions are too complex to be worth implementing, no one will build or use it and the proposal will die. In the meantime, we'll have helped define the problem space and hopefully pushed improvements through in the area across the board. On the other hand, if we're right and it is "just complex enough" then WHOIS++ will flourish and we'll all have a better Information Lookup Service based upon our work. Sounds like a win either way. } } Then we had a posting from PeterD (which still isn't an official I-D) } } that besides creating a whole new protocol says } } Okay, I'll address this back-handed comment first. . . . } I wasn't commenting on some slackness on your part, I was commenting } on the fact that I am trying to do an experimental implementation and } I went looking for the I-D and couldn't find it where I would have } expected it. In fact I only found one of the documents in the internet } drafts area on munnari.oz.au, the third one! } } It is very hard to comment on a document if you can't find the sucker } or if you think there has got to be something newer than a proposal } dated August 19, 1992. Sorry, I really think this is a housekeeping issue and should have been addressed as private email to the chair, not included in a general posting to the entire list. Meanwhile, the draft you have _is_ the current proposal and technical comments on it are welcome. } Would you care to post it again so at least we can talk about the same } thing, and those people who may have joined the list after Washington } can get it easily (the charter document describes an archive that } doesn't exist). I'd be glad to send out a copy of the original proposal if there is a genuine lack of availability, although when it was posted I thought I made it clear that it was a strawman proposal and people should not try to implement to it until the working group had endorsed the approach and we had a more stable version of the protocol available. As for the lack of an archive, that's nothing to do with me. Perhaps a politely worded request to the working group chair would have been more appropriate? That would also have solved the distribution problem in a more appropriate manner than having people periodically reposting the documents. At the same time, _you_ already have a copy of the most recently circulated draft so I don't see why you would complain that it's hard for _you_ to comment. Rest assured, I too want a new draft out, but I really would like to have some _technical_ discussion on the proposals before I do the final wordsmithing. I just don't see any worth in posting something that's half-baked or not finished, since you might then justifiably complain that the spec keeps changing and you can't implement under such conditions. I think our time would be better spent getting the proposals to an acceptable level of consensus before we start multiple teams seriously hacking code. Let's keep things in perspective. We've only had _one_ meeting of the working group, held Wednesday, Nov.18th. At that meeting we discussed a strawman proposal for WHOIS extensions that a bunch of keeners had worked out, and the group generated comments and feedback on this proposal. In my humble opinion consensus on the current approach was reached at that meeting and we are now working on refinements and extensions to the proposal that the group has requested. The next task is to refine the proposals and firm up the protocol, while ensuring that we can actually build this thing. If there are no _technical_ problems, we can then look at deployment on a large scale. I've now posted _my_ views on the issues of security and multiple language support (and judging from the lack of technical criticism I'm almost ready to conclude that there is consensus on this and write it up). I also hope (perhaps today) to post my views on some of the other outstanding issues brought up at the working group. Again, if there is no howl of protest I will then fold these into my document. Seems like the process is working just as it should. } } Come on now Peter either this is a clean up of whois or it's a } } directory service and I can't see how you can honestly say that this } } group is chartered to do that (besides the fact that at the BOF it } } was made pretty clear that it wasn't going to be a directory service } } and the name was changed from DREGS to WNILS to avoid that confusion). } } Or perhaps a clean-up of WHOIS _is_ a directory service? } Or do you claim that WHOIS is _not_ a White Pages } directory service? Maybe you can clarify the distinction } you seem to be making, as I don't get it. } } My idea of whois is a known interface to a Directory Service not one } in it's own right. Okay, valid view, although not one I agree with. I think abstracting out the data storage and access is a strength of the WHOIS system, and obviously one we should build on. To overuse a popular buzz word (buzz phrase?? :-) "Open Systems" are ones that don't tie us into any one vendor system or architecture. We've hopefully got a system here that's as open as it can be and still function. I think it's a great solution to the problem. } } Now, given that the working group charter has been } accepted by the IETF process, our architecture was } discussed at the last IETF and that no less than three } draft documents describing it have now been circulating for } several months } } I assume you mean the following documents - } } Joan's posting posted on 8th October 92 } Your's posted on 13th November 92 } Chris' posting posted on 14th November 92 Yup. } At the same time, I don't see how you can imply (as you } seem to be doing) that we're trying to slip one over on } the Internet community by offering our own solution to } what seems to be a hard problem. From what I've seen, many } people welcome the approach we've taken (which is to } strive for simplicity, ease of implementation and } extensibility) and if you object to something in our } architecture, or in how we're implementing it so far, do } say so. } } Simplicity! Where? You keep adding to the poor thing. Having tried } implementing it I would say that the grammer could do with simplifying } for a start. Okay, I gather you don't like the suggestion to have a set of optional features to address the items requested by the working group. The other possible solution seems to be make them all required, which is (IMHO) worse in terms of complexity. Any other possibilities that still allow us to add the requested features? } } If you don't think this work is needed } say so, or simply don't participate and don't use the } results of our work. } } Well at Boston I did say I didn't think it was needed but given that } this thing is going ahead I am trying to make sure that it doesn't get } out of hand. What do you mean "get out of hand". Do you want to make sure what we do is not powerful enough to do real work, or just that we don't get around to solving the problems we've set out to address? I think our "bit slice" approach, where only a core subset of features are required, and everything else is an option, can successfully solve the problem we're addressing in a simple and feasible way. How is this "getting out of hand"? } } And as a final comment on this, please recall that we went } from some good ideas on the bar napkins in Boston to an } alpha implementation of a server and three documents in } draft by Washington. Sorry if we didn't send out copies of } everything weeks in advance, but quite frankly they simply } weren't available. } } Well I'm not sure how you expect people who are also as busy as you } are to make any sort of rational judgement and comments on a draft if } it is released on the weekend before the IETF like two of them were } last time. It is especially hard for those of us who either have to } travel half way around the planet to attend or have to try to arrange } with someone else to make comments on their behalf. Which is why we're trying to get some work done _now_. So please go ahead and make some comments on the proposal you have in your hands. This might give us time to reach consensus and fold in the comments before the end of the month. If not, at least it gives us a discussion item for the agenda. So, does anyone else have any objections to the proposed language and security extensions? Otherwise, should I write them up into a concrete proposal for the document? More later. Time for some lunch... - peterd -- ------------------------------------------------------------------------------- One should never ascribe to malice that which can be adequately explained by incompetence... - This may be original, I can't remember ------------------------------------------------------------------------------- From ietf-wnils-request@ucdavis.ucdavis.edu Wed Mar 10 01:32:16 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06082; Wed, 10 Mar 93 01:25:24 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11438; Wed, 10 Mar 93 00:50:19 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04628; Wed, 10 Mar 93 00:41:45 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04493; Wed, 10 Mar 93 00:36:43 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA08171; Wed, 10 Mar 1993 18:04:59 +0930 Message-Id: <9303100834.AA08171@jarrah.itd.adelaide.edu.au> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Comments on the "Whois++ Architecture" document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Mar 1993 18:04:58 +0930 From: Mark Prior OK Peter here are my comments on the document. These comments are in no particular order and are just a result of me going through the notes I have scribbled on my copy and the comments I have written in my code which attempts to implement it. But first a comment on the language extension you made last week. I agree that there should be multiple natural language support but am not sure (at this stage) whether there really needs to be two way character set support. This does raise an issue not covered in the draft though that does need looking into, that is the ability to query the server if a particular constraint is supported. This is especially true now that you say that a server need not support the whole proposed standard. In this case I think there needs to be two extensions 1. query if a constraint is supported, eg there should be a command such as "supported =" which the server will respond to with either an affirmative or negative response. 2. ask for a list of supported values for a particular constraint. If the constraints command is changed to "constraint [ ]" then you could query the system to find all valid contraints or just the valid values for a particular constraint. I see this being used by a sophisticated client (ie not the existing whois client :-) to determine if a particular language is supported and if it isn't then providing a list of supported languages. Say a user in Switzerland is trying to find my entry but they want the response in a particular language then the client may ask my server supported language=french my server could respond with some negative acknowledgement, eg % notok so the client could then ask for a list of languages constraint language whereby my server would return a list of valid (to it) languages. The user would then be advised of these values at which stage they could select one and my server would be queried again or the user could abort the query. Note this is a stateless dialogue between server and client and so an original whois client could still interact with my server. Now onto the actual draft... In the valid commands you provide an optional parameter to the list command. What purpose does this really serve and is it necessary? I assume it would only return either the name of the template as supplied by the user or a diagnostic message (of no such template). The BNF allows multiple terms, what does it mean when you combine multiple terms with the same specifier? I assume they are or'ed. I think the section on specifiers needs to be made clearer, especially as it relates to the information searched and the data returned. How useful is all this anyway, you can spend a lot to time making a parser to parse the compound search terms and then constructing a suitable query but for what gain? Also I expect it only makes sense to have a single term when you are using the handle specifier. Your example of an abridged format response lacks the required template type (according to the paragraph on abridged, the bullet point doesn't mention template type). I think the formatted response should be marked as optional in your diagram too. Start lines should be able to be continued like lines within the actual formatted response. It is not clear whether the responses from commands like version are system responses, ie need a leading %, or regular responses. If they are regular response do they need a leading space or not? More tomorrow... :-) Mark. From ietf-wnils-request@ucdavis.ucdavis.edu Wed Mar 10 08:59:59 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22026; Wed, 10 Mar 93 08:46:20 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13726; Wed, 10 Mar 93 08:03:44 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19807; Wed, 10 Mar 93 07:45:10 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from blacks.jpl.nasa.gov by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19648; Wed, 10 Mar 93 07:39:44 -0800 Received: from localhost.jpl.nasa.gov by blacks.jpl.nasa.gov (4.1/SMI-4.1) id AA16029; Wed, 10 Mar 93 07:33:11 PST Message-Id: <9303101533.AA16029@blacks.jpl.nasa.gov> To: ietf-wnils@ucdavis.ucdavis.edu Cc: dank@blacks.jpl.nasa.gov Subject: Re: Comments on the "Whois++ Architecture" document Date: Wed, 10 Mar 93 07:33:11 PST From: dank@blacks.jpl.nasa.gov Sigh. The output format proposed for whois++ looks like a pain to parse by machine. I suggest that either we switch to a format designed to be trivial to parse, like ph's output format (which precedes each output line with a numerical code indicating its general meaning), or require the whois++ specification to include source code and test cases for a complete whois++ output parser. Otherwise we may find ourself with a system which is difficult for agent software (e.g. email address resolution) software to interface to. - Dan Kegel (dank@blacks.jpl.nasa.gov) From ietf-wnils-request@ucdavis.ucdavis.edu Sat Mar 13 01:30:04 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17436; Sat, 13 Mar 93 01:23:18 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29017; Sat, 13 Mar 93 00:29:18 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16508; Sat, 13 Mar 93 00:20:50 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16493; Sat, 13 Mar 93 00:19:26 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA06696; Sat, 13 Mar 1993 17:47:45 +0930 Message-Id: <9303130817.AA06696@jarrah.itd.adelaide.edu.au> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Call for comments and some thoughts... In-Reply-To: Your message of "Tue, 09 Mar 1993 13:39:14 EST." <9303091839.AA14751@expresso.bunyip.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 Mar 1993 17:47:44 +0930 From: Mark Prior When I first showed up I actually felt I was one of the people "caught in the cross fire" (those who were there might remember that I sat between Steve Kille and those down the front... :-) I _do_ agree that the discussion didn't seem to be going anywhere fast for a while, but that doesn't mean either that nothing was accomplished or that there was not a rough consensus to continue at the end of the meeting. You have a very strange definition of the word consensus. } I assumed that if this proposal is to build on whois and make it } (continue to be) usable then it should be a simple, lightweight } package that leverages off some other Directory, whether that be WAIS, } X.500, Oracle whatever. Actually, the way we have architected our proposal implementors or operators are certainly free to leverage off other systems, such as Oracle, or X.500 or whatever. On the other hand, under our proposal you are not _required_ to do so, which I happen to believe is one of our strengths. We attempt to standardize where it matters (communications protocol, information model) while leaving decisions about security level or database implementation and access details to those who care about such things. I think this was one of the big failings in the original X.500 effort, in that they attempted to standardize such things as database system or template contents and this hobbled deployment ("favorite drink"? Really...) Well this sort of comment is the type of comment that gets people upset, as well as Joan's comment at the BOF about the speed of X.500 systems. The fact that X.500 is extensible enough for someone to define an attribute such as favourite drink is seen as an advantage. If enough people want it then why shouldn't it's use be standardised. It seems that people who don't like X.500 always point at it saying how monolithic it is and that it would be much better if it only focussed itself on a smaller problem space. Obviously you don't think this is a failing since you seem to want to drive whois++ in the same direction. I don't think security/authentication of the user has any place in whois++, and it appears that you can't make up your mind about it either. I would have thought that either the system is a standalone system and so the data present would only consist on freely available data (and thus there is no security concern) or the system is an interface to another system and then any access restrictions would be built into the interface between the two systems. Adding this to the whois++ spec is just not justified. Those more comfortable with tree browsing models can use them. Those more comfortable with using systems such as X.500 directly can ignore us if the information is available to them from their X.500 client. And yes, although the idea has been fought tooth and nail for two years, the X.500 community is free to build gateways to other people's information and serve it through their protocol, if they wish. Call it genetic diversity of directory services, which I think is a "Good Thing (tm)". I certainly don't have any trouble with this, my "normal" mode of accessing data in our directory is through our finger server. I only use a dua when I want to get to someone elses data or I want to execute a complex query. As well as writing a whois++ dua interface I am also considering writing one that will gateway from X.500 into whois if necessary. Loading whois server location information into X.500 is no big deal, I just define a new object class and away I go. Thus, I propose a couple of simple, extensible mechanisms for WHOIS++ and suggest we leave the implementation details to the implementors. I think the operative word here is "simple", and I don't think a authentication falls into this category. } Are you claiming that what we have so far is not an } extension to WHOIS, or that it is not an Information } Lookup Service? I need some help here. } } I am claiming that the direction you seem to be driving this proposal } in is too far. Whois is a simple one shot lookup service. The user } supplies their query to the system and the server responds with any } information it thinks satisfies the request. When you add in an } authentication mechanism you are moving away from this simplicity by } adding a more complex interaction between client and server. This I } think is wrong. There are several points I'd like to make here. First, "driving to far" is your opinion. I obviously disagree, since I think our architecture has a lot of promise and the potential to address several open problems I perceive in the field and I would like to experiment with it to see how far it can go. My company has already found several internal applications for it outside the realm of an Internet White Pages service and from talks and correspondance I've had, I gather others have as well. This is to me the mark of a good solution, since it hints we might be generalizing in the right direction. Nothing wrong with that, is there? I have no problem with this per se I am just keen to keep to the KISS principle (ie Keep It Simple Stupid). Third, the various mechanisms I'm proposing are _optional_, which means that nobody's required to implement or use them. Again, in my mind that's one of our strengths. We require little but we allow a lot. Well this should be spelled out in the draft. It also raises the obvious question of how is the poor client going to work out what the server is capable of. I assume you are counting on some poor sucker :-) actually writing a sophisticated client that can interact with this new server. A bare-bones server doing only the required minimum can still be built in a few weekends. We have an existance proof of this already. I can't argue with that since I knocked together a basic server (as a dua interface) according to Joan's spec in short order. Making one conform to your spec is tougher but that's mainly caused by me not understanding what the hell you are trying to do with your search syntax. At the same time, _you_ already have a copy of the most recently circulated draft so I don't see why you would complain that it's hard for _you_ to comment. See my previous message for a first cut on my comments. I have scribbled some more notes on my poor printout so expect some more comments when I get a chance. Rest assured, I too want a new draft out, but I really would like to have some _technical_ discussion on the proposals before I do the final wordsmithing. I just don't see any worth in posting something that's half-baked or not finished, since you might then justifiably complain that the spec keeps changing and you can't implement under such conditions. I think our time would be better spent getting the proposals to an acceptable level of consensus before we start multiple teams seriously hacking code. Well if you want to do some wordsmithing :-) you might take a look at the first two sections and rewrite them. They don't appear to be consistant with your current views on what whois++ is and the motivation for it. I've now posted _my_ views on the issues of security and multiple language support (and judging from the lack of technical criticism I'm almost ready to conclude that there is consensus on this and write it up). I also hope (perhaps today) to post my views on some of the other outstanding issues brought up at the working group. Again, if there is no howl of protest I will then fold these into my document. Seems like the process is working just as it should. Do you want me to comment on the security issue some more and address your original posting? That is, if I assume that there needs to be some mechanism (which I obviously don't) what I think the problems are with your proposal or are you going to leave it out of the new draft until after there has been some more discussion at the IETF? } My idea of whois is a known interface to a Directory Service not one } in it's own right. Okay, valid view, although not one I agree with. I think abstracting out the data storage and access is a strength of the WHOIS system, and obviously one we should build on. To overuse a popular buzz word (buzz phrase?? :-) "Open Systems" are ones that don't tie us into any one vendor system or architecture. We've hopefully got a system here that's as open as it can be and still function. I think it's a great solution to the problem. Well I would have thought that my view was even more in favour of that then your view since I don't care what the underlying engine is at all. I just want to build a known query interface that the poor users can use without caring what the actually happening to resolve their query. } Simplicity! Where? You keep adding to the poor thing. Having tried } implementing it I would say that the grammer could do with simplifying } for a start. Okay, I gather you don't like the suggestion to have a set of optional features to address the items requested by the working group. The other possible solution seems to be make them all required, which is (IMHO) worse in terms of complexity. Any other possibilities that still allow us to add the requested features? I don't mind having optional features, as long as there is a mechanism to find out if an optional feature is available but your draft doesn't state which features are optional. } If you don't think this work is needed } say so, or simply don't participate and don't use the } results of our work. } } Well at Boston I did say I didn't think it was needed but given that } this thing is going ahead I am trying to make sure that it doesn't get } out of hand. What do you mean "get out of hand". Do you want to make sure what we do is not powerful enough to do real work, or just that we don't get around to solving the problems we've set out to address? Well as I think that the current whois is powerful enough to do real work I'm not sure what your problem with it is. My main gripe, and the one I kept harping on at the BOF, was the problem of actually finding the damn servers. This is the biggest plus for X.500 in my opinion, you know where in the tree to look and if it isn't there then it doesn't exist, end of story. With whois the server could be anywhere and there was no way to tell. Mark. From ietf-wnils-request@aggie.ucdavis.edu Thu Mar 18 10:50:21 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29724; Thu, 18 Mar 93 10:34:48 -0800 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA04453; Thu, 18 Mar 93 09:33:17 -0800 Sender: ietf-wnils-request@aggie.ucdavis.edu Received: from bullwinkle.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02615; Thu, 18 Mar 93 08:46:17 -0800 Received: from parapente.ucdavis.edu.ucdavis.edu by bullwinkle.ucdavis.edu (4.1/UCD2.04) id AA15107; Thu, 18 Mar 93 08:44:34 PST From: ccjoan@bullwinkle.ucdavis.edu Date: Thu, 18 Mar 93 08:44:34 PST Message-Id: <9303181644.AA15107@bullwinkle.ucdavis.edu> To: ietf-wnils@aggie.ucdavis.edu Subject: Update to archives and milestones Comments: Internet jcgargano@ucdavis.ucdavis.edu BITNET jcgargano@ucdavis UUCP ucdavis!jcgargano Mailing lists: General Discussion:ietf-wnils@ucdavis.edu To Subscribe: ietf-wnils-request@ucdavis.edu Mail Archive: pub/archive/wnils@ucdavis.edu File Archive: Gopher - gopher.ucdavis.edu, port 70 Anonymous ftp - gopher.ucdavis.edu /pub/IETF/WNILS 5/15/93 Submit the Whois and Network Information Lookup Service Recommendations document to the IESG as an Informational document. 6/11/93 Submit the WHOIS++ protocol and index service documents to the IESG as an Internet Draft. 6/11/93 Submit the revised WHOIS++ protocol and index service documents to the IESG as Draft Standards. Joan Gargano jcgargano@ucdavis.edu Advanced Networked and Scientific Applications (ANSA) (916)752-2591 Information Technology University of California, Davis From ietf-wnils-request@ucdavis.ucdavis.edu Thu Mar 18 17:51:33 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15881; Thu, 18 Mar 93 17:44:27 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14230; Thu, 18 Mar 93 17:20:42 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14819; Thu, 18 Mar 93 17:13:02 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14700; Thu, 18 Mar 93 17:08:20 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA09156; Fri, 19 Mar 1993 10:36:37 +0930 Message-Id: <9303190106.AA09156@jarrah.itd.adelaide.edu.au> To: ietf-wnils@ucdavis.ucdavis.edu Subject: More Whois++ comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Mar 1993 10:36:36 +0930 From: Mark Prior Keeping in mind the IETF's philosophy of "rough consensus and running code" I think we should concentrate on getting the current draft into a state where usuable implementations can be built and then move on from there is need be. So why do I think we can't do that now? :-) Constraints. The current draft only briefly touches on them and I think they need to be fleshed out some more with (at least) the search options from Joan's original paper worked into Peter's syntax. Peter's proposal only really has global constraints that modify the format of the response whereas Joan's includes substring matching, soundex matching etc but as part of the search string. While looking at them, and considering what to do about specifying the type of matching and the natural language to respond in, it would seem that there are two things wrong with the current syntax. 1. The current constraint values aren't really keywords (since you can only select one anyway) but they are really values of a "format" constraint. 2. Listing more than one constraint would be easier to parse and error check if there was a separator between each constraint. On the first issue I would suggest that rather than having the existing syntax of "one of four keywords" we change it to "format" "=" This allows us to easily add more formats later if required (maybe even an unformatted format :-) and would be consistant with "language" "=" , eg language = francais "match" "=" , eg match = soundex constraints. Also what sort of constraints are likely to be used on the "help", "show", and "list" commands? Aren't these more likely to be "global" type constraints and thus should be separated from the query by a colon rather than a comma? As an extension of this what about using the colon to separate the query and the constraints while using the comma a separator between constraints? I would then propose that the syntax be ::= | ::= ( [ ] [ ":" ] | "list" [ ] [ ":" ] | "show" [ ":" ] | "constraints" | "version" ) ::= "help" | "?" ::= { "," } ::= ( "format" "=" | "language" "=" | "match" "=" ... ) ::= "full" | "abridged" | "handle" | "summary" ::= { ";" } [ ":" ] ::= ( | "=" | | "=" ) [ ":" < constraints> ] etc. Mark. From ietf-wnils-request@ucdavis.ucdavis.edu Fri Mar 19 13:24:52 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28557; Fri, 19 Mar 93 13:13:27 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25161; Fri, 19 Mar 93 12:40:28 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27126; Fri, 19 Mar 93 12:31:39 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from mocha.bunyip.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26780; Fri, 19 Mar 93 12:22:13 -0800 Received: from [192.197.208.2] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19747 (mail destined for ietf-wnils@ucdavis.edu) on Fri, 19 Mar 93 15:20:17 -0500 Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0) id AA07186; Fri, 19 Mar 93 15:17:47 -0500 Message-Id: <9303192017.AA07186@expresso.bunyip.com> From: peterd@expresso.bunyip.com (/usr/spool/mail/peterd) Date: Fri, 19 Mar 1993 15:17:46 -0500 In-Reply-To: Mitra's message as of Mar 10, 4:10 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: mitra@pandora.sf.ca.us (Mitra), ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Multiple languages g'day all, I'm finally back from Interop (snowed in at Washington until Monday) and roughly caught up on my mail (although I've still anumber of messages to answer. If yours is one of them, bear with me). Now, here's a final pass on WHOIS-related postings. Mark, I'm coming up to yours next... [ Mitra wrote: ] > I'll change the subject line, so that Peter and others can argue about > the appropriateness of whois in another thread :-) That one seems to have gone away, or at least been punted until the bar in Columbus??? :-) > > I think multiple language support is a great idea but..... > > It looks more and more like you are going through the same process > that the Info-1 people are doing over in the Z39.50 group, and that > gopher is going through. Info-1 calls these things variants, Gopher > calls them views. I think both have got something that your proposal > lacks, i.e. a way to get at the required data without a bunch of > rejections from the server. I disagree with the premise that > client-cycles are cheap, multiple failed queries are a pain for the > user, and the server - even more so if they are going through any kind > of gateway imposing delays. Actually, I forsee us addressing this in a combination of ways. First, although I didn't make it clear enough, I had assumed that if we were adding optional components (such as security or multilingual support) we'd also add a corresponding "OPTIONS" system command. This would return either a list of supported options or the word "NONE". Thus, if you wished to use an optional feature, you would first send this to determine if it was possible. As for the basic query-response paradigm, I still maintain it can do a lot (witness the success of Gopher, which is built on exactly the same interaction mechanism). > In Gopher+ this is done with the directory listing where you get told > what the possible views are. In info-1 you can specify a preferred list > of variants, or ask the server to tell you what variants (e.g. > languages) are available. In other words, one interaction to determine the options and one to perform the query. Sorry I wasn't clear enough in the original proposal. > One simple way to get this would be to allow a construct of the form. > > LANGUAGE=ENGLISH,FRENCH > > meaning give me a result in English (first preference) or French. > > Alternatively > > LANGUAGE=ENGLISH,ANY > > would be English for preference, but failing this give me anything else. Although such a multiple specification would work, I personally prefer a two step negotiation model, since I think it makes both client and server easier to bring up and thus encourages experimentation. We could make such overloading an option, but I would prefer personally an OPTIONS command. Anybody else have a thought on this? > > - Mitra > > P.S. I havent tried to mould this into your form of query, cos I lost > track of whether you maintained the distinction between Language and > Charset. For example I can read French, but my terminal only handles > US-ASCII. Yes, I vote to maintain the distinction. This would allow, for example, the selection of language for help messages independently of the charset representation. They really are two different choices. - peterd -- From ietf-wnils-request@ucdavis.ucdavis.edu Tue Mar 23 01:10:12 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14491; Tue, 23 Mar 93 01:00:30 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23305; Tue, 23 Mar 93 00:39:45 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13519; Tue, 23 Mar 93 00:31:58 -0800 Sender: ietf-wnils-request@ucdavis.ucdavis.edu Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13180; Tue, 23 Mar 93 00:22:26 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26) id AA18790; Tue, 23 Mar 1993 17:50:43 +0930 Message-Id: <9303230820.AA18790@jarrah.itd.adelaide.edu.au> To: ietf-wnils@ucdavis.ucdavis.edu Subject: Re: Multiple languages In-Reply-To: Your message of "Fri, 19 Mar 1993 15:17:46 EST." <9303192017.AA07186@expresso.bunyip.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Mar 1993 17:50:42 +0930 From: Mark Prior Oh no, it looks like I'm going to have to agree with Peter on something, I better go have a little lie down :-) > One simple way to get this would be to allow a construct of the form. > > LANGUAGE=ENGLISH,FRENCH > > meaning give me a result in English (first preference) or French. > > Alternatively > > LANGUAGE=ENGLISH,ANY > > would be English for preference, but failing this give me anything else. Although such a multiple specification would work, I personally prefer a two step negotiation model, since I think it makes both client and server easier to bring up and thus encourages experimentation. We could make such overloading an option, but I would prefer personally an OPTIONS command. Anybody else have a thought on this? Seriously, I too would prefer a two step process. It is easy to say do a list if the user is only going to specify two choices but what if they are more than bilingual and could reasonably cope with a number of languages are you going to expect them to list them? A swiss might like to specify "language=german,french,italian" whereas if the server might only be able to accomodate mandarin, cantonese, korean, japanese,and english. In this case it would be better if the client program either A. 1. asked the server for german 2. on fail asked for a list of supported languages 3. query user if (s)he finds any language acceptable or B. 1. ask the server for the list 2. then queried user Mark. PS We need to determine which language is to be used to specify the language. That is if I want to ask for french do I specify a. "language=francais" b. "language=french" c. something else entirely, ISO codes perhaps