rfc1914.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 564 行 · 第 1/2 页


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:       [e-mail]
   Admin-Phone:       [phone]
   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: [e-mail]
>  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: [e-mail]
>  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: [e-mail]


   Rickard Schoultz
   KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
   S-100 44  STOCKHOLM
   SWEDEN

   EMail: [e-mail]


   Chris Weider
   BUNYIP INFORMATION SYSTEMS, inc
   310 St Catherine St West, Suite 300
   Montreal, Quebec
   CANADA H2X 2A1

   EMail: [e-mail]

























Faltstrom, et al            Standards Track                    [Page 10]