home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1914 < prev    next >
Text File  |  1996-02-16  |  18KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       P. Faltstrom
  8. Request for Comments: 1914              Bunyip Information Systems, Inc.
  9. Category: Standards Track                                    R. Schoultz
  10.                                                                   KTHNOC
  11.                                                                C. Weider
  12.                                         Bunyip Information Systems, Inc.
  13.                                                            February 1996
  14.  
  15.  
  16.                   How to Interact with a Whois++ Mesh
  17.  
  18. Status of this Memo
  19.  
  20.    This document specifies an Internet standards track protocol for the
  21.    Internet community, and requests discussion and suggestions for
  22.    improvements.  Please refer to the current edition of the "Internet
  23.    Official Protocol Standards" (STD 1) for the standardization state
  24.    and status of this protocol.  Distribution of this memo is unlimited.
  25.  
  26. 1. Overview
  27.  
  28.    In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is
  29.    done by the client, since each server 'refers' the client to the next
  30.    appropriate server(s). The protocol is simple. The client opens a
  31.    connection to a  server, sends a query, receives a reply, closes the
  32.    connection, and after parsing the  response the client decides which
  33.    server to contact next, if necessary.
  34.  
  35.    So, the client needs to have an algorithm to follow when it interacts
  36.    with the Whois++ mesh so that referral loops can be detected, cost is
  37.    minimised, and appropriate servers are rapidly and effectively
  38.    contacted.
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Faltstrom, et al            Standards Track                     [Page 1]
  59.  
  60. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  61.  
  62.  
  63. 2. Basic functionality
  64.  
  65.    Each Whois++ client should be configured to automatically send
  66.    queries to a specific Whois++ server. The deault Whois++ server can
  67.    vary depending on which template is desired, and the location of the
  68.    client with respect to the WHOIS++ index mesh,  but as a rule the
  69.    server should be as local as possible.
  70.  
  71.                         A
  72.                        / \
  73.                       B   C
  74.                      / \   \
  75.            Z -----> D   E   F
  76.                    / \
  77.                   G   H
  78.  
  79.        Fig 1: The client Z is configured to first query server D
  80.  
  81.    After getting responses from a server, the client can act in several
  82.    ways. If the number of hits is greater than zero, the response is
  83.    just presented to the user. If the client gets one or many servers-
  84.    to-ask answers, the client should be able to automatically resolve
  85.    these pointers, i.e. query these servers in turn.
  86.  
  87.                         A
  88.                        / \
  89.                       B   C
  90.                      / \   \
  91.            Z <----- D   E   F
  92.              \     / \
  93.               --> G   H
  94.  
  95.    Fig 2: The client Z gets a "servers-to-ask G" response from D and
  96.              therefore may automatically queries server G.
  97.  
  98. 3. How to navigate in the mesh
  99.  
  100.    A client can use several different strategies when traversing or
  101.    navigating around in the mesh. The automatic way of doing this is to
  102.    just "expand the search" (described in 3.1) and a second method is to
  103.    use the "Directory of Servers" (described in 3.2).
  104.  
  105. 3.1. Expansion of searches
  106.  
  107.    If the number of hits is zero, or if the user in some way wants to
  108.    expand the search, it is recommended for the client to issue a
  109.    'polled-by' and 'polled-for' query to the server. The client can then
  110.    repeat the original query to the new servers indicated.
  111.  
  112.  
  113.  
  114. Faltstrom, et al            Standards Track                     [Page 2]
  115.  
  116. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  117.  
  118.  
  119.                         A
  120.                        / \
  121.               /-----> B   C
  122.              /       / \   \
  123.            Z <----- D   E   F
  124.                    / \
  125.                   G   H
  126.  
  127.  Fig 3: The client Z gets a "polled-by B" response from D and therefore
  128.                            queries server B.
  129.  
  130.    The client must always keep track of which servers it has queried
  131.    because it must itself detect loops in the mesh by not querying the
  132.    same server more than once.
  133.  
  134.                         A
  135.                        / \
  136.                    /- B   C
  137.                   /  / \   \
  138.            Z <---/  D   E   F
  139.                    / \
  140.                   G   H
  141.  
  142.   Fig 4: The client Z gets a "servers-to-ask D" response from B but Z
  143.     does not query D because the server D has already been queried.
  144.  
  145.    So, the default expansion of a query by a client causes increasingly
  146.    more comprenhensive index servers to be queried; the forward
  147.    knowledge contained in the index server mesh allows rapid pruning of
  148.    these larger trees.
  149.  
  150.    All loop detection and elimination is done in the client, rather than
  151.    in the server mesh. This decision was made because loop detection and
  152.    elimination are quite difficult to build into the mesh if we are to
  153.    continue to allow each server to participate in multiple hierarchies
  154.    within the mesh.
  155.  
  156. 3.1.1. Optimising the mesh
  157.  
  158.    If organization A tends to use organization B's WHOIS++ server
  159.    frequently, for example if A is cooperating in a project with B, A
  160.    may wish to make B's server locally available by creating a local
  161.    index server which retrieves the centroid for both organizations.
  162.    When A's client then expands a query which is looking for someone at
  163.    B, the client can much more rapidly resolve the query, as it does not
  164.    have to find the top level servers for the tree to which A and B both
  165.    belong.
  166.  
  167.  
  168.  
  169.  
  170. Faltstrom, et al            Standards Track                     [Page 3]
  171.  
  172. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  173.  
  174.  
  175.                         A
  176.                        / \
  177.                       B   C
  178.                      / \   \
  179.            Z        D   --> F
  180.                    / \
  181.                   G   H
  182.  
  183.            Fig 5: The server B gets a centroid from server F
  184.  
  185.                         A
  186.                        / \
  187.                       B   C
  188.                      / \   \
  189.            Z <----> D   --- F
  190.                    / \
  191.                   G   H
  192.  
  193.   Fig 6: The client queries server D, gets zero hits back, expands the
  194.              search and gets a "polled-by B" response back.
  195.  
  196.                         A
  197.                        / \
  198.                  /--> B   C
  199.                 /    / \   \
  200.            Z <-/    D   --- F
  201.                    / \
  202.                   G   H
  203.  
  204.     Fig 7: The client Z queries server B and gets "servers-to-ask F"
  205.                              response back.
  206.  
  207.                         A
  208.                        / \
  209.                       B   C
  210.                      / \   \
  211.                     D   --- F <-----> Z
  212.                    / \
  213.                   G   H
  214.  
  215.        Fig 8: The client Z queries server F and gets the answer.
  216.  
  217.    The example given in Fig 5-8 shows that the algorithm works even
  218.    though the Whois++ mesh is not a tree. There are many reasons why a
  219.    given index server mesh might be 'short-circuited'. For example, in
  220.    the case of a multinational company, the Swedish branch of Acme Inc.,
  221.    is polled both by the national server in Sweden and the headquarters
  222.    server in the USA. By querying the Swedish server, one finds all
  223.  
  224.  
  225.  
  226. Faltstrom, et al            Standards Track                     [Page 4]
  227.  
  228. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  229.  
  230.  
  231.    persons working at the Swedish branch of Acme Inc., but by querying
  232.    the Acme Inc.  server in the USA, you will find all employees in the
  233.    company, including those in Sweden.
  234.  
  235.    Note that the location of a server does not implicitly narrow the
  236.    search, i.e. you have to specify all information when sending a query
  237.    to a server. In the example above, one can see that by just querying
  238.    a server for companies in the USA, you will not implicitly only get
  239.    hits from records in the states, because the Acme Inc. server in the
  240.    states has polled a server in Sweden. So, in this case you have to
  241.    explicitly include "country=USA" in the query if you are only
  242.    interested in those records.
  243.  
  244.    Although the WHOIS++ index service has been designed to make searches
  245.    at any location in the index mesh quite effective and efficient,
  246.    blindly expanding the query can incur an exponentially growing cost
  247.    in resources, and, as charging for responses is implemented in parts
  248.    of the WHOIS++ index service mesh, growing cost, automatic expansion
  249.    is not recommended. More sophisticated clients  should also be
  250.    configurable to "cut off" some servers from a search, i.e. a
  251.    blacklist of servers. This might be needed when searching for records
  252.    and one server might have a very high cost (in dollars) so one might
  253.    want to explicitly forbid the client to send queries to that server.
  254.  
  255. 3.1.2. The algorithm used by the client
  256.  
  257.    By following this algorithm a client finds all records in a mesh
  258.    which the first Whois++ server queried belongs to.
  259.  
  260.    The algorithm for the client follows:
  261.  
  262.       Query := data to search for;
  263.       QueriedServers := {};
  264.       AnswerList := {};
  265.       OriginalServers := { known servers to this client };
  266.       while OriginalServers is not empty do:
  267.             ServerList = OriginalServers;
  268.             while ServerList is not empty do:
  269.                   Server := ServerList[1];
  270.                   if Server is not in QueriedServers then do:
  271.                         send Query to Server;
  272.                         Answer := answer from Server;
  273.                         append ServersToAsk to ServerList;
  274.                         remove Server from ServerList;
  275.                         append Answers to AnswerList;
  276.                   end;
  277.             done;
  278.             if query should be expanded then do:
  279.  
  280.  
  281.  
  282. Faltstrom, et al            Standards Track                     [Page 5]
  283.  
  284. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  285.  
  286.  
  287.                   ServerList := OriginalServers;
  288.                   OriginalServers := {};
  289.                   while ServerList is not empty do:
  290.                         Server := ServerList[1];
  291.                         send Polled-For-Query to Server;
  292.                         Answer := answer from Server;
  293.                         append Answer to OriginalServers;
  294.                         remove Server from ServerList;
  295.                   end;
  296.             done;
  297.       done;
  298.       display AnswerList to user;
  299.  
  300. 3.2. The Directory of Servers
  301.  
  302.    A second way of finding the correct server to query is to use a
  303.    separate service we call the Directory of Servers. The Directory of
  304.    Servers is a special Whois++ server which polls every Whois++ server
  305.    for information about common information among the records on that
  306.    perticular server.
  307.  
  308. 3.2.1. How should a client use the Directory of Servers?
  309.  
  310.    A client that want to very quickly find what servers serves USER
  311.    templates in Sweden, should do it this way:
  312.  
  313.    1) The hostname and portnumber of the directory of Servers have
  314.       to be preconfigured in the current version of the protocol.
  315.  
  316.    2) Query the Directory of Servers for serverhandle records for
  317.       country sweden. This gives information of all these servers.
  318.       By presenting this information to the user the user should be
  319.       able to start the search at some closer server.
  320.  
  321.    Note that we at this moment doesn't think this should be an autmatic
  322.    process in the client. The Directory of Servers should be used for
  323.    giving the user information about what Whois++ servers that exists.
  324.  
  325.    In the future a technique might have developed that makes it possible
  326.    for a client to do this selection automatically depending on the
  327.    query the user issues.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Faltstrom, et al            Standards Track                     [Page 6]
  339.  
  340. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  341.  
  342.  
  343. 3.2.2. What does the serverhandle record look like?
  344.  
  345.    The attributes that must be in all serverhandle records are:
  346.  
  347.    Server-Handle: The handle for this server.
  348.    Host-Name:     The (current) hostname of this server.
  349.    Host-Port:     The (current) portnumber for this server.
  350.  
  351.    Part from that information, the record can include other attributes
  352.    like:
  353.  
  354.    Admin-Name:        Patrik Faltstrom
  355.    Admin-Email:       paf@bunyip.com
  356.    Admin-Phone:       +1-514-875-8611
  357.    Organization-Name: Bunyip Information Systems Inc.
  358.    Description:       USER information
  359.    Menu-Item:         World (Bunyip Information Systems inc)
  360.    City:              Montreal
  361.    State:             Quebec
  362.    Country:           Canada
  363.    :
  364.    :
  365.    (Other attributes that can identify all records on this server, for
  366.    example domainname)
  367.  
  368.    The information in the Navigation record is intended to be presented
  369.    to a user.
  370.  
  371. 3.2.3. Example
  372.  
  373.    An example of how an interaction with the Directory of Servers is
  374.    done follows. The characters '<' and '>' displays if it is the client
  375.    ('<') or responding server ('>') which is responsible for the output:
  376.  
  377. > % 220-This is services.bunyip.com running Bunyip-Whois++: DIGGER 1.0.5
  378. > % 220 Ready to go!
  379. < template=serverhandle and bunyip
  380. > % 200 Search is executing
  381. > # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM01
  382. >  SERVER-HANDLE: BUNYIPCOM01
  383. >  HOST-NAME: services.bunyip.com
  384. >  HOST-PORT: 63
  385. >  ADMIN-NAME: Patrik Faltstrom
  386. >  ADMIN-EMAIL: paf@bunyip.com
  387. >  ORGANIZATION-NAME: Bunyip Information Systems Inc.
  388. >  DESCRIPTION: USER information
  389. >  DESCRIPTION: Directory of Servers
  390. >  DESCRIPTION: Toplevel Index server in the world
  391.  
  392.  
  393.  
  394. Faltstrom, et al            Standards Track                     [Page 7]
  395.  
  396. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  397.  
  398.  
  399. >  MENU-ITEM: World (Bunyip Information Systems inc)
  400. >  CITY: Montreal
  401. >  COUNTRY: Canada
  402. > # END
  403. >
  404. > # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM02
  405. >  SERVER-HANDLE: BUNYIPCOM02
  406. >  HOST-NAME: services.bunyip.com
  407. >  HOST-PORT: 7778
  408. >  ADMIN-NAME: Patrik Faltstrom
  409. >  ADMIN-EMAIL: paf@bunyip.com
  410. >  ORGANIZATION-NAME: Bunyip Information Systems Inc.
  411. >  DESCRIPTION: USER information
  412. >  MENU-ITEM: Bunyip Information Systems
  413. >  CITY: Montreal
  414. >  COUNTRY: Canada
  415. > # END
  416. >
  417. > % 226 Transaction complete
  418. > % 203 Bye, bye
  419.  
  420. 4. Caching
  421.  
  422.    A client can cache all information it gets from a server for some
  423.    time.  For example records, IP-addresses of Whois++ servers, the
  424.    Directory of Services server etc.
  425.  
  426.    A client can itself choose for how long it should cache the
  427.    information.
  428.  
  429.    The IP-address of the Directory of Services server might not change
  430.    for a day or two, and neither might any other information.
  431.  
  432. 4.1. Caching a Whois++ servers hostname
  433.  
  434.    An example of cached information that might change is the chached
  435.    hostname, IP-address and portnumber which a client gets back in a
  436.    servers-to-ask response. That information is cached in the server
  437.    since the last poll, which might occurred several weeks ago.
  438.    Therefore, when such a connection fails, the client should fall back
  439.    to use the serverhandle insted, which means that it contacts the
  440.    Directory of Services server and queries for a server with that
  441.    serverhandle.  By doing this, the client should always get the last
  442.    known hostname.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Faltstrom, et al            Standards Track                     [Page 8]
  451.  
  452. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  453.  
  454.  
  455.    An algorithm for this might be:
  456.  
  457.   response := servers-to-ask response from server A
  458.   IP-address := find ip-address for response.hostname in DNS
  459.   connect to ip-address at port response.portnumber
  460.   if connection fails {
  461.      connect to Directory of Services server
  462.      query for host with serverhandle response.serverhandle
  463.      response := response from Directory of Services server
  464.      IP-address := find ip-address for response.hostname in DNS
  465.      connect to ip-address at port response.portnumber
  466.      if connection fails {
  467.          exit with error message
  468.      }
  469.    }
  470.    Query this new server
  471.  
  472. 5. Security Considerations
  473.  
  474.    Security considerations when using the Whois++ protocol is described
  475.    in [Deutsch94].
  476.  
  477.    A client should be able to have a "blacklist" of servers it should
  478.    not query, because it might happen that fake Whois++ servers is put
  479.    up on the net. When such a fake Whois++ servers is found, a user
  480.    should be able to configure it's client to never query this server.
  481.  
  482.    Note that a client should be careful when expanding a query by either
  483.    using normal expansion or using the directory of servers. A query
  484.    might take a long time, so a user should be able to quit in the
  485.    middle of such a transaction. This is though more a question of user
  486.    interaction than a plain security issue.
  487.  
  488. 6. References
  489.  
  490.    [Deutsch94]  Deutsch P., Schoultz R., Faltstrom P., and C. Weider,
  491.                 "Architecture of the Whois++ service", RFC 1835,
  492.                 August 1995.
  493.  
  494.    [Weider94]   Weider C., Fullton J., and S. Spero, "Architecture of
  495.                 the WHOIS++ Index Service", RFC 1913, February 1996.
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Faltstrom, et al            Standards Track                     [Page 9]
  507.  
  508. RFC 1914          How to Interact with a Whois++ Mesh      February 1996
  509.  
  510.  
  511. 7. Authors' Addresses
  512.  
  513.    Patrik Faltstrom
  514.    BUNYIP INFORMATION SYSTEMS, inc
  515.    310 St Catherine St West, Suite 300
  516.    Montreal, Quebec
  517.    CANADA H2X 2A1
  518.  
  519.    EMail: paf@bunyip.com
  520.  
  521.  
  522.    Rickard Schoultz
  523.    KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
  524.    S-100 44  STOCKHOLM
  525.    SWEDEN
  526.  
  527.    EMail: schoultz@sunet.se
  528.  
  529.  
  530.    Chris Weider
  531.    BUNYIP INFORMATION SYSTEMS, inc
  532.    310 St Catherine St West, Suite 300
  533.    Montreal, Quebec
  534.    CANADA H2X 2A1
  535.  
  536.    EMail: clw@bunyip.com
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Faltstrom, et al            Standards Track                    [Page 10]
  563.  
  564.