File: rfc1914.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (563 lines) | stat: -rw-r--r-- 17,842 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
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
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]