idnits 2.17.1 draft-ietf-find-cip-01.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-25) 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 757 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 an Introduction 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 an Authors' Addresses Section. ** There are 154 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** There are 42 instances of lines with control characters 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 367: '...Version-Number REQUIRED...' RFC 2119 keyword, line 368: '...me-of-latest-centroid-change REQUIRED...' RFC 2119 keyword, line 369: '...me-of-message-generation REQUIRED...' RFC 2119 keyword, line 370: '...DSI OPTIONAL...' RFC 2119 keyword, line 371: '...Server-handle REQUIRED...' (60 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '...tandard forma...' == Line 520 has weird spacing: '...dvanced serve...' -- 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.) -- The document date (May 1996) is 10207 days in the past. Is this intentional? -- 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) -- Missing reference section? 'Faltstrom 95' on line 741 looks like a reference -- Missing reference section? 'Deutsch 95' on line 738 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Chris Weider 3 INTERNET-DRAFT CNIDR 4 May 1996 6 The Common Indexing Protocol 8 Status of this memo: 10 The author describes a protocol designed to provide common indexing 11 for the currently deployed Internet Directory Services. 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted 20 by other documents at any time. It is not appropriate to use 21 Internet Drafts as reference material or to cite them other than 22 as a "working draft" or "work in progress." 24 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any 26 other Internet Draft. 28 This Internet Draft expires October 20, 1996. 30 Part 0: Differences between this and the WHOIS++ Indexing protocol 32 This protocol is designed to be more flexible than version 1.0 33 of the WHOIS++ Indexing protocol. The version number on this protocol 34 is 2.0, as when this stabilizes it will become version 2.0 of the 35 WHOIS++ Index protocol as well. It adds the ability to specify 36 tokenization method for the strings generated for the centroids, 37 weighting capabilities, and the ability to specify which original 38 host a specific term was derived from. These capabilities 39 should provide a much more robust indexing protocol. 41 Part 1: Introduction 43 This protocol is designed to allow general indexing from most of the attribute- 44 value based directory services. It is an extension of the current WHOIS++ 45 indexing protocol. Also, this protocol is designed to be implemented in 46 such a way as to allow many different types of protocols (X.500, WHOIS++, 47 SOLO, LDAP, etc) to use a basic server which speaks all these protocols. 49 Part 2: Using the Indexing Architecture 51 The basic software architecture consists of APIs to back-end databases, 52 an indexing 'object' which speaks the indexing protocol, and a variety of 53 interfaces for various query protocols. 55 Backend Databases Indexing Object Protocol Front End Client 56 or query protocols 57 _________ 58 __________ __________ | | 59 | | | |<-CIP-| WHOIS++ |<-WHOIS++- 60 | SQL or |<---API---->| Indexer | |_________| 61 | Z39.50 or| |__________| 62 | GDBM or | ^ __________ 63 |__________| |----CIP-| | 64 | SOLO |<-SOLO- 65 |_________| 67 Each Indexer participates in a forward knowledge mesh as shown below. 69 Part 3: Protocol Functionality and components of the Index Service 71 3.1 Base data servers 73 Most directory services today specify only the query language, 74 the information model, and the server responses for their servers. 75 Most also use a basic 'template-based' information model, in which each 76 entry consists of a set of attribute-value pairs. Thus the basic service 77 can be provided by a wide variety of databases and directory services. 78 However, to participate in the Index Service, that underlying database must 79 also be able to generate a 'centroid', or some other type of forward 80 knowledge, for the data it serves. 82 Connections out from the indexing service to the base data servers will 83 be accomplished using URLs for the various end protocols. This will 84 avoid the need to rewrite the data from its native formats. 86 3.2. Centroids as forward knowledge 88 The centroid of a server is comprised of a list of the templates and 89 attributes used by that server, and a word list for each attribute. 90 The word list for a given attribute contains one occurrence of every 91 word which appears at least once in that attribute in some record in that 92 server's data, and nothing else. 94 For example, if a server contains exactly three records, as follows: 96 Record 1 Record 2 97 Template: User Template: User 98 First Name: John First Name: Joe 99 Last Name: Smith Last Name: Smith 100 Favourite Drink: Labatt Beer Favourite Drink: Molson Beer 102 Record 3 103 Template: Domain 104 Domain Name: foo.edu 105 Contact Name: Mike Foobar 107 the centroid for this server would be 109 Template: User 110 First Name: Joe 111 -John 112 Last Name: Smith 113 Favourite Drink: Beer 114 -Labatt 115 -Molson 117 Template: Domain 118 Domain Name: foo.edu 119 Contact Name: Mike 120 -Foobar 122 It is this information which is handed up the tree to provide forward 123 knowledge. As we mention above, this may not turn out to be the ideal 124 solution for forward knowledge, and we suspect that there may be a number of 125 different sets of forward knowledge used in the Index Service. However, the 126 indexing architecture is in a very real sense independent of what types of 127 forward knowledge are handed around, and it is entirely possible to build a 128 unified directory which uses many types of forward knowledge. 130 3.3 Other types of forward information 132 There are several other types of forward information that might be useful 133 in an indexing service. The first is untokenized values for the given 134 attributes, as opposed to the tokenized values given in the centroid. 135 A second type is forward information generated by a typical query; 136 this can be used for replication of databases or of specific records in 137 a database. A third type is forward information which specifies from 138 which server a given value was obtained. All of these are given in 139 the protocol. 141 3.4. Index servers and Index server Architecture 143 A index server collects and collates the centroids (or other forward 144 knowledge) of either a number of base servers or of a number of other index 145 servers. An index server must be able to generate a centroid for the 146 information it contains. In addition, an index server can index any other 147 server it wishes, which allows one base level server (or index server) to 148 participate in many hierarchies in the directory mesh. 150 3.4.1. Queries to index servers 152 An index server will take a query in standard format, search its 153 collections of centroids and other forward information, determine which 154 servers hold records which may fill that query, and then notifies the 155 user's client of the next servers to contact to submit the query (referral in 156 the X.500 model). An index server can also contain primary data of its own; 157 and thus act a both an index server and a base level server. In this case, the 158 index server's response to a query may be a mix of records and referral 159 pointers. 161 Protocol-specific use of an index server (for example, issuing a WHOIS++ 162 query to the index service) will require a protocol-specific front end to the 163 index server, which is responsible for translating the query and formatting 164 the output as required. 166 3.4.2. Index server distribution model and forward knowledge propogation 168 The diagram on the next page illustrates how a mesh of index servers might be 169 created for a set of base servers. Although it looks like a hierarchy, 170 the protocols allow (for example) server A to be indexed by both server 171 D and by server H. 173 base level index index 174 servers servers servers 175 for for 176 base level lower-level 177 servers index servers 178 _______ 179 | | 180 | A |__ 181 |_______| \ _______ 182 \----------| | 183 _______ | D |__ ______ 184 | | /----------|_______| \ | | 185 | B |__/ \----------| | 186 |_______| | F | 187 /----------|______| 188 / 189 _______ _______ / 190 | | | |- 191 | C |--------------| E | 192 |_______| |_______|- 193 \ 194 \ 195 _______ \ ______ 196 | | \----------| | 197 | G |--------------------------------------| H | 198 |_______| |______| 200 Figure 1: Sample layout of the Index Service mesh 201 _______________________________________________________________________________ 203 In the portion of the index tree shown above, base servers A and B hand 204 their centroids up to index server D, base server C hands its centroid up 205 to index server E, and index servers D and E hand their centroids up to index 206 server F. Servers E and G also hand their centroids up to H. 208 The number of levels of index servers, and the number of index servers at each 209 level, will depend on the number of base servers deployed, and the response 210 time of individual layers of the server tree. These numbers will have to 211 be determined in the field. 213 3.4.3. Forward knowledge propogation and changes to forward knowledge 215 Forward knowledge propogation is initiated by an authenticated POLL command 216 (sec. 4.2). The format of the POLL command allows the poller to request the 217 forward knowledge of any or all templates and attributes held by the polled 218 server. After the polled server has authenticated the poller, it determines 219 which of the requested forward knowledge the poller is allowed to request, and 220 then issues a CENTROID-CHANGES report (sec. 4.3) to transmit the data. When the 221 poller receives the CENTROID-CHANGES report, it can authenticate the pollee to 222 determine whether to add the new changes to its data. Additionally, if 223 a given pollee knows what pollers hold forward knowledge from the pollee, it can 224 signal to those pollers the fact that its information has changed by issuing 225 a DATA-CHANGED command. The poller can then determine if and when to 226 issue a new POLL request to get the updated information. The DATA-CHANGED 227 command is included in this protocol to allow 'interactive' updating of 228 critical information. 230 3.4.4. Forward knowledge propogation and mesh traversal 232 When an index server issues a POLL request, it may indicate to the polled 233 server what relationship it has to the polled. This information can be 234 used to help traverse the directory mesh. Two fields are specified in the 235 current proposal to transmit the relationship information, although it is 236 expected that richer relationship information will be shared in future 237 revisions of this protocol. 239 One field used for this information is the Hierarchy field, and can take on 240 three values. The first is 'topology', which indicates that the indexing 241 server is at a higher level in the network topology (e.g. indexes the whole 242 regional ISP). The second is 'geographical', which indicates that the polling 243 server covers a geographical area subsuming the pollee. The third is 244 'administrative', which indicates that the indexing server covers an 245 administrative domain subsuming the pollee. 247 The second field used for this information is the Description field, which 248 contains the DESCRIBE record of the polling server. This allows users to 249 obtain richer metainformation for the directory mesh, enabling them to expand 250 queries more effectively. 252 3.4.5 Loop control 254 Since there are no a priori restrictions on which servers may poll which other 255 servers, and since a given server may participate in many sub-meshes, 256 mechanisms must be installed to allow the detection of cycles in the polling 257 relationships. This is accomplished in the current protocol by including a 258 hop-count on polling relationships. Each time a polled server generates 259 forward information, it informs the polling server about its current hopcount, 260 which is the maximum of the hopcounts of all the servers it polls, plus 1. 261 A base level server (one which polls no other servers) will have a hopcount of 262 0. When a server decides to poll a new server, if its hopcount goes up, then 263 it must information all the other servers which poll it about its new hopcount. 264 A maximum hopcount (8 in the current version) will help the servers detect 265 polling loops. 267 A second approach to loop detection is to do all the work in the client; 268 which would determine which new referrals have already appeared in the referral 269 list, and then simply iterate the referral process until there are no new 270 servers to ask. An algorithm to accomplish this in WHOIS++ is detailed in 271 [Faltstrom 95]. 273 3.4.6. Query handling and passing algorithms 275 When an index server receives a query, it searches its collection of forward 276 knowledge and determines which servers hold records which may fill that query. 277 As this service becomes widely deployed, it is expected that some index servers 278 may specialize in indexing certain template types or perhaps even 279 certain fields within those templates. If an index server obtains a match 280 with the query _for those template fields and attributes the server indexes_, 281 it is to be considered a match for the purpose of forwarding the query. 283 3.4.7. Query referral 285 Query referral is the process of informing a client which servers to contact 286 next to resolve a query. The syntax for notifying a client is outlined in 287 section 4.5. A query can specify the 'trace' option, which causes each server 288 which receives the query to send its server handle and an identification 289 string to the client. 291 3.5 Security considerations 293 In the opinion of this author, until a generally accepted Internet wide 294 security service is available (or until a web of such services reaches into 295 most of the Internet) all security applied to queries should be done by 296 the base server. Propogating this information through the common index 297 mesh will run immediately into the problems of common authentication, 298 access control, and incommensurable security features. Thus any index 299 information propogated to this service should be considered unsecured. 300 Server to Server authentication is provided, however. 302 4: Integrating disparate services 304 4.1 The service model 306 The basic service model uses a common data model, a common set of schema, 307 and allows the use of different access protocols to access a CIP server. A 308 large number of additions to the 2.0 protocol are made to do this work. 310 4.1 Integration of data models 312 The basic data model for most of the existing directory services is essentially 313 the same, a set of templates or object classes which are composed of attribute 314 value pairs. Therefore integration of the data models should not prove too 315 difficult. 317 4.2 Integration of schema 319 The various protocols use different attribute names for attributes which 320 typically contain the same data. Since the common indexing protocol must 321 provide a uniform index for these protocols, the attributes from the various 322 protocols must be normalized. The protocol achieves this by mapping the 323 various schema into a single attribute set. The CIP server is responsible for 324 creating the URLs necessary to search the next server in the mesh. 326 4.3 Using different protocols to access the CIP service 328 As this document is presently constituted, one can use many protocols to 329 access a CIP server, but the client must use the CIP attribute names when 330 speaking to a CIP server. This issue will be debated on the mailing list. 332 5: Protocol Specification for the Index Service: 334 The syntax for each protocol component is listed below. In addition, each 335 section contains a listing of which of these attributes is required and 336 optional for each of the components. All timestamps must be in the format 337 YYYYMMDDHHMM+ZZZZ or YYYYMMDDHHMM-ZZZZ, using a 24 hour clock, where ZZZZ 338 indicates the difference between the local clock and GMT. 340 5.1. Data changed syntax 342 The data changed template look like this: 344 # DATA-CHANGED 345 Version-number: // version number of index service software, used to insure 346 // compatibility. Current value is 2.0 347 Time-of-latest-centroid-change: // time stamp of latest forward information 348 // change,GMT 349 Time-of-message-generation: // time when this message was generated, GMT 350 DSI: // Data set identifier. This uniquely identifies a given data set in case the 351 // server manages multiple logical data sets 352 Server-handle: // IANA unique identifier for this server 353 // Or Distinguished Name of the root of the subtree this server 354 // is responsible for. 355 Host-Name: // Host name of this server (current name) 356 Host-Port: // Port number of this server (current port) 357 Protocol: // Access protocol to use when speaking to this server 358 Best-time-to-poll: // For heavily used servers, this will identify when 359 // the server is likely to be lightly loaded 360 // so that response to the poll will be speedy, GMT 361 Authentication-type: // Type of authentication used by server, or NONE 362 Authentication-data: // data for authentication 363 # END // This line must be used to terminate the data changed message 365 Required/optional table 367 Version-Number REQUIRED 368 Time-of-latest-centroid-change REQUIRED 369 Time-of-message-generation REQUIRED 370 DSI OPTIONAL 371 Server-handle REQUIRED 372 Host-Name REQUIRED 373 Host-Port REQUIRED 374 Protocol REQUIRED 375 Best-time-to-poll OPTIONAL 376 Authentication-type OPTIONAL 377 Authentication-data OPTIONAL 379 5.2. Polling syntax 381 # POLL: 382 Version-number: // version number of poller's index software, used to 383 // insure compatibility 384 Charset: // specifies character set in which the centroid changes are to be 385 // transmitted. Must be one of ISO-8859-1 or UNICODE-1-1-UTF-8 386 DSI: // Data set identifier. Indicates which data set of multiple data sets 387 // should be indexed. 388 DSI-Description: // Human readable string about the data set 389 Type-of-poll: // type of forward data requested. CENTROID and QUERY 390 // are the only one currently defined 391 Poll-scope: // Selects bounds within which data will be returned. See note. 392 Start-time: // give me all the centroid changes starting at this time, GMT 393 End-time: // ending at this time, GMT 394 Template: // a standard template or object class name, or the keyword ALL, for a 395 // full update. 396 Field: // used to limit centroid update information to specific fields, 397 // is either a specific field name, a list of field names, 398 // or the keyword ALL 399 Starting-point: // location in the DIT or other hierarchical structure 400 // to start the index. If used, it implies that the entire subtree is 401 // indexed as well 402 Server-handle: // IANA unique identifier for the polling server. 403 // this handle may optionally be cached by the polled 404 // server to announce future changes 405 Host-Name: // Host name of the polling server. 406 Host-Port: // Port number of the polling server. 407 Relationship: // This field indicates the relationship which the poller 408 // bears to the pollee. Typical values might include 409 // 'Topology', 'Geographical", or "Administrative" 410 Description: // This field contains the DESCRIBE record of the 411 // polling server 412 Tokenization-type: // The tokenization algorithm used 413 // Can be one of: "TOKENS", "RECORDS" or "ATTRIBUTES". 414 // Default is "TOKENS", which means space-delimited values. 415 Options: // Can be used to request the WEIGHT, HANDLE, and/or HOST information 416 // for the returned values 417 Content-Transfer-Encoding: // What encoding type, standard values... 418 Authentication-type: // Type of authentication used by poller, or NONE 419 Authentication-data: // Data for authentication 420 # END // This line must by used to terminate the poll message 422 For poll type CENTROID, the allowable values for Poll Scope are 423 FULL and RELATIVE. Support of the FULL value is required, this provides a 424 complete listing of the centroid or other forward information. 425 RELATIVE indicates that these are the relative changes in the centroid 426 since the last report to the polling server. 428 The allowable values for OPTION are WEIGHT, HANDLE, and HOST. 429 Support for the HANDLE and HOST values are required. HANDLE indicates that each 430 attribute value must be listed with the server handle of the server from which 431 this value was obtained by the polled server; HOST indicates that each 432 attribute value must be listed with the host name and port number of the server 433 from which this value was obtained. WEIGHT is optional, and allows each value to 434 be assigned a relative weight according to a defined and specified weighting 435 scheme. This value is included for future clarification. Since a weighting 436 scheme will need to be identified, WEIGHT will take additional scheme 437 identifiers in a syntax to be determined. 439 For poll type QUERY, the allowable values for Poll Scope are a blank line, 440 which indicates that all records are to be returned, or a valid WHOIS++ query, 441 which indicates that just those records which satisfy the query are to be 442 returned. N.B. Security considerations may require additional authentication 443 for successful response to the Blank Line Poll Scope. This value has been 444 included for server replication. 446 As there are different types of tokenization available in future versions of 447 this protocol, and as there may well be organizations which wish to construct 448 servers which each index the same set of servers, but wish to do it in slightly 449 different fashions, the command POLLED-FOR can be used to determine all the 450 servers the current server polls. 452 Required/Optional Table 454 Version-Number REQUIRED, value is 2.0 455 Charset REQUIRED, values ISO-8859-1 and UNICODE-1-1-UTF-8 are required 456 DSI OPTIONAL 457 DSI-Description OPTIONAL 458 Type-Of-Poll REQUIRED, values CENTROID and QUERY are required 459 Poll-scope REQUIRED If Type-of-poll is CENTROID, FULL is required, 460 RELATIVE is optional 461 If Type-of-poll is QUERY, Blank line is required, 462 and WHOIS++-type queries are required 463 Start-time OPTIONAL 464 End-Time OPTIONAL 465 Template REQUIRED 466 Field REQUIRED 467 Starting-point OPTIONAL 468 Server-handle REQUIRED 469 Host-Name REQUIRED 470 Host-Port REQUIRED 471 Hierarchy OPTIONAL 472 Description OPTIONAL 473 Tokenization-Type REQUIRED, value TOKENS is required, RECORDS and 474 ATTRIBUTES are optional 475 Options OPTIONAL 476 Content-Tranfer-Encoding OPTIONAL. If not given, default is 8-bit 477 Available values are 8-bit, Quoted-Printable, 478 and Base64 479 Authentication-Type: OPTIONAL 480 Authentication-data: OPTIONAL 482 Example of a POLL command: 483 # POLL: 484 Version-number: 2.0 485 Charset: UNICODE-1-1-UTF-8 486 Type-of-poll: CENTROID 487 Poll-scope: FULL 488 Start-time: 199501281030+0100 489 Template: ALL 490 Field: ALL 491 Server-handle: BUNYIP01 492 Host-Name: services.bunyip.com 493 Host-Port: 7070 494 Hierarchy: Geographical 495 Tokenization-type: TOKENS 496 # END 498 5.3. Centroid change report 500 As the centroid change report contains nested multiply-occuring blocks, 501 each multiply occurring block is surrounded *in this paper* by curly 502 braces '{', '}'. These curly braces are NOT part of the syntax, they are 503 for identification purposes only. 505 The syntax of a Data: item is either a list of values (words or other phases, 506 depending on the tokenization value), one value per line, with 507 the syntax: 509 -word 510 + weight (if requested) 511 + server handle (if requested) 512 + host (if requested) 513 + port (if requested) 515 or the keyword: 517 * 519 The weight, handle, host, and port are not required, but are expected to be 520 used by advanced servers. The weight is the relative weight of the value 521 for weighting servers, and the handle, host, and port values are to indicate 522 from which host the polled server received the value. This allows a polling 523 server to construct direct pointers to the servers lower in the mesh rather 524 than adding an additional level of indirection. 526 The keyword ANY as the only item of a Data: list means that any value for 527 this field should be treated as a hit by the indexing server. 529 The field Any-field: needs more explanation than can be given in the body 530 of the syntax description below. It can take two values, True or False. If 531 the value is True, the pollee is indicating that there are fields in this 532 template which are not being exported to the polling server, but wishes to 533 treat as a hit. Thus, when the polling server gets a query which has a term 534 requesting a field not in this list for this template, the polling server 535 will treat that term as a 'hit'. If the value is False, the pollee is 536 indicating that there are no other fields for this template which should be 537 treated as a hit. This field is required because the basic model for the 538 WHOIS++ query syntax requires that the results of each search term be 'and'ed 539 together. This field allows polled servers to export data only for 540 non-sensitive fields, yet still get referrals of queries which contain 541 sensitive terms. 543 The attributes used by the polled server must also be mapped into the 544 attributes used by the CIP. This allows the specification of the creation 545 of the URLs to refer to the search on the final server. 547 # CENTROID-CHANGES 548 Version-number: // version number of pollee's index software, used to 549 // insure compatibility 550 Character-set: // Specifies which character set the data is in. Allowable values 551 // are ISO-8859-1 and UNICODE-1-1-UTF-8 552 Start-time: // change list starting time, GMT 553 End-time: // change list ending time, GMT 554 Server-handle: // IANA unique identifier of the responding server 555 Hop-Count: // One more than the largest value the polled server has received 556 // when polling other servers. If the polled server is a leaf , 557 // server, hop-count should be zero. The current maximum value 558 // (Feb. 95) is 8. 559 Options: // Which options the polled server was able to satisfy. Values are 560 // WEIGHT, HANDLE, and HOST 561 Authentication-type: // Type of authentication used by pollee, or NONE 562 Authentication-data: // Data for authentication 563 Compression-type: // Type of compression used on the data, or NONE 564 Size-of-compressed-data: // size of compressed data if compression is used 565 Protocol: // Protocol spoken by the polled server. Used to construct the URLs 566 // for referrals. One of WHOIS++, LDAP, CCSO, CIP 567 Operation: // One of 3 keywords: ADD, DELETE, FULL 568 // ADD - add these entries to the centroid for this server 569 // DELETE - delete these entries from the centroid of this 570 // server 571 // FULL - the full centroid as of end-time follows 572 Tokenization-type: // The tokenization algorithm used 573 // Can be one of: "TOKENS", "RECORDS" or "ATTRIBUTES". 574 // Default is "TOKENS". 575 Token: // Character(s) used in the tokenization algorithm 576 { // The multiply occurring template block starts here 577 # BEGIN TEMPLATE 578 Template: // a standard template name 579 // May be repeated to indicate that the CIP template name 580 // should map to all of these 581 CIP-Template-Name: // What template name this maps to in the CIP 582 Any-field: // TRUE or FALSE. See beginning of 6.3 for explanation. 583 { // the template contains multiple field blocks 584 # BEGIN FIELD 585 Field: // a field name within that template 586 // May be repeated to indicate that the CIP attribute name should 587 // map to all of these 588 CIP-Field-Name: // The attribute name used by CIP 589 Value-rewrite-method: // specifies how values should be rewritten for the 590 // final query to the end server 591 Content-Transfer-Encoding: // If existing, one of Base64 or Quoted-Printable 592 Data: // Either the keyword *, or 593 // the value list itself, one per line, cr/lf terminated, 594 // each line starting with a dash character ('-'). 595 // Each value may be optionally followed by other lines containing 596 // weight, handle, and/or host information, these other lines begin 597 // with the plus sign (+) and a tag which states which information 598 // is placed on this line. Allowable tags are , , , 599 // and 600 # END FIELD 601 } // the field ends with END FIELD 602 # END TEMPLATE 603 } // the template block ends with END TEMPLATE 604 # END CENTROID-CHANGES // This line must be used to terminate the centroid 605 // change report 607 For each template, all fields must be listed, or queries will not be 608 referred correctly. 610 Required/Optional table 612 Version-number REQUIRED, value is 2.0 613 Character-set REQUIRED, values of ISO-8859-1 and UNICODE-1-1-UTF-8 must be 614 supported 615 Start-time REQUIRED (even if the centroid type is FULL) 616 End-time REQUIRED (even if the centroid type is FULL) 617 Server-handle REQUIRED 618 Hop-Count REQUIRED 619 Options OPTIONAL If the polling server has requested options a polled 620 server is unable to satisfy, an error message will be 621 generated 622 Authentication-Type OPTIONAL 623 Authentication-Data OPTIONAL 624 Compression-type OPTIONAL 625 Size-of-compressed-data OPTIONAL (even if compression is used) 626 Protocol REQUIRED 627 Operation REQUIRED, Support for all three values is required 628 Tokenization-type REQUIRED 629 Token OPTIONAL, if missing the default is blanks and newlines 630 # BEGIN TEMPLATE REQUIRED 631 Template REQUIRED 632 CIP-Template-Name REQUIRED 633 Any-field REQUIRED 634 # BEGIN FIELD REQUIRED 635 Field REQUIRED 636 CIP-Field-Name REQUIRED 637 Value-Rewrite-Method OPTIONAL 638 Content-Transfer-Encoding OPTIONAL, same values as above 639 Data REQUIRED 640 # END FIELD REQUIRED 641 # END TEMPLATE REQUIRED 642 # END CENTROID-CHANGES REQUIRED 644 Example: 646 # CENTROID-CHANGES 647 Version-number: 2.0 648 Charset: UNICODE-1-1-UTF-8 649 Start-time: 197001010000+0100 650 End-time: 199503012336+0100 651 Server-handle: BUNYIP01 652 Hop-Count: 3 653 Tokenization-Type: TOKENS 654 # BEGIN TEMPLATE 655 Template: USER 656 CIP-Template-Name: USER 657 Any-field: TRUE 658 # BEGIN FIELD 659 Field: Name 660 CIP-Field-Name: Name 661 Data: Patrik 662 + NADA01 663 + ui.nada.kth.se 664 + 7070 665 -Faltstrom 666 + NADA01 667 + ui.nada.kth.se 668 + 7070 669 -Malin 670 -Linnerborg 671 # END FIELD 672 # BEGIN FIELD 673 Field: Email 674 CIP-Field-Name: Email 675 Data: paf@bunyip.com 676 -malin.linnerborg@paf.se 677 # END FIELD 678 # END TEMPLATE 679 # END CENTROID-CHANGES 681 4.4 QUERY and POLLEES responses 683 The response to a QUERY command is done in WHOIS++ format. 685 4.5. Query referral 687 # SERVERS-TO-ASK 688 Version-number: // version number of index software, used to insure 689 // compatibility 690 Body-of-Query: // the original query goes here 691 URL: // URL of the interaction required to issue this query to the next 692 // server 693 Priority: // Relative priority of this server among all replicas 695 # END SERVERS-TO-ASK 697 Required/Optional table 699 Version-number REQUIRED, value should be 2.0 700 Body-of-query OPTIONAL 701 URL REQUIRED 702 Priority OPTIONAL 704 5. Client-Server Interaction 706 Access can be made to a CIP server using most access protocols. As of this 707 writing, the attribute and template names used in the query must be those 708 used by the CIP protocol itself. 710 6: Reply Codes 712 In addition to the reply codes listed in [Deutsch 95] for the basic WHOIS++ 713 client/server interaction, the following reply codes are used by the 714 Common Indexing Protocol. 716 113 Requested method not available Unable to provide a requested tokenization, 717 compression, or transfer encoding method. 718 Contacted server will send requested data 719 in different format. 721 114 Requested option not available Unable to provide a requested option in 722 CENTROID-CHANGES. No options have been used 723 but raw data will be transmitted. 725 227 Update request acknowledged A DATA-CHANGED transmission has been accepted 726 and logged for further action. 728 503 Required attribute missing A REQUIRED attribute is missing in an 729 interaction. 731 504 Desired server unreachable The desired server is unreachable. 733 505 Desired server unavailable The desired server fails to respond to 734 requests, but host is still reachable. 736 7: References 738 [Deutsch 95] Deutsch, P., Patrik Faltstrom, Rickard Schoultz, and Chris Weider, 739 Architecture of the WHOIS++ Service, RFC 1835, Proposed Standard, March 1995 741 [Faltstrom 95] Faltstrom, Patrik, Rickard Schoultz, and Chris Weider, 742 "How to interact with a WHOIS++ mesh", RFC 1914, Proposed Standard, November 743 1995