summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1914.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1914.txt')
-rw-r--r--doc/rfc/rfc1914.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc1914.txt b/doc/rfc/rfc1914.txt
new file mode 100644
index 0000000..aa49f09
--- /dev/null
+++ b/doc/rfc/rfc1914.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group P. Faltstrom
+Request for Comments: 1914 Bunyip Information Systems, Inc.
+Category: Standards Track R. Schoultz
+ KTHNOC
+ C. Weider
+ Bunyip Information Systems, Inc.
+ February 1996
+
+
+ How to Interact with a Whois++ Mesh
+
+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.
+
+1. Overview
+
+ In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is
+ done by the client, since each server 'refers' the client to the next
+ appropriate server(s). The protocol is simple. The client opens a
+ connection to a server, sends a query, receives a reply, closes the
+ connection, and after parsing the response the client decides which
+ server to contact next, if necessary.
+
+ So, the client needs to have an algorithm to follow when it interacts
+ with the Whois++ mesh so that referral loops can be detected, cost is
+ minimised, and appropriate servers are rapidly and effectively
+ contacted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al Standards Track [Page 1]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+2. Basic functionality
+
+ Each Whois++ client should be configured to automatically send
+ queries to a specific Whois++ server. The deault Whois++ server can
+ vary depending on which template is desired, and the location of the
+ client with respect to the WHOIS++ index mesh, but as a rule the
+ server should be as local as possible.
+
+ A
+ / \
+ B C
+ / \ \
+ Z -----> D E F
+ / \
+ G H
+
+ Fig 1: The client Z is configured to first query server D
+
+ After getting responses from a server, the client can act in several
+ ways. If the number of hits is greater than zero, the response is
+ just presented to the user. If the client gets one or many servers-
+ to-ask answers, the client should be able to automatically resolve
+ these pointers, i.e. query these servers in turn.
+
+ A
+ / \
+ B C
+ / \ \
+ Z <----- D E F
+ \ / \
+ --> G H
+
+ Fig 2: The client Z gets a "servers-to-ask G" response from D and
+ therefore may automatically queries server G.
+
+3. How to navigate in the mesh
+
+ A client can use several different strategies when traversing or
+ navigating around in the mesh. The automatic way of doing this is to
+ just "expand the search" (described in 3.1) and a second method is to
+ use the "Directory of Servers" (described in 3.2).
+
+3.1. Expansion of searches
+
+ If the number of hits is zero, or if the user in some way wants to
+ expand the search, it is recommended for the client to issue a
+ 'polled-by' and 'polled-for' query to the server. The client can then
+ repeat the original query to the new servers indicated.
+
+
+
+Faltstrom, et al Standards Track [Page 2]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+ A
+ / \
+ /-----> B C
+ / / \ \
+ Z <----- D E F
+ / \
+ G H
+
+ Fig 3: The client Z gets a "polled-by B" response from D and therefore
+ queries server B.
+
+ The client must always keep track of which servers it has queried
+ because it must itself detect loops in the mesh by not querying the
+ same server more than once.
+
+ A
+ / \
+ /- B C
+ / / \ \
+ Z <---/ D E F
+ / \
+ G H
+
+ Fig 4: The client Z gets a "servers-to-ask D" response from B but Z
+ does not query D because the server D has already been queried.
+
+ So, the default expansion of a query by a client causes increasingly
+ more comprenhensive index servers to be queried; the forward
+ knowledge contained in the index server mesh allows rapid pruning of
+ these larger trees.
+
+ All loop detection and elimination is done in the client, rather than
+ in the server mesh. This decision was made because loop detection and
+ elimination are quite difficult to build into the mesh if we are to
+ continue to allow each server to participate in multiple hierarchies
+ within the mesh.
+
+3.1.1. Optimising the mesh
+
+ If organization A tends to use organization B's WHOIS++ server
+ frequently, for example if A is cooperating in a project with B, A
+ may wish to make B's server locally available by creating a local
+ index server which retrieves the centroid for both organizations.
+ When A's client then expands a query which is looking for someone at
+ B, the client can much more rapidly resolve the query, as it does not
+ have to find the top level servers for the tree to which A and B both
+ belong.
+
+
+
+
+Faltstrom, et al Standards Track [Page 3]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+ A
+ / \
+ B C
+ / \ \
+ Z D --> F
+ / \
+ G H
+
+ Fig 5: The server B gets a centroid from server F
+
+ A
+ / \
+ B C
+ / \ \
+ Z <----> D --- F
+ / \
+ G H
+
+ Fig 6: The client queries server D, gets zero hits back, expands the
+ search and gets a "polled-by B" response back.
+
+ A
+ / \
+ /--> B C
+ / / \ \
+ Z <-/ D --- F
+ / \
+ G H
+
+ Fig 7: The client Z queries server B and gets "servers-to-ask F"
+ response back.
+
+ A
+ / \
+ B C
+ / \ \
+ D --- F <-----> Z
+ / \
+ G H
+
+ Fig 8: The client Z queries server F and gets the answer.
+
+ The example given in Fig 5-8 shows that the algorithm works even
+ though the Whois++ mesh is not a tree. There are many reasons why a
+ given index server mesh might be 'short-circuited'. For example, in
+ the case of a multinational company, the Swedish branch of Acme Inc.,
+ is polled both by the national server in Sweden and the headquarters
+ server in the USA. By querying the Swedish server, one finds all
+
+
+
+Faltstrom, et al Standards Track [Page 4]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+ persons working at the Swedish branch of Acme Inc., but by querying
+ the Acme Inc. server in the USA, you will find all employees in the
+ company, including those in Sweden.
+
+ Note that the location of a server does not implicitly narrow the
+ search, i.e. you have to specify all information when sending a query
+ to a server. In the example above, one can see that by just querying
+ a server for companies in the USA, you will not implicitly only get
+ hits from records in the states, because the Acme Inc. server in the
+ states has polled a server in Sweden. So, in this case you have to
+ explicitly include "country=USA" in the query if you are only
+ interested in those records.
+
+ Although the WHOIS++ index service has been designed to make searches
+ at any location in the index mesh quite effective and efficient,
+ blindly expanding the query can incur an exponentially growing cost
+ in resources, and, as charging for responses is implemented in parts
+ of the WHOIS++ index service mesh, growing cost, automatic expansion
+ is not recommended. More sophisticated clients should also be
+ configurable to "cut off" some servers from a search, i.e. a
+ blacklist of servers. This might be needed when searching for records
+ and one server might have a very high cost (in dollars) so one might
+ want to explicitly forbid the client to send queries to that server.
+
+3.1.2. The algorithm used by the client
+
+ By following this algorithm a client finds all records in a mesh
+ which the first Whois++ server queried belongs to.
+
+ The algorithm for the client follows:
+
+ Query := data to search for;
+ QueriedServers := {};
+ AnswerList := {};
+ OriginalServers := { known servers to this client };
+ while OriginalServers is not empty do:
+ ServerList = OriginalServers;
+ while ServerList is not empty do:
+ Server := ServerList[1];
+ if Server is not in QueriedServers then do:
+ send Query to Server;
+ Answer := answer from Server;
+ append ServersToAsk to ServerList;
+ remove Server from ServerList;
+ append Answers to AnswerList;
+ end;
+ done;
+ if query should be expanded then do:
+
+
+
+Faltstrom, et al Standards Track [Page 5]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+ ServerList := OriginalServers;
+ OriginalServers := {};
+ while ServerList is not empty do:
+ Server := ServerList[1];
+ send Polled-For-Query to Server;
+ Answer := answer from Server;
+ append Answer to OriginalServers;
+ remove Server from ServerList;
+ end;
+ done;
+ done;
+ display AnswerList to user;
+
+3.2. The Directory of Servers
+
+ A second way of finding the correct server to query is to use a
+ separate service we call the Directory of Servers. The Directory of
+ Servers is a special Whois++ server which polls every Whois++ server
+ for information about common information among the records on that
+ perticular server.
+
+3.2.1. How should a client use the Directory of Servers?
+
+ A client that want to very quickly find what servers serves USER
+ templates in Sweden, should do it this way:
+
+ 1) The hostname and portnumber of the directory of Servers have
+ to be preconfigured in the current version of the protocol.
+
+ 2) Query the Directory of Servers for serverhandle records for
+ country sweden. This gives information of all these servers.
+ By presenting this information to the user the user should be
+ able to start the search at some closer server.
+
+ Note that we at this moment doesn't think this should be an autmatic
+ process in the client. The Directory of Servers should be used for
+ giving the user information about what Whois++ servers that exists.
+
+ In the future a technique might have developed that makes it possible
+ for a client to do this selection automatically depending on the
+ query the user issues.
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al Standards Track [Page 6]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+3.2.2. What does the serverhandle record look like?
+
+ The attributes that must be in all serverhandle records are:
+
+ Server-Handle: The handle for this server.
+ Host-Name: The (current) hostname of this server.
+ Host-Port: The (current) portnumber for this server.
+
+ Part from that information, the record can include other attributes
+ like:
+
+ Admin-Name: Patrik Faltstrom
+ Admin-Email: paf@bunyip.com
+ Admin-Phone: +1-514-875-8611
+ Organization-Name: Bunyip Information Systems Inc.
+ Description: USER information
+ Menu-Item: World (Bunyip Information Systems inc)
+ City: Montreal
+ State: Quebec
+ Country: Canada
+ :
+ :
+ (Other attributes that can identify all records on this server, for
+ example domainname)
+
+ The information in the Navigation record is intended to be presented
+ to a user.
+
+3.2.3. Example
+
+ An example of how an interaction with the Directory of Servers is
+ done follows. The characters '<' and '>' displays if it is the client
+ ('<') or responding server ('>') which is responsible for the output:
+
+> % 220-This is services.bunyip.com running Bunyip-Whois++: DIGGER 1.0.5
+> % 220 Ready to go!
+< template=serverhandle and bunyip
+> % 200 Search is executing
+> # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM01
+> SERVER-HANDLE: BUNYIPCOM01
+> HOST-NAME: services.bunyip.com
+> HOST-PORT: 63
+> ADMIN-NAME: Patrik Faltstrom
+> ADMIN-EMAIL: paf@bunyip.com
+> ORGANIZATION-NAME: Bunyip Information Systems Inc.
+> DESCRIPTION: USER information
+> DESCRIPTION: Directory of Servers
+> DESCRIPTION: Toplevel Index server in the world
+
+
+
+Faltstrom, et al Standards Track [Page 7]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+> MENU-ITEM: World (Bunyip Information Systems inc)
+> CITY: Montreal
+> COUNTRY: Canada
+> # END
+>
+> # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM02
+> SERVER-HANDLE: BUNYIPCOM02
+> HOST-NAME: services.bunyip.com
+> HOST-PORT: 7778
+> ADMIN-NAME: Patrik Faltstrom
+> ADMIN-EMAIL: paf@bunyip.com
+> ORGANIZATION-NAME: Bunyip Information Systems Inc.
+> DESCRIPTION: USER information
+> MENU-ITEM: Bunyip Information Systems
+> CITY: Montreal
+> COUNTRY: Canada
+> # END
+>
+> % 226 Transaction complete
+> % 203 Bye, bye
+
+4. Caching
+
+ A client can cache all information it gets from a server for some
+ time. For example records, IP-addresses of Whois++ servers, the
+ Directory of Services server etc.
+
+ A client can itself choose for how long it should cache the
+ information.
+
+ The IP-address of the Directory of Services server might not change
+ for a day or two, and neither might any other information.
+
+4.1. Caching a Whois++ servers hostname
+
+ An example of cached information that might change is the chached
+ hostname, IP-address and portnumber which a client gets back in a
+ servers-to-ask response. That information is cached in the server
+ since the last poll, which might occurred several weeks ago.
+ Therefore, when such a connection fails, the client should fall back
+ to use the serverhandle insted, which means that it contacts the
+ Directory of Services server and queries for a server with that
+ serverhandle. By doing this, the client should always get the last
+ known hostname.
+
+
+
+
+
+
+
+Faltstrom, et al Standards Track [Page 8]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+ An algorithm for this might be:
+
+ response := servers-to-ask response from server A
+ IP-address := find ip-address for response.hostname in DNS
+ connect to ip-address at port response.portnumber
+ if connection fails {
+ connect to Directory of Services server
+ query for host with serverhandle response.serverhandle
+ response := response from Directory of Services server
+ IP-address := find ip-address for response.hostname in DNS
+ connect to ip-address at port response.portnumber
+ if connection fails {
+ exit with error message
+ }
+ }
+ Query this new server
+
+5. Security Considerations
+
+ Security considerations when using the Whois++ protocol is described
+ in [Deutsch94].
+
+ A client should be able to have a "blacklist" of servers it should
+ not query, because it might happen that fake Whois++ servers is put
+ up on the net. When such a fake Whois++ servers is found, a user
+ should be able to configure it's client to never query this server.
+
+ Note that a client should be careful when expanding a query by either
+ using normal expansion or using the directory of servers. A query
+ might take a long time, so a user should be able to quit in the
+ middle of such a transaction. This is though more a question of user
+ interaction than a plain security issue.
+
+6. References
+
+ [Deutsch94] Deutsch P., Schoultz R., Faltstrom P., and C. Weider,
+ "Architecture of the Whois++ service", RFC 1835,
+ August 1995.
+
+ [Weider94] Weider C., Fullton J., and S. Spero, "Architecture of
+ the WHOIS++ Index Service", RFC 1913, February 1996.
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al Standards Track [Page 9]
+
+RFC 1914 How to Interact with a Whois++ Mesh February 1996
+
+
+7. Authors' Addresses
+
+ Patrik Faltstrom
+ BUNYIP INFORMATION SYSTEMS, inc
+ 310 St Catherine St West, Suite 300
+ Montreal, Quebec
+ CANADA H2X 2A1
+
+ EMail: paf@bunyip.com
+
+
+ Rickard Schoultz
+ KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
+ S-100 44 STOCKHOLM
+ SWEDEN
+
+ EMail: schoultz@sunet.se
+
+
+ Chris Weider
+ BUNYIP INFORMATION SYSTEMS, inc
+ 310 St Catherine St West, Suite 300
+ Montreal, Quebec
+ CANADA H2X 2A1
+
+ EMail: clw@bunyip.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al Standards Track [Page 10]
+