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/rfc1914.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc1914.txt (limited to 'doc/rfc/rfc1914.txt') 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] + -- cgit v1.2.3