idnits 2.17.1 draft-ietf-wnils-whois-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 702 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 157 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 387: '...Version-Number REQUIRED...' RFC 2119 keyword, line 388: '...me-of-latest-centroid-change REQUIRED...' RFC 2119 keyword, line 389: '...me-of-message-generation REQUIRED...' RFC 2119 keyword, line 390: '...Server-handle REQUIRED...' RFC 2119 keyword, line 391: '...Host-Name REQUIRED...' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1835 (ref. 'Deutsch 95') -- Possible downref: Non-RFC (?) normative reference: ref. 'Faltstrom 95' Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WNILS Working Group Chris Weider 2 INTERNET-DRAFT Bunyip 3 Jim Fullton 4 CNIDR 5 Simon Spero 6 EIT 7 October, 1995 9 Architecture of the Whois++ Index Service 11 Status of this memo: 13 The authors describe an architecture for indexing in distributed databases, 14 and apply this to the WHOIS++ protocol. 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted 23 by other documents at any time. It is not appropriate to use 24 Internet Drafts as reference material or to cite them other than 25 as a "working draft" or "work in progress." 27 Please check the I-D abstract listing contained in each Internet 28 Draft directory to learn the current status of this or any 29 other Internet Draft. 31 This Internet Draft expires March 20, 1996. 33 1. Purpose: 35 The WHOIS++ directory service [Deutsch, et al, 1995] is intended to provide 36 a simple, extensible directory service predicated on a template-based 37 information model and a flexible query language. This document describes 38 a general architecture designed for indexing distributed databases, and then 39 applys that architecture to link together many of these WHOIS++ servers 40 into a distributed, searchable wide area directory service. 42 2. Scope: 44 This document details a distributed, easily maintained architecture for 45 providing a unified index to a large number of distributed WHOIS++ 46 servers. This architecture can be used with systems other than WHOIS++ to 47 provide a distributed directory service which is also searchable. 49 3. Motivation and Introduction: 51 It seems clear that with the vast amount of directory information potentially 52 available on the Internet, it is simply not feasible to build a centralized 53 directory to serve all this information. If we are to distribute the directory 54 service, the easiest (although not necessarily the best) way of building the 55 directory service is to build a hierarchy of directory information collection 56 agents. In this architecture, a directory query is delivered to a certain agent 57 in the tree, and then handed up or down, as appropriate, so that the query 58 is delivered to the agent which holds the information which fills the query. 59 This approach has been tried before, most notably in some implementations of 60 the X.500 standard. However, there are number of major flaws with the approach 61 as it has been taken. This new Index Service is designed to fix these flaws. 63 3.1. The search problem 65 One of the primary assumptions made by recent implementations of distributed 66 directory services is that every entry resides in some location in a hierarch- 67 ical name space. While this arrangement is ideal for reading the entry once 68 one knows its location, it is not as good when one is searching for the 69 location in the namespace of those entries which meet some set of criteria. 70 If the only criteria we know about a desired entry are items which do not 71 appear in the namespace, we are forced to do a global query. Whenever we issue 72 a global query (at the root of the namespace), or a query at the top of a 73 given subtree in the namespace, that query is replicated to _all_ subtrees of 74 the starting point. The replication of the query to all subtrees is not 75 necessarily a problem; queries are cheap. However, every server to which the 76 query has been replicated must process that query, even if it has no entries 77 which match the specified criteria. This part of the global query processing 78 is quite expensive. A poorly designed namespace or a thin namespace can cause 79 the vast majority of queries to be replicated globally, but a very broad 80 namespace can cause its own navigation problems. Because of these problems, 81 search has been turned off at high levels of the X.500 namespace. 83 3.2. The location problem 85 With global search turned off, one must know in advance how the name space is 86 laid out so that one can guide a query to a proper location. Also, the layout 87 of the namespace then becomes critical to a user's ability to find the 88 desired information. Thus there are endless battles about how to lay out the 89 name space to best serve a given set of users, and enormous headaches whenever 90 it becomes apparent that the current namespace is unsuited to the current 91 usages and must be changed (as recently happened in X.500). Also, assuming 92 one does impose multiple hierarchies on the entries through use of the 93 namespace, the mechanisms to maintain these multiple hierarchies in X.500 do 94 not exist yet, and it is possible to move entries out from under their 95 pointers. Also, there is as yet no agreement on how the X.500 namespace 96 should look even for the White Pages types of information that is currently 97 installed in the X.500 pilot project. 99 3.3. The Yellow Pages problem 101 Current implementations of this hierarchical architecture have also been 102 unsuited to solving the Yellow Pages problem; that is, the problem of 103 easily and flexibly building special-purpose directories (say of molecular 104 biologists) and of automatically maintaining these directories once they have 105 been built. In particular, the attributes appropriate to the new directory 106 must be built into the namespace because that is the only way to segregate 107 related entries into a place where they can be found without a global 108 search. Also, there is a classification problem; how does one adequately 109 specify the proper categories so that people other than the creator of the 110 directory can find the correct subtree? Additionally, there is the problem 111 of actually finding the data to put into the subtree; if one must traverse 112 the hierarchy to find the data, we have to look globally for the proper 113 entries. 115 3.4. Solutions 117 The problems examined in this section can be addressed by a combination of two 118 new techniques: directory meshes and forward knowledge. 120 4. Directory meshes and forward knowledge 122 We'll hold off for a moment on describing the actual architecture used in 123 our solution to these problems and concentrate on a high level description of 124 what solutions are provided by our conceptual approach. To begin with, 125 although every entry in WHOIS++ does indeed have a unique identifier 126 (resides in a specific location in the namespace) the navigational algorithms 127 to reach a specific entry do not necessarily depend on the identifier the 128 entry has been assigned. The Index Service gets around the namespace and 129 hierarchy problems by creating a directory mesh on top of the entries. 130 Each layer of the mesh has a set of 'forward knowledge' which indicates the 131 contents of the various servers at the next lower layer of the mesh. Thus 132 when a query is received by a server in a given layer of the mesh, it can 133 prune the search tree and hand the query off to only those lower level servers 134 which have indicated that they might be able to answer it. Thus search becomes 135 feasible at all levels of the mesh. In the current version of this 136 architecture, we have chosen a certain set of information to hand up the mesh 137 as forward knowledge. This may or may not be exactly the set of information 138 required to construct a truly searchable directory, but the protocol itself 139 doesn't restrict the types of information which can be handed around. 141 In addition, the protocols designed to maintain the forward knowledge will 142 also work perfectly well to provide replication of servers for redundancy 143 and robustness. In this case, the forward knowledge handed around by the 144 protocols is the entire database of entries held by the replicated server. 146 Another benefit provided by the mesh of index servers is that since the 147 entry identification scheme has been decoupled from the navigation service, 148 multiple hierarchies can be built and easily maintained on top of the 149 existing data. Also, the user does not need to know in advance where in the 150 mesh the entry is contained. 152 Also, the Yellow Pages problem now becomes tractable, as the index servers 153 can pick and choose between information proffered by a given server; 154 because we have an architecture that allows for automatic polling of data, 155 special purpose directories become easy to construct and to maintain. 157 5. Components of the Index Service: 159 5.1. WHOIS++ servers 161 The whois++ service is described in [Deutsch, et al, 1995]. As that service 162 specifies only the query language, the information model, and the server 163 responses, whois++ services can be provided by a wide variety of databases 164 and directory services. However, to participate in the Index Service, that 165 underlying database must also be able to generate a 'centroid', or some other 166 type of forward knowledge, for the data it serves. 168 5.2. Centroids as forward knowledge 170 The centroid of a server is comprised of a list of the templates and 171 attributes used by that server, and a word list for each attribute. 172 The word list for a given attribute contains one occurrence of every 173 word which appears at least once in that attribute in some record in that 174 server's data, and nothing else. 176 A word is any token delimited by blank spaces and/or newlines in the value 177 of an attribute. 179 For example, if a whois++ server contains exactly three records, as follows: 181 Record 1 Record 2 182 Template: User Template: User 183 First Name: John First Name: Joe 184 Last Name: Smith Last Name: Smith 185 Favourite Drink: Labatt Beer Favourite Drink: Molson Beer 187 Record 3 188 Template: Domain 189 Domain Name: foo.edu 190 Contact Name: Mike Foobar 192 the centroid for this server would be 194 Template: User 195 First Name: Joe 196 John 197 Last Name: Smith 198 Favourite Drink: Beer 199 Labatt 200 Molson 202 Template: Domain 203 Domain Name: foo.edu 204 Contact Name: Mike 205 Foobar 207 It is this information which is handed up the tree to provide forward 208 knowledge. As we mention above, this may not turn out to be the ideal 209 solution for forward knowledge, and we suspect that there may be a number of 210 different sets of forward knowledge used in the Index Service. However, the 211 directory architecture is in a very real sense independent of what types of 212 forward knowledge are handed around, and it is entirely possible to build a 213 unified directory which uses many types of forward knowledge. 215 5.3. Index servers and Index server Architecture 217 A whois++ index server collects and collates the centroids (or other forward 218 knowledge) of either a number of whois++ servers or of a number of other index 219 servers. An index server must be able to generate a centroid for the 220 information it contains. In addition, an index server can index any other 221 server it wishes, which allows one base level server (or index server) to 222 participate in many hierarchies in the directory mesh. 224 5.3.1. Queries to index servers 226 An index server will take a query in standard whois++ format, search its 227 collections of centroids and other forward information, determine which 228 servers hold records which may fill that query, and then notifies the 229 user's client of the next servers to contact to submit the query (referral in 230 the X.500 model). An index server can also contain primary data of its own; 231 and thus act a both an index server and a base level server. In this case, the 232 index server's response to a query may be a mix of records and referral 233 pointers. 235 5.3.2. Index server distribution model and centroid propogation 237 The diagram on the next page illustrates how a mesh of index servers might be 238 created for a set of whois++ servers. Although it looks like a hierarchy, 239 the protocols allow (for example) server A to be indexed by both server 240 D and by server H. 242 whois++ index index 243 servers servers servers 244 for for 245 whois++ lower-level 246 servers index servers 247 _______ 248 | | 249 | A |__ 250 |_______| \ _______ 251 \----------| | 252 _______ | D |__ ______ 253 | | /----------|_______| \ | | 254 | B |__/ \----------| | 255 |_______| | F | 256 /----------|______| 257 / 258 _______ _______ / 259 | | | |- 260 | C |--------------| E | 261 |_______| |_______|- 262 \ 263 \ 264 _______ \ ______ 265 | | \----------| | 266 | G |--------------------------------------| H | 267 |_______| |______| 269 Figure 1: Sample layout of the Index Service mesh 270 _______________________________________________________________________________ 272 In the portion of the index tree shown above, whois++ servers A and B hand 273 their centroids up to index server D, whois++ server C hands its centroid up 274 to index server E, and index servers D and E hand their centroids up to index 275 server F. Servers E and G also hand their centroids up to H. 277 The number of levels of index servers, and the number of index servers at each 278 level, will depend on the number of whois++ servers deployed, and the response 279 time of individual layers of the server tree. These numbers will have to 280 be determined in the field. 282 5.3.3. Centroid propogation and changes to centroids 284 Centroid propogation is initiated by an authenticated POLL command (sec. 5.2). 285 The format of the POLL command allows the poller to request the centroid of 286 any or all templates and attributes held by the polled server. After the 287 polled server has authenticated the poller, it determines which of the 288 requested centroids the poller is allowed to request, and then issues a 289 CENTROID-CHANGES report (sec. 5.3) to transmit the data. When the poller 290 receives the CENTROID-CHANGES report, it can authenticate the pollee to 291 determine whether to add the centroid changes to its data. Additionally, if 292 a given pollee knows what pollers hold centroids from the pollee, it can 293 signal to those pollers the fact that its centroid has changed by issuing 294 a DATA-CHANGED command. The poller can then determine if and when to 295 issue a new POLL request to get the updated information. The DATA-CHANGED 296 command is included in this protocol to allow 'interactive' updating of 297 critical information. 299 5.3.4. Centroid propogation and mesh traversal 301 When an index server issues a POLL request, it may indicate to the polled 302 server what relationship it has to the polled. This information can be 303 used to help traverse the directory mesh. Two fields are specified in the 304 current proposal to transmit the relationship information, although it is 305 expected that richer relationship information will be shared in future 306 revisions of this protocol. 308 One field used for this information is the 309 Hierarchy field, and can take on three values. The first is 'topology', 310 which indicates that the indexing server is at a higher level in the network 311 topology (e.g. indexes the whole regional ISP). The second is 'geographical', 312 which indicates that the polling server covers a geographical area subsuming 313 the pollee. The third is 'administrative', which indicates that 314 the indexing server covers an administrative domain subsuming the pollee. 316 The second field used for this information is the Description field, which 317 contains the DESCRIBE record of the polling server. This allows users to 318 obtain richer metainformation for the directory mesh, enabling them to expand 319 queries more effectively. 321 5.3.5. Query handling and passing algorithms 323 When an index server receives a query, it searches its collection of centroids 324 and determines which servers hold records which may fill that query. As 325 whois++ becomes widely deployed, it is expected that some index servers 326 may specialize in indexing certain whois++ templates or perhaps even 327 certain fields within those templates. If an index server obtains a match 328 with the query _for those template fields and attributes the server indexes_, 329 it is to be considered a match for the purpose of forwarding the query. 331 5.3.5.1. Query referral 333 Query referral is the process of informing a client which servers to contact 334 next to resolve a query. The syntax for notifying a client is outlined in 335 section 5.5. 337 5.3.6 Loop control 339 Since there are no a priori restrictions on which servers may poll which other 340 servers, and since a given server may participate in many sub-meshes, 341 mechanisms must be installed to allow the detection of cycles in the polling 342 relationships. This is accomplished in the current protocol by including a 343 hop-count on polling relationships. Each time a polled server generates 344 forward information, it informs the polling server about its current hopcount, 345 which is the maximum of the hopcounts of all the servers it polls, plus 1. 346 A base level server (one which polls no other servers) will have a hopcount of 347 0. When a server decides to poll a new server, if its hopcount goes up, then 348 it must information all the other servers which poll it about its new hopcount. 349 A maximum hopcount (8 in the current version) will help the servers detect 350 polling loops. 352 A second approach to loop detection is to do all the work in the client; 353 which would determine which new referrals have already appeared in the referral 354 list, and then simply iterate the referral process until there are no new 355 servers to ask. An algorithm to accomplish this in WHOIS++ is detailed in 356 [Faltstrom 95]. 358 6. Syntax for operations of the Index Service: 360 The syntax for each protocol componenet is listed below. In addition, 361 each section contains a listing of which of these attributes is required and 362 optional for each of the componenet. All timestamps must be in the format 363 YYYYMMDDHHMM and in GMT. 365 6.1. Data changed syntax 367 The data changed template look like this: 369 # DATA-CHANGED 370 Version-number: // version number of index service software, used to insure 371 // compatibility. Current value is 1.0 372 Time-of-latest-centroid-change: // time stamp of latest centroid change,GMT 373 Time-of-message-generation: // time when this message was generated, GMT 374 Server-handle: // IANA unique identifier for this server 375 Host-Name: // Host name of this server (current name) 376 Host-Port: // Port number of this server (current port) 377 Best-time-to-poll: // For heavily used servers, this will identify when 378 // the server is likely to be lightly loaded 379 // so that response to the poll will be speedy, GMT 380 Authentication-type: // Type of authentication used by server, or NONE 381 Authentication-data: // data for authentication 382 # END // This line must be used to terminate the data changed 383 // message 385 Required/optional table 387 Version-Number REQUIRED 388 Time-of-latest-centroid-change REQUIRED 389 Time-of-message-generation REQUIRED 390 Server-handle REQUIRED 391 Host-Name REQUIRED 392 Host-Port REQUIRED 393 Best-time-to-poll OPTIONAL 394 Authentication-type OPTIONAL 395 Authentication-data OPTIONAL 397 6.2. Polling syntax 399 # POLL: 400 Version-number: // version number of poller's index software, used to 401 // insure compatibility 402 Type-of-poll: // type of forward data requested. CENTROID or QUERY 403 // are the only one currently defined 404 Poll-scope: // Selects bounds within which data will be returned. See note. 405 Start-time: // give me all the centroid changes starting at this time, GMT 406 End-time: // ending at this time, GMT 407 Template: // a standard whois++ template name, or the keyword ALL, for a 408 // full update. 409 Field: // used to limit centroid update information to specific fields, 410 // is either a specific field name, a list of field names, 411 // or the keyword ALL 412 Server-handle: // IANA unique identifier for the polling server. 413 // this handle may optionally be cached by the polled 414 // server to announce future changes 415 Host-Name: // Host name of the polling server. 416 Host-Port: // Port number of the polling server. 417 Hierarchy: // This field indicates the relationship which the poller 418 // bears to the pollee. Typical values might include 419 // 'Topology', 'Geographical", or "Administrative" 420 Description: // This field contains the DESCRIBE record of the 421 // polling server 422 Authentication-type: // Type of authentication used by poller, or NONE 423 Authentication-data: // Data for authentication 424 # END // This line must by used to terminate the poll message 426 Note: For poll type CENTROID, the allowable values for Poll Scope are 427 FULL and RELATIVE. Support of the FULL value is required, this provides 428 a complete listing of the centroid or other forward information. RELATIVE 429 indicates that these are the relative changes in the centroid since the last 430 report to the polling server. 432 For poll type QUERY, the allowable values for Poll 433 Scope are a blank line, which indicates that all records are to be 434 returned, or a valid WHOIS++ query, which indicates that just those 435 records which satisfy the query are to be returned. N.B. Security 436 considerations may require additional authentication for successful response 437 to the Blank Line Poll Scope. This value has been included for server 438 replication. 440 A polling server may wish to index different types of information than the 441 polled server has collected. The POLLED-FOR command will indicate which 442 servers the polled server has contacted. 444 Required/Optional Table 446 Version-Number REQUIRED, value is 1.0 447 Type-Of-Poll REQUIRED, values CENTROID and QUERY are required 448 Poll-scope REQUIRED If Type-of-poll is CENTROID, FULL is required, 449 RELATIVE is optional 450 If Type-of-poll is QUERY, Blank line is required, 451 and WHOIS++-type queries are required 452 Start-time OPTIONAL 453 End-Time OPTIONAL 454 Template REQUIRED 455 Field REQUIRED 456 Server-handle REQUIRED 457 Host-Name REQUIRED 458 Host-Port REQUIRED 459 Hierarchy OPTIONAL 460 Description OPTIONAL 461 Authentication-Type: OPTIONAL 462 Authentication-data: OPTIONAL 464 Example of a POLL command: 465 # POLL: 466 Version-number: 1.0 467 Type-of-poll: CENTROID 468 Poll-scope: FULL 469 Start-time: 199501281030+0100 470 Template: ALL 471 Field: ALL 472 Server-handle: BUNYIP01 473 Host-Name: services.bunyip.com 474 Host-Port: 7070 475 Hierarchy: Geographical 476 # END 478 6.3. Centroid change report 480 As the centroid change report contains nested multiply-occuring blocks, 481 each multiply occurring block is surrounded *in this paper* by curly 482 braces '{', '}'. These curly braces are NOT part of the syntax, they are 483 for identification purposes only. 485 The syntax of a Data: item is either a list of words, one word per line, 486 or the keyword: 488 ANY 490 . The keyword ANY as the only item of a Data: list means that any value for 491 this field should be treated as a hit by the indexing server. 493 The field Any-field: needs more explanation than can be given in the body 494 of the syntax description below. It can take two values, True or False. If 495 the value is True, the pollee is indicating that there are fields in this 496 template which are not being exported to the polling server, but wishes to 497 treat as a hit. Thus, when the polling server gets a query which has a term 498 requesting a field not in this list for this template, the polling server 499 will treat that term as a 'hit'. If the value is False, the pollee is 500 indicating that there are no other fields for this template which should be 501 treated as a hit. This field is required because the basic model for the 502 WHOIS++ query syntax requires that the results of each search term be 'and'ed 503 together. This field allows polled servers to export data only for 504 non-sensitive fields, yet still get referrals of queries which contain 505 sensitive terms. 507 # CENTROID-CHANGES 508 Version-number: // version number of pollee's index software, used to 509 // insure compatibility 510 Start-time: // change list starting time, GMT 511 End-time: // change list ending time, GMT 512 Server-handle: // IANA unique identifier of the responding server 513 Case-sensitive: // states whether data is case sensitive or case 514 // insensitive. values are TRUE or FALSE 515 Authentication-type: // Type of authentication used by pollee, or NONE 516 Authentication-data: // Data for authentication 517 Compression-type: // Type of compression used on the data, or NONE 518 Size-of-compressed-data: // size of compressed data if compression is used 519 Operation: // One of 3 keywords: ADD, DELETE, FULL 520 // ADD - add these entries to the centroid for this server 521 // DELETE - delete these entries from the centroid of this 522 // server 523 // FULL - the full centroid as of end-time follows 524 { // The multiply occurring template block starts here 525 # BEGIN TEMPLATE 526 Template: // a standard whois++ template name 527 Any-field: // TRUE or FALSE. See beginning of 6.3 for explanation. 528 { // the template contains multiple field blocks 529 # BEGIN FIELD 530 Field: // a field name within that template 531 Data: // Either the keyword *ANY*, or 532 // the word list itself, one per line, cr/lf terminated, 533 // each line starting with a dash character ('-'). 534 # END FIELD 535 } // the field ends with END FIELD 536 # END TEMPLATE 537 } // the template block ends with END TEMPLATE 538 # END CENTROID-CHANGES // This line must be used to terminate the centroid 539 // change report 541 For each template, all fields must be listed, or queries will not be 542 referred correctly. 544 Required/Optional table 546 Version-number REQUIRED, value is 1.0 547 Start-time REQUIRED (even if the centroid type is FULL) 548 End-time REQUIRED (even if the centroid type is FULL) 549 Server-handle REQUIRED 550 Case-Sensitive OPTIONAL 551 Authentication-Type OPTIONAL 552 Authentication-Data OPTIONAL 553 Compression-type OPTIONAL 554 Size-of-compressed-data OPTIONAL (even if compression is used) 555 Operation OPTIONAL, if used, upport for all three values is required 556 Tokenization-type OPTIONAL 557 #BEGIN TEMPLATE REQUIRED 558 Template REQUIRED 559 Any-field REQUIRED 560 #BEGIN FIELD REQUIRED 561 Field REQUIRED 562 Data REQUIRED 563 #END FIELD REQUIRED 564 #END TEMPLATE REQUIRED 565 #END CENTROID-CHANGES REQUIRED 567 Example: 569 # CENTROID-CHANGES 570 Version-number: 1.0 571 Start-time: 197001010000 572 End-time: 199503012336 573 Server-handle: BUNYIP01 574 # BEGIN TEMPLATE 575 Template: USER 576 Any-field: TRUE 577 # BEGIN FIELD 578 Field: Name 579 Data: Patrik 580 -Faltstrom 581 -Malin 582 -Linnerborg 583 #END FIELD 584 #BEGIN FIELD 585 Field: Email 586 Data: paf@bunyip.com 587 -malin.linnerborg@paf.se 588 # END FIELD 589 # END TEMPLATE 590 # END CENTROID-CHANGES 592 4.4 QUERY and POLLEES responses 594 The response to a QUERY command is done in WHOIS++ format. 596 6.4. Query referral 598 When referrals are included in the body of a response to a query, 599 each referral is listed in a separate SERVER-TO-ASK block as shown 600 below. 602 # SERVER-TO-ASK 603 Version-number: // version number of index software, used to insure 604 // compatibility 605 Body-of-Query: // the original query goes here 606 Server-Handle: // WHOIS++ handle of the referred server 607 Host-Name: // DNS name or IP address of the referred server 608 Port-Number: // Port number to which to connect, if different from the 609 // WHOIS++ port number 611 # END 613 Required/Optional table 615 Version-number REQUIRED, value should be 1.0 616 Body-of-query OPTIONAL 617 Server-Handle REQUIRED 618 Host-Name REQUIRED 619 Port-Number OPTIONAL, must be used if different from port 63 621 Example: 623 # SERVER-TO-ASK 624 Version-Number: 1.0 625 Server-Handle: SUNETSE01 626 Host-Name: sunic.sunet.se 627 Port-Number: 63 628 # END 630 7: Reply Codes 631 In addition to the reply codes listed in [Deutsch 95] for the basic WHOIS++ 632 client/server interaction, the following reply codes are used in version 1.0 633 of this protocol. 635 113 Requested method not available Unable to provide a requested 636 compression method. Contacted server 637 will send requested data in different 638 format. 640 227 Update request acknowledged A DATA-CHANGED transmission has been 641 accepted and logged for further action. 643 503 Required attribute missing A REQUIRED attribute is missing in an 644 interaction. 646 504 Desired server unreachable The desired server is unreachable. 648 505 Desired server unavailable The desired server fails to respond to 649 requests, but host is still reachable. 651 8. References 653 [Deutsch 95] Deutsch, et al. Architecture of the WHOIS++ service. March 1995. 654 RFC 1835. 656 [Faltstrom 95] Faltstrom, Patrik, Rickard Schoultz, and Chris Weider, 657 How to interact with a WHOIS++ mesh, Internet Draft, October 1995 658 Available by anonymous FTP as 659 < URL://nic.merit.edu/documents/internet-drafts/draft-ietf-asid-mesh-03.txt> 661 9. Author's Addresses 663 Chris Weider 664 clw@bunyip.com 665 Bunyip Information Systems, Inc. 666 310 St. Catherine St. West 667 Montreal, PQ H2X 2A1 668 CANADA 669 (O) +1-514-875-8611 670 (F) +1-514-875-6134 672 Jim Fullton 673 fullton@cnidr.org 674 MCNC Center for Communications 675 Post Office Box 12889 676 3021 Cornwallis Road 677 Research Triangle Park 678 North Carolina 27709-2889 679 O: 410-795-5422 680 F: 410-795-5422 682 Simon Spero 683 ses@eit.com