From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1913.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc1913.txt (limited to 'doc/rfc/rfc1913.txt') diff --git a/doc/rfc/rfc1913.txt b/doc/rfc/rfc1913.txt new file mode 100644 index 0000000..4775324 --- /dev/null +++ b/doc/rfc/rfc1913.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group C. Weider +Request for Comments: 1913 Bunyip +Category: Standards Track J. Fullton + CNIDR + S. Spero + EIT + February 1996 + + + Architecture of the Whois++ Index Service + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The authors describe an architecture for indexing in distributed + databases, and apply this to the WHOIS++ protocol. + +1. Purpose: + + The WHOIS++ directory service [Deutsch, et al, 1995] is intended to + provide a simple, extensible directory service predicated on a + template-based information model and a flexible query language. This + document describes a general architecture designed for indexing + distributed databases, and then applys that architecture 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 not feasible to + build a centralized directory to serve all this information. If we + are to distribute the directory service, the easiest (although not + + + +Weider, et al Standards Track [Page 1] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + + 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 + number of 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 + + One of the primary assumptions made by recent implementations of + distributed directory services is that every entry resides in some + location in a hierarchical name space. While this arrangement is + ideal for reading the entry once one knows its location, it is not as + good when one is searching for the location in the namespace of those + entries which meet some set of criteria. If the only criteria we know + about a desired entry are items which do not appear in the namespace, + we are forced to do a global query. Whenever we issue a global query + (at the root of the namespace), or a query at the top of a given + subtree in the namespace, that query is replicated to "all" subtrees + of the starting point. The replication of the query to all subtrees + is not necessarily a problem; queries are cheap. However, every + server to which the query has been replicated must process that + query, even if it has no entries which match the specified criteria. + This part of the global query processing is quite expensive. A poorly + designed namespace or a thin namespace can cause the vast majority of + queries to be replicated globally, but a very broad namespace can + cause its own navigation problems. Because of these problems, search + has been turned off at high levels of the X.500 namespace. + +3.2. The location problem + + With global search turned off, one must know in advance how the name + space is laid out so that one can guide a query to a proper location. + Also, the layout of the namespace then becomes critical to a user's + ability to find the desired information. Thus there are endless + battles about how to lay out the name space to best serve a given set + of users, and enormous headaches whenever it becomes apparent that + the current namespace is unsuited to the current usages and must be + changed (as recently happened in X.500). Also, assuming one does + impose multiple hierarchies on the entries through use of the + namespace, the mechanisms to maintain these multiple hierarchies in + X.500 do not exist yet, and it is possible to move entries out from + under their pointers. Also, there is as yet no agreement on how the + X.500 namespace should look even for the White Pages types of + information that is currently installed in the X.500 pilot project. + + + +Weider, et al Standards Track [Page 2] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + +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, the attributes + appropriate to the new directory must be built into the namespace + because that is the only way to segregate related entries into a + place where they can be found without a global search. Also, there is + a classification problem; how does one adequately specify the proper + categories so that people other than the creator of the directory can + find the correct subtree? Additionally, there is the problem of + actually finding the data to put into the subtree; if one must + traverse the hierarchy to find the data, we have to look globally for + the proper entries. + +3.4. Solutions + + The problems examined in this section can be addressed by a + combination of two new techniques: directory meshes and forward + knowledge. + +4. Directory meshes and forward knowledge + + We'll hold off for a moment on describing the actual architecture + used in our solution to these problems and concentrate on a high + level description of what solutions are provided by our conceptual + approach. To begin with, although every entry in WHOIS++ does indeed + have a unique identifier (resides in a specific location in the + namespace) the navigational algorithms to reach a specific entry do + not necessarily depend on the identifier the entry has been assigned. + The Index Service gets around the namespace and hierarchy problems by + creating a directory mesh on top of the entries. Each layer of the + mesh has a set of 'forward knowledge' which indicates the contents of + the various servers at the next lower layer of the mesh. Thus when a + query is received by a server in a given layer of the mesh, it can + prune the search tree and hand the query off to only those lower + level servers which have indicated that they might be able to answer + it. Thus search becomes feasible at all levels of the mesh. In the + current version of this architecture, we have chosen a certain set of + information to hand up the mesh as forward knowledge. This may or may + not be exactly the set of information required to construct a truly + searchable directory, but the protocol itself doesn't restrict the + types of information which can be handed around. + + In addition, the protocols designed to maintain the forward knowledge + will also work perfectly well to provide replication of servers for + + + +Weider, et al Standards Track [Page 3] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + + redundancy and robustness. In this case, the forward knowledge handed + around by the protocols is the entire database of entries held by the + replicated server. + + Another benefit provided by the mesh of index servers is that since + the entry identification scheme has been decoupled from the + navigation service, multiple hierarchies can be built and easily + maintained on top of the existing data. Also, the user does not need + to know in advance where in the mesh the entry is contained. + + Also, the Yellow Pages problem now becomes tractable, as the index + servers can pick and choose between information proffered by a given + server; because we have an architecture that allows for automatic + polling of data, special purpose directories become easy to construct + and to maintain. + +5. Components of the Index Service: + +5.1. WHOIS++ servers + + The whois++ service is described in [Deutsch, et al, 1995]. 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', or some other type of forward knowledge, for + the data it serves. + +5.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. + + A word is any token delimited by blank spaces, newlines, or the '@' + character, in the value of an attribute. + + 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 + + + + +Weider, et al Standards Track [Page 4] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + + 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. + +5.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. In addition, an + index server can index any other server it wishes, which allows one + base level server (or index server) to participate in many + hierarchies in the directory mesh. + +5.3.1. Queries to index servers + + An index server will take a query in standard whois++ format, search + its collections of centroids and other forward information, determine + which servers hold records which may fill that query, and then + notifies the user's client of the next servers to contact to submit + the query (referral in the X.500 model). An index server can also + contain primary data of its own; and thus act a both an index server + and a base level server. In this case, the index server's response to + + + +Weider, et al Standards Track [Page 5] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + + a query may be a mix of records and referral pointers. + +5.3.2. Index server distribution model and centroid propogation + + The diagram on the next page illustrates how a mesh of index servers + might be created for a set of whois++ servers. Although it looks like + a hierarchy, the protocols allow (for example) server A to be indexed + by both server D and by server H. + + whois++ index index + servers servers servers + for for + whois++ lower-level + servers index servers + _______ + | | + | A |__ + |_______| \ _______ + \----------| | + _______ | D |__ ______ + | | /----------|_______| \ | | + | B |__/ \----------| | + |_______| | F | + /----------|______| + / + _______ _______ / + | | | |- + | C |--------------| E | + |_______| |_______|- + \ + \ + _______ \ ______ + | | \----------| | + | G |--------------------------------------| H | + |_______| |______| + + Figure 1: Sample layout of the Index Service mesh + + 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. Servers E and G also hand their + centroids up to H. + + 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. + + + +Weider, et al Standards Track [Page 6] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + +5.3.3. Centroid propogation and changes to centroids + + Centroid propogation is initiated by an authenticated POLL command + (sec. 5.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. + 5.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. + +5.3.4. Centroid propogation and mesh traversal + + When an index server issues a POLL request, it may indicate to the + polled server what relationship it has to the polled. This + information can be used to help traverse the directory mesh. Two + fields are specified in the current proposal to transmit the + relationship information, although it is expected that richer + relationship information will be shared in future revisions of this + protocol. + + One field used for this information is the Hierarchy field, and can + take on three values. The first is 'topology', which indicates that + the indexing server is at a higher level in the network topology + (e.g. indexes the whole regional ISP). The second is 'geographical', + which indicates that the polling server covers a geographical area + subsuming the pollee. The third is 'administrative', which indicates + that the indexing server covers an administrative domain subsuming + the pollee. + + The second field used for this information is the Description field, + which contains the DESCRIBE record of the polling server. This allows + users to obtain richer metainformation for the directory mesh, + enabling them to expand queries more effectively. + +5.3.5. Query handling and passing algorithms + + 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++ + + + +Weider, et al Standards Track [Page 7] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + + 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. + +5.3.5.1. Query referral + + Query referral is the process of informing a client which servers to + contact next to resolve a query. The syntax for notifying a client + is outlined in section 5.5. + +5.3.6 Loop control + + Since there are no a priori restrictions on which servers may poll + which other servers, and since a given server may participate in many + sub-meshes, mechanisms must be installed to allow the detection of + cycles in the polling relationships. This is accomplished in the + current protocol by including a hop-count on polling relationships. + Each time a polled server generates forward information, it informs + the polling server about its current hopcount, which is the maximum + of the hopcounts of all the servers it polls, plus 1. A base level + server (one which polls no other servers) will have a hopcount of 0. + When a server decides to poll a new server, if its hopcount goes up, + then it must information all the other servers which poll it about + its new hopcount. A maximum hopcount (8 in the current version) will + help the servers detect polling loops. + + A second approach to loop detection is to do all the work in the + client; which would determine which new referrals have already + appeared in the referral list, and then simply iterate the referral + process until there are no new servers to ask. An algorithm to + accomplish this in WHOIS++ is detailed in [Faltstrom 95]. + +6. Syntax for operations of the Index Service: + + The syntax for each protocol componenet is listed below. In addition, + each section contains a listing of which of these attributes is + required and optional for each of the componenet. All timestamps must + be in the format YYYYMMDDHHMM and in GMT. + +6.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. Current value is 1.0 + Time-of-latest-centroid-change: // time stamp of latest centroid + + + +Weider, et al Standards Track [Page 8] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + + // change, GMT + Time-of-message-generation: // time when this message was generated, + // GMT + Server-handle: // IANA unique identifier for this server + Host-Name: // Host name of this server (current name) + Host-Port: // Port number of this server (current port) + 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 // This line must be used to terminate the data changed + // message + +Required/optional table + +Version-Number REQUIRED +Time-of-latest-centroid-change REQUIRED +Time-of-message-generation REQUIRED +Server-handle REQUIRED +Host-Name REQUIRED +Host-Port REQUIRED +Best-time-to-poll OPTIONAL +Authentication-type OPTIONAL +Authentication-data OPTIONAL + +6.2. Polling syntax + +# POLL: + Version-number: // version number of poller's index software, used to + // insure compatibility + Type-of-poll: // type of forward data requested. CENTROID or QUERY + // are the only one currently defined + Poll-scope: // Selects bounds within which data will be returned. + // See note. + 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 + Host-Name: // Host name of the polling server. + + + +Weider, et al Standards Track [Page 9] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + + Host-Port: // Port number of the polling server. + Hierarchy: // This field indicates the relationship which the poller + // bears to the pollee. Typical values might include + // 'Topology', 'Geographical", or "Administrative" + Description: // This field contains the DESCRIBE record of the + // polling server + Authentication-type: // Type of authentication used by poller, or NONE + Authentication-data: // Data for authentication +# END // This line must by used to terminate the poll message + + Note: For poll type CENTROID, the allowable values for Poll Scope are + FULL and RELATIVE. Support of the FULL value is required, this + provides a complete listing of the centroid or other forward + information. RELATIVE indicates that these are the relative changes + in the centroid since the last report to the polling server. + + For poll type QUERY, the allowable values for Poll Scope are a blank + line, which indicates that all records are to be returned, or a valid + WHOIS++ query, which indicates that just those records which satisfy + the query are to be returned. N.B. Security considerations may + require additional authentication for successful response to the + Blank Line Poll Scope. This value has been included for server + replication. + + A polling server may wish to index different types of information + than the polled server has collected. The POLLED-FOR command will + indicate which servers the polled server has contacted. + +Required/Optional Table + +Version-Number REQUIRED, value is 1.0 +Type-Of-Poll REQUIRED, values CENTROID and QUERY are required +Poll-scope REQUIRED If Type-of-poll is CENTROID, FULL is required, + RELATIVE is optional + If Type-of-poll is QUERY, Blank line is + required, and WHOIS++-type queries are + required +Start-time OPTIONAL +End-Time OPTIONAL +Template REQUIRED +Field REQUIRED +Server-handle REQUIRED +Host-Name REQUIRED +Host-Port REQUIRED +Hierarchy OPTIONAL +Description OPTIONAL +Authentication-Type: OPTIONAL +Authentication-data: OPTIONAL + + + +Weider, et al Standards Track [Page 10] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + +Example of a POLL command: +# POLL: + Version-number: 1.0 + Type-of-poll: CENTROID + Poll-scope: FULL + Start-time: 199501281030+0100 + Template: ALL + Field: ALL + Server-handle: BUNYIP01 + Host-Name: services.bunyip.com + Host-Port: 7070 + Hierarchy: Geographical + # END + +6.3. Centroid change report + + As the centroid change report contains nested multiply-occuring + blocks, each multiply occurring block is surrounded *in this paper* + by curly braces '{', '}'. These curly braces are NOT part of the + syntax, they are for identification purposes only. + + The syntax of a Data: item is either a list of words, one word per + line, or the keyword: + + ANY + + The keyword ANY as the only item of a Data: list means that any value + for this field should be treated as a hit by the indexing server. + + The field Any-field: needs more explanation than can be given in the + body of the syntax description below. It can take two values, True or + False. If the value is True, the pollee is indicating that there are + fields in this template which are not being exported to the polling + server, but wishes to treat as a hit. Thus, when the polling server + gets a query which has a term requesting a field not in this list for + this template, the polling server will treat that term as a 'hit'. + If the value is False, the pollee is indicating that there are no + other fields for this template which should be treated as a hit. This + field is required because the basic model for the WHOIS++ query + syntax requires that the results of each search term be 'and'ed + together. This field allows polled servers to export data only for + non-sensitive fields, yet still get referrals of queries which + contain sensitive terms. + + IMPORTANT: The data listed in the centroid must be in the ISO-8859-1 + character set in this version of the indexing protocol. Use of any + other character set is a violation of the protocol. Note that the + base-level server is also specified to use ISO-8859-1 [Deutsch, et + + + +Weider, et al Standards Track [Page 11] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + + al, 1995]. + +# 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 + Case-sensitive: // states whether data is case sensitive or case + // insensitive. values are TRUE or FALSE + 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 +{ // The multiply occurring template block starts here +# BEGIN TEMPLATE + Template: // a standard whois++ template name + Any-field: // TRUE or FALSE. See beginning of 6.3 for explanation. + { // the template contains multiple field blocks +# BEGIN FIELD + Field: // a field name within that template + Data: // Either the keyword *ANY*, or + // the word list itself, one per line, cr/lf terminated, + // each line starting with a dash character ('-'). +# END FIELD + } // the field ends with END FIELD +# END TEMPLATE +} // the template block ends with END TEMPLATE +# END CENTROID-CHANGES // This line must be used to terminate the + // centroid change report + + For each template, all fields must be listed, or queries will not be + referred correctly. + +Required/Optional table + +Version-number REQUIRED, value is 1.0 +Start-time REQUIRED (even if the centroid type is FULL) +End-time REQUIRED (even if the centroid type is FULL) +Server-handle REQUIRED +Case-Sensitive OPTIONAL +Authentication-Type OPTIONAL + + + +Weider, et al Standards Track [Page 12] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + +Authentication-Data OPTIONAL +Compression-type OPTIONAL +Size-of-compressed-data OPTIONAL (even if compression is used) +Operation OPTIONAL, if used, upport for all three values is required +Tokenization-type OPTIONAL +#BEGIN TEMPLATE REQUIRED +Template REQUIRED +Any-field REQUIRED +#BEGIN FIELD REQUIRED +Field REQUIRED +Data REQUIRED +#END FIELD REQUIRED +#END TEMPLATE REQUIRED +#END CENTROID-CHANGES REQUIRED + +Example: + +# CENTROID-CHANGES + Version-number: 1.0 + Start-time: 197001010000 + End-time: 199503012336 + Server-handle: BUNYIP01 +# BEGIN TEMPLATE + Template: USER + Any-field: TRUE +# BEGIN FIELD + Field: Name + Data: Patrik +-Faltstrom +-Malin +-Linnerborg +#END FIELD +#BEGIN FIELD + Field: Email + Data: paf@bunyip.com +-malin.linnerborg@paf.se +# END FIELD +# END TEMPLATE +# END CENTROID-CHANGES + +6.4 QUERY and POLLEES responses + + The response to a QUERY command is done in WHOIS++ format. + + + + + + + + +Weider, et al Standards Track [Page 13] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + +6.5. Query referral + + When referrals are included in the body of a response to a query, + each referral is listed in a separate SERVER-TO-ASK block as shown + below. + +# SERVER-TO-ASK + Version-number: // version number of index software, used to insure + // compatibility + Body-of-Query: // the original query goes here + Server-Handle: // WHOIS++ handle of the referred server + Host-Name: // DNS name or IP address of the referred server + Port-Number: // Port number to which to connect, if different from the + // WHOIS++ port number + +# END + +Required/Optional table + +Version-number REQUIRED, value should be 1.0 +Body-of-query OPTIONAL +Server-Handle REQUIRED +Host-Name REQUIRED +Port-Number OPTIONAL, must be used if different from port 63 + +Example: + +# SERVER-TO-ASK + Version-Number: 1.0 + Server-Handle: SUNETSE01 + Host-Name: sunic.sunet.se + Port-Number: 63 +# END + +7: Reply Codes + + In addition to the reply codes listed in [Deutsch 95] for the basic + WHOIS++ client/server interaction, the following reply codes are used + in version 1.0 of this protocol. + +113 Requested method not available Unable to provide a requested + compression method. Contacted + server will send requested + data in different format. + +227 Update request acknowledged A DATA-CHANGED transmission + has been accepted and logged + for further action. + + + +Weider, et al Standards Track [Page 14] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + +503 Required attribute missing A REQUIRED attribute is + missing in an interaction. + +504 Desired server unreachable The desired server is + unreachable. + +505 Desired server unavailable The desired server fails to + respond to requests, but host + is still reachable. + +8. References + +[Deutsch 95] Deutsch, et al., "Architecture of the WHOIS++ service", + RFC 1835, August 1995. + + +[Faltstrom 95] Faltstrom, P., et al., "How to Interact with a WHOIS++ + Mesh, RFC 1914, February 1996. + +9. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weider, et al Standards Track [Page 15] + +RFC 1913 Architecture of the Whois++ Index Service February 1996 + + +10. Authors' Addresses + + Chris Weider + Bunyip Information Systems, Inc. + 310 St. Catherine St. West + Montreal, PQ H2X 2A1 + CANADA + + Phone: +1-514-875-8611 + Fax: +1-514-875-6134 + EMail: clw@bunyip.com + + + Jim Fullton + MCNC Center for Communications + Post Office Box 12889 + 3021 Cornwallis Road + Research Triangle Park + North Carolina 27709-2889 + + Phone: 410-795-5422 + Fax: 410-795-5422 + EMail: fullton@cnidr.org + + + Simon Spero + EMail: ses@eit.com + + + + + + + + + + + + + + + + + + + + + + + + +Weider, et al Standards Track [Page 16] + -- cgit v1.2.3