As per Relevance of the word standards, we have this rfc below:
Network Working Group P.
Request for Comments: 1914 Bunyip Information Systems, Inc
Category: Standards Track R.
C.
Bunyip Information Systems, Inc
February 1996
How to Interact with a Whois++
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1.
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal
done by the client, since each server 'refers' the client to the
appropriate server(s). The protocol is simple. The client opens
connection to a server, sends a query, receives a reply, closes
connection, and after parsing the response the client decides
server to contact next, if necessary
So, the client needs to have an algorithm to follow when it
with the Whois++ mesh so that referral loops can be detected, cost
minimised, and appropriate servers are rapidly and
contacted
Faltstrom, et al Standards Track [Page 1]
RFC 1914 How to Interact with a Whois++ Mesh February 1996
2. Basic
Each Whois++ client should be configured to automatically
queries to a specific Whois++ server. The deault Whois++ server
vary depending on which template is desired, and the location of
client with respect to the WHOIS++ index mesh, but as a rule
server should be as local as possible
/ \
B
/ \ \
Z -----> D E
/ \
G
Fig 1: The client Z is configured to first query server
After getting responses from a server, the client can act in
ways. If the number of hits is greater than zero, the response
just presented to the user. If the client gets one or many servers
to-ask answers, the client should be able to automatically
these pointers, i.e. query these servers in turn
/ \
B
/ \ \
Z <----- D E
\ / \
--> G
Fig 2: The client Z gets a "servers-to-ask G" response from D
therefore may automatically queries server G
3. How to navigate in the
A client can use several different strategies when traversing
navigating around in the mesh. The automatic way of doing this is
just "expand the search" (described in 3.1) and a second method is
use the "Directory of Servers" (described in 3.2).
3.1. Expansion of
If the number of hits is zero, or if the user in some way wants
expand the search, it is recommended for the client to issue
'polled-by' and 'polled-for' query to the server. The client can
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
/ \
/-----> B
/ / \ \
Z <----- D E
/ \
G
Fig 3: The client Z gets a "polled-by B" response from D and
queries server B
The client must always keep track of which servers it has
because it must itself detect loops in the mesh by not querying
same server more than once
/ \
/- B
/ / \ \
Z <---/ D E
/ \
G
Fig 4: The client Z gets a "servers-to-ask D" response from B but
does not query D because the server D has already been queried
So, the default expansion of a query by a client causes
more comprenhensive index servers to be queried; the
knowledge contained in the index server mesh allows rapid pruning
these larger trees
All loop detection and elimination is done in the client, rather
in the server mesh. This decision was made because loop detection
elimination are quite difficult to build into the mesh if we are
continue to allow each server to participate in multiple
within the mesh
3.1.1. Optimising the
If organization A tends to use organization B's WHOIS++
frequently, for example if A is cooperating in a project with B,
may wish to make B's server locally available by creating a
index server which retrieves the centroid for both organizations
When A's client then expands a query which is looking for someone
B, the client can much more rapidly resolve the query, as it does
have to find the top level servers for the tree to which A and B
belong
Faltstrom, et al Standards Track [Page 3]
RFC 1914 How to Interact with a Whois++ Mesh February 1996
/ \
B
/ \ \
Z D -->
/ \
G
Fig 5: The server B gets a centroid from server
/ \
B
/ \ \
Z <----> D ---
/ \
G
Fig 6: The client queries server D, gets zero hits back, expands
search and gets a "polled-by B" response back
/ \
/--> B
/ / \ \
Z <-/ D ---
/ \
G
Fig 7: The client Z queries server B and gets "servers-to-ask F
response back
/ \
B
/ \ \
D --- F <----->
/ \
G
Fig 8: The client Z queries server F and gets the answer
The example given in Fig 5-8 shows that the algorithm works
though the Whois++ mesh is not a tree. There are many reasons why
given index server mesh might be 'short-circuited'. For example,
the case of a multinational company, the Swedish branch of Acme Inc.,
is polled both by the national server in Sweden and the
server in the USA. By querying the Swedish server, one finds
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
the Acme Inc. server in the USA, you will find all employees in
company, including those in Sweden
Note that the location of a server does not implicitly narrow
search, i.e. you have to specify all information when sending a
to a server. In the example above, one can see that by just
a server for companies in the USA, you will not implicitly only
hits from records in the states, because the Acme Inc. server in
states has polled a server in Sweden. So, in this case you have
explicitly include "country=USA" in the query if you are
interested in those records
Although the WHOIS++ index service has been designed to make
at any location in the index mesh quite effective and efficient
blindly expanding the query can incur an exponentially growing
in resources, and, as charging for responses is implemented in
of the WHOIS++ index service mesh, growing cost, automatic
is not recommended. More sophisticated clients should also
configurable to "cut off" some servers from a search, i.e.
blacklist of servers. This might be needed when searching for
and one server might have a very high cost (in dollars) so one
want to explicitly forbid the client to send queries to that server
3.1.2. The algorithm used by the
By following this algorithm a client finds all records in a
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
A second way of finding the correct server to query is to use
separate service we call the Directory of Servers. The Directory
Servers is a special Whois++ server which polls every Whois++
for information about common information among the records on
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
templates in Sweden, should do it this way
1) The hostname and portnumber of the directory of Servers
to be preconfigured in the current version of the protocol
2) Query the Directory of Servers for serverhandle records
country sweden. This gives information of all these servers
By presenting this information to the user the user should
able to start the search at some closer server
Note that we at this moment doesn't think this should be an
process in the client. The Directory of Servers should be used
giving the user information about what Whois++ servers that exists
In the future a technique might have developed that makes it
for a client to do this selection automatically depending on
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
like
Admin-Name: Patrik
Admin-Email: paf@bunyip.
Admin-Phone: +1-514-875-8611
Organization-Name: Bunyip Information Systems Inc
Description: USER
Menu-Item: World (Bunyip Information Systems inc
City:
State:
Country:
:
:
(Other attributes that can identify all records on this server,
example domainname
The information in the Navigation record is intended to be
to a user
3.2.3.
An example of how an interaction with the Directory of Servers
done follows. The characters '<' and '>' displays if it is the
('<') 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
> % 200 Search is
> # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM01
> SERVER-HANDLE: BUNYIPCOM01
> HOST-NAME: services.bunyip.
> HOST-PORT: 63
> ADMIN-NAME: Patrik
> ADMIN-EMAIL: paf@bunyip.
> ORGANIZATION-NAME: Bunyip Information Systems Inc
> DESCRIPTION: USER
> DESCRIPTION: Directory of
> DESCRIPTION: Toplevel Index server in the
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:
> COUNTRY:
> #
> # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM02
> SERVER-HANDLE: BUNYIPCOM02
> HOST-NAME: services.bunyip.
> HOST-PORT: 7778
> ADMIN-NAME: Patrik
> ADMIN-EMAIL: paf@bunyip.
> ORGANIZATION-NAME: Bunyip Information Systems Inc
> DESCRIPTION: USER
> MENU-ITEM: Bunyip Information
> CITY:
> COUNTRY:
> #
> % 226 Transaction
> % 203 Bye,
4.
A client can cache all information it gets from a server for
time. For example records, IP-addresses of Whois++ servers,
Directory of Services server etc
A client can itself choose for how long it should cache
information
The IP-address of the Directory of Services server might not
for a day or two, and neither might any other information
4.1. Caching a Whois++ servers
An example of cached information that might change is the
hostname, IP-address and portnumber which a client gets back in
servers-to-ask response. That information is cached in the
since the last poll, which might occurred several weeks ago
Therefore, when such a connection fails, the client should fall
to use the serverhandle insted, which means that it contacts
Directory of Services server and queries for a server with
serverhandle. By doing this, the client should always get the
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
IP-address := find ip-address for response.hostname in
connect to ip-address at port response.
if connection fails {
connect to Directory of Services
query for host with serverhandle response.
response := response from Directory of Services
IP-address := find ip-address for response.hostname in
connect to ip-address at port response.
if connection fails {
exit with error
}
}
Query this new
5. Security
Security considerations when using the Whois++ protocol is
in [Deutsch94].
A client should be able to have a "blacklist" of servers it
not query, because it might happen that fake Whois++ servers is
up on the net. When such a fake Whois++ servers is found, a
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
using normal expansion or using the directory of servers. A
might take a long time, so a user should be able to quit in
middle of such a transaction. This is though more a question of
interaction than a plain security issue
6.
[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
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'
Patrik
BUNYIP INFORMATION SYSTEMS,
310 St Catherine St West, Suite 300
Montreal,
CANADA H2X 2A
EMail: paf@bunyip.
Rickard
KTHNOC, SUNET/NORDUnet/Ebone Operations
S-100 44
EMail: schoultz@sunet.
Chris
BUNYIP INFORMATION SYSTEMS,
310 St Catherine St West, Suite 300
Montreal,
CANADA H2X 2A
EMail: clw@bunyip.
Faltstrom, et al Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
