idnits 2.17.1 draft-ietf-find-cip-mime-03.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-03-19) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 78 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAMEWORK' ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FIND Working Group J. Allen 3 Internet Draft WebTV Networks, Inc. 4 Michael Mealling 5 18 November 1998 Network Solutions, Inc. 6 Expires in six months 8 MIME Object Definitions for the 9 Common Indexing Protocol (CIP) 11 Status of this Memo 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 months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 The Common Indexing Protocol (CIP) is used to pass indexing 32 information from server to server in order to facilitate query 33 routing. The protocol is comprised of several MIME objects being 34 passed from server to server. This document describes the 35 definitions of those objects as well as the methods and 36 requirements needed to define a new index type. 38 1. Introduction 40 The Common Indexing Protocol (CIP) is used to pass indexes between 41 servers that combine multiple indexes and/or route queries based 42 on those indexes. The overall framework for the protocol is specified 43 in the CIP Framework document [FRAMEWORK]. This document should be 44 read within the context of that document as there are fundamental 45 concepts contained in the framework that are not fully explained 46 here. 48 Since there are several different ways to index a given database 49 there will be multiple types of indexes to pass. These indexes 50 may have different transport requirements, different ways of 51 specifying parameters, and different referral rules. These 52 different requirements are handled by encapsulating the indexes 53 within MIME wrappers in order to have a standardized way to specify 54 those different parameters. 56 Allen & Mealling [Page 1] 57 RFCXXXX MIME Definitions for CIP November 1998 59 Appendix A contains the actual MIME [RFC2046] registration templates 60 to be sent to the IANA for registration [RFC2048] as soon as this 61 document is accepted by the IESG. 63 This document uses language like SHOULD and SHALL that have special 64 meaning as specified in "Key words for use in RFCs to Indicate 65 Requirement Levels". [RFC2119] 67 2.0 CIP Transactions 69 Messages passed by CIP implementations over reliable transport 70 mechanisms fall into three categories: requests, responses and 71 results. All requests result in either a response or a result. 72 A result sent in response to a request must be interpreted as a 73 successful operation. 75 Requests, responses and results are formatted as MIME [RFC2046] 76 messages. The specific MIME types involved are defined below. 78 As with all MIME objects, CIP messages may be wrapped in a security 79 multipart package to provide authentication and privacy. The security 80 policy with respect to all messages is implementation defined, when 81 not explicitly discussed below. CIP implementors are strongly urged 82 to allow server administrators maximum configurability to secure 83 their servers against maliciously sent anonymous CIP messages. In 84 general, operations which can permanently change the server's state 85 in a harmful way should only take place upon receipt of a properly 86 signed message from a trusted CIP peer or administrator. Implementors 87 should provide appropriate auditing capabilities so that both 88 successful and failed requests can be tracked by the server 89 administrator. 91 Since these MIME objects can and will be sent over several different 92 protocols, body termination is specified by the transfer protocol. 93 New protocols are encouraged to use SMTP [RFC821] style body 94 termination. 96 Finally, since MIME objects can specify their own encoding, the 97 line-breaks contained within each body are defined by the encoding. 98 Thus, instead of specifying them as carriage-return and/or linefeed, 99 the identifier is used. Linebreaks in the headers and 100 separating the body from the headers follow existing standards. 102 2.1 Common syntactic definitions 104 There are certain syntactic elements common to all of the 105 CIP transactions. These include type, DSI and the Base-URI. 107 Allen & Mealling [Page 2] 108 RFCXXXX MIME Definitions for CIP November 1998 110 2.1.1 The "application/index" MIME type tree 112 Due to requirements in RFC2048 concerning objects that have the same 113 type but different syntaxes, CIP objects will use the 114 application/index tree but include "facets" [RFC2048] which extend 115 it as other types have done with respect to global elements and 116 vendor specific enhancements. Thus the tree is divided up into 117 the following branches: 119 application/index.cmd._command_ 120 application/index.response 121 application/index.obj._type_ 122 application/index.vnd._xxx_ 124 _command_ is a command as specified here. It contains 125 commands and their arguments. 127 _type_ identifies what type of CIP index object is contained 128 within the body. It is unique among all other reserved 129 types. Reserved types are those previously documented by other 130 CIP index object specifications, according to standard IETF 131 processes. 133 _xxx_ is an identifier specified by a vendor for use by 134 that vendor in operations specifically to do with indexes. 136 All of the above identifiers follow the rules in RFC2048 for 137 valid MIME types. In addition commands, responses and types are 138 limited by this document to consist of from 1 to 20 characters from 139 the set [a-zA-Z0-9-]; that is, all upper and lower case letters, all 140 digits, and the ASCII minus character (decimal 45). Though type 141 names may be specified case sensitively, they must be compared and 142 otherwise processed case insensitively. 144 Appendix A contains the registration template for the 145 application/index tree that will be sent to the IANA upon approval 146 by the IESG. 148 2.1.2 DSI 150 A dataset identifier is an identifier chosen from any part of the 151 ISO/CCITT OID space. The DSI uniquely identifies a given dataset 152 among all datasets indexed by CIP. 154 As currently defined, OID's are an unbounded sequence of unbounded 155 integers. While this creates an infinite numbering space, it presents 156 problems for implementors dealing with machines with finite 157 resources. To ease implementation, this document specifies an ASCII 158 encoding of the OID, and specifies limits which make implementation 159 easier. 161 Allen & Mealling [Page 3] 162 RFCXXXX MIME Definitions for CIP November 1998 164 For the purposes of interchange in CIP messages, an OID must conform 165 to the following rules: 167 dsi = integer *( "." integer) 168 integer = all-digits / (one-to-nine *all-digits) 169 one-to-nine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / 170 "8" / "9" 171 all-digits = "0" / one-to-nine 173 Under no circumstances shall the total length of the resulting string 174 exceed 255 characters. OID's which cannot, due to their length, 175 conform to these rules must not be used as CIP dataset identifiers. 177 An implementation must not attempt to parse the individual integers 178 unless it is prepared to handle arbitrary-length integers. Treating 179 the DSI as anything other than an opaque string of US-ASCII 180 characters is not recommended. 182 Two CIP DSI's are considered to match if both conform to the above 183 rules and every number matches. 185 2.1.3. Base-URI 187 CIP index objects carry base-URI's to facilitate referral generation 188 based on the index object. The base-URI parameter carries a 189 whitespace-delimited list of URL's. URL's are defined in RFC-1738. 190 The exact rules are as follows: 192 base-uri = genericurl *( 1*whitespace genericurl ) 193 whitespace = "" (decimal 32) / 194 "" (decimal 9) / 195 "" (decimal 13) / 196 "" (decimal 10) 197 genericurl = { as specified in RFC-1738, section 5 } 199 2.2 Response format 201 All requests must be followed by a response code, except in the 202 cases where a return path is unavailable. 204 The definition for this MIME type is: 206 MIME type name: application 207 MIME subtype name: index.response 208 Required parameters: code 209 Optional parameters: charset 210 Security considerations: (See Section 4) 212 The code parameter contains a 3 digit return code that denotes 213 the status of the last command. 215 Allen & Mealling [Page 4] 216 RFCXXXX MIME Definitions for CIP November 1998 218 The format of the body is such that the first line is interpreted 219 as the comment corresponding to the code. As with most response 220 codes this comment is intended for human consumption and may not 221 exist and must not be depended on by the protocol. Subsequent lines 222 in the body are reserved for each response to define. In the case 223 where the comment is not given the first must be an empty line. 225 body = comment linebreak payload 226 comment = { any text } 227 linebreak = (decimal 13) (decimal 10) 228 payload = { any text } 230 The charset parameter has its normal MIME meaning. Below are several 231 examples: 233 [begin MIME] 234 Content-type: application/index.response; code=220 236 CIP Server v1.0 ready! 237 [end MIME] 239 [begin MIME] 240 Content-type: application/index.response; code=500 242 MIME formatting problem 243 [end MIME] 245 [begin MIME] 246 Content-type: application/index.response; code=520 248 249 [end MIME] 251 While the responses described in this document do not utilize the 252 rest of the lines in the body of a response implementors should 253 take care to not disallow it in the future. A good example would 254 be a message specifying that a poll request did not contain required 255 attributes. This message might look like this: 257 [begin MIME] 258 Content-type: application/index.response; code=502 260 Request is missing required CIP attributes 261 Missing-Attribute: attribute1 262 Missing-Attribute: attribute2 263 Missing-Attribute: attribute3 264 [end MIME] 266 The meaning of the various digits in the response codes is discussed 267 in RFC-821, Appendix E. 269 See Appendix B for a list of the valid response codes. 271 Allen & Mealling [Page 5] 272 RFCXXXX MIME Definitions for CIP November 1998 274 2.3 Command format 276 A CIP command either initiates an index transfer, interrogates the 277 state of the receiver-CIP (or the server's participation in the 278 mesh), or changes the state of the server (or the server's place in 279 the mesh). 281 CIP commands are sent as a MIME message of type 282 "application/index.cmd._command_". The definition for this MIME type 283 tree follows: 285 MIME type name: application 286 MIME subtype name: index.cmd._command_ 287 Optional parameters: type, dsi 288 Security considerations: (See Section 4) 290 The format of the body is defined by each command. A general 291 attribute/value pair orientation is preserved throughout the 292 following specified commands. Those developing future command 293 should attempt to maintain that orientation but are not required 294 to do so. 296 In the following sections, the server's response for each possible 297 value for "command" is defined. Note that the parameters listed as 298 optional above are only optional with respect to the generic MIME 299 form. The optional parameters are only optional with respect to MIME 300 parsing. If one or more of the parameters needed to fulfill a 301 command is missing, a response code of 502 is returned. 303 Extra optional parameters which are unrecognized must be silently 304 ignored. 306 2.3.1 No-operation 308 Command Name: application/index.cmd.noop 309 Required parameters: (none) 311 A CIP command with the "command" parameter set to "noop" must be 312 acknowledged with response type code 200 (command OK, no response 313 forthcoming). 315 This command must not require a signed MIME object. Implementations 316 should accept commands which have been validly signed. 318 Example: 320 [begin MIME] 321 Content-type: application/index.cmd.noop 323 [end MIME] 325 Note the lack of a body but how the pair is still 326 preserved after the Content-type header. 328 Allen & Mealling [Page 6] 329 RFCXXXX MIME Definitions for CIP November 1998 331 2.3.2 Poll 333 Request Name: application/index.cmd.poll 334 Required parameters: type, dsi 336 The "poll" command is used by a poller to request the transfer of an 337 index object. It requires the following parameters: 339 type: The index object type requested 340 dsi: The dataset which the index should cover 342 If there are no index objects available for a given DSI, or the 343 receiver-CIP does not support a given index object type, the 344 receiver-CIP must respond with response code 200, (successful, no 345 response forthcoming). Otherwise, the response code must be 201 346 (successful, response is forthcoming). 348 The security policy for polling commands is wholly implementation 349 defined. Implementations may be configured to accept or reject 350 anonymous poll commands. 352 Example: 354 [begin MIME] 355 Content-type: application/index.cmd.poll; type="simple"; 356 dsi= "1.3.5.7.9" 358 Template: contact name address phone 359 Start-time: Fri May 30 14:25:30 EDT 1997 360 End-time: Sat May 31 14:25:30 EDT 1997 361 [end MIME] 363 2.3.3 DataChanged 365 Request Name: application/index.cmd.datachanged 366 Required parameters: type, dsi 368 The "datachanged" command is used by a pollee to notify a poller that 369 the data within an index has changed. It requires the following 370 parameters: 372 type: The index object type requested 373 dsi: The dataset which the index should cover 375 If there are no index objects available for a given DSI, or the 376 receiver-CIP does not support a given index object type, the 377 receiver-CIP must respond with response code 200, (successful, no 378 response forthcoming). Otherwise, the response code must be 201 379 (successful, response is forthcoming). 381 The body of a DataChanged command is formatted as a simple set of 382 attribute value pairs following the rules of RFC822. The actual 383 attributes and values allowed are defined by the index type 384 specification. 386 Allen & Mealling [Page 7] 387 RFCXXXX MIME Definitions for CIP November 1998 389 The security policy for DataChanged commands is wholly 390 implementation defined. Implementations may be configured to 391 accept or reject anonymous DataChanged commands. 393 Example: 395 [begin MIME] 396 Content-type: application/index.cmd.datachanged; 397 type="simple"; dsi= "1.3.5.7.9" 399 Time-of-latest-change: Fri May 30 14:25:30 EDT 1997 400 Time-of-message-generation: Fri May 30 14:25:30 EDT 1997 401 Host-Name: cip.rwhois.net 402 Host-Port: 4322 403 Protocol: RWhois2.0 404 [end MIME] 406 2.3.4 Additional Requests 408 The requests specified above are those required to implement a simple 409 mesh. It is expected that other requests will be developed to handle 410 issues of mesh-management and statistics gathering requests. At this 411 point this is an area of additional work. Specifically more work is 412 needed in the area of mesh management as meshes will tend to be 413 organized around the characteristics of their index type. 415 2.4. Index Object format 417 In reply to the "poll" command, a server may choose to send one or 418 more index objects. Regardless of the number of index objects 419 returned, the response must take the form of a MIME multipart/mixed 420 message. Each part must itself be a MIME object of type 421 "application/index.obj._type_". The definition for this type follows: 423 MIME type name: application 424 MIME subtype name: index.obj._type_ 425 Required parameters: dsi, base-uri 426 Optional parameters: none 427 Security considerations: (See Section 4) 429 As previously described, each index object is of a particular type. 430 This type is specified in the MIME subtype name since some types 431 may have a different syntax. 433 The required parameters are to be used as follows: 435 DSI: The DSI is a string which globally uniquely 436 identifies the dataset from which the index was 437 created. 439 base-URI: One or more URI's will form the base of 440 any referrals created based upon this index 441 object. 443 Allen & Mealling [Page 8] 444 RFCXXXX MIME Definitions for CIP November 1998 446 3. Index Type Definition Requirements 448 Because of the need for application domain specific indices, CIP 449 index objects are abstract; they must be defined by a separate 450 specification. The basic protocols for moving index objects are 451 widely applicable, but the specific design of the index, and the 452 structure of the mesh of servers which pass a particular type of 453 index is dependent on the application domain. While companion 454 documents will describe index objects, there is a set of base 455 requirements and questions those documents must address. This is to 456 ensure that the base assumptions that the CIP protocol makes about 457 its indexes are actually expressible within the index. 459 Since each type is a MIME type all its own, registration of 460 new types follows the standard registration policies specified 461 in RFC2048. 463 3.1 Type specific requests 465 Any index type definition must address the type specific bodies of 466 the Poll and DataChanged requests. All parameters included in the 467 body must be specified. 469 3.2 The index.obj parameters 471 3.2.1 Type 473 See the above definitions for allowed values for type. 475 A new name must be assigned when any changes to the document 476 describing the index object type are not completely backwards 477 compatible. 479 3.2.2 DSI 481 Another attribute is the "DSI", or Dataset Identifier, which 482 uniquely identifies the dataset from which the index was created. 483 The index specification should define the policies for how the DSI 484 is generated. This includes the concept of what a data-set means for 485 the given index. 487 3.2.3. Base-URI 489 An attribute of the index object which is crucial for generating 490 referrals is the "Base-URI". The URI (or URI's) contained in this 491 attribute form the basis of any referrals generated based on this 492 index block. The URI is also used as input during the index 493 aggregation process to constrain the possible types of aggregation. 494 This use of the Base-URI is used to deal with meshes that support 495 multiple protocols. 497 Thus, an index specification should define how the Base-URI applies 498 to the underlying index and how it is changed during the 499 aggregation process. 501 Allen & Mealling [Page 9] 502 RFCXXXX MIME Definitions for CIP November 1998 504 3.3 Aggregation 506 All index object specifications must address the issue of 507 aggregation. This is the method by which an index server takes 508 two or more indexes and combines them into one index to be passed 509 on. It is not required that a given index-type aggregate. If it does 510 not it must explicitly address the reasons why and what affect that 511 has on scalability. 513 If a given index does aggregate, the algorithm for that aggregation 514 must be given. It must also address how that algorithm affects mesh 515 organization and scalability. 517 Index object document authors should remember that any kind of 518 aggregation should be performed without compromising the 519 ability to correctly route queries while avoiding excessive numbers 520 of missed results. The acceptable likelihood of false negatives must 521 be established on a per-application-domain basis, and is controlled 522 by the granularity of the index and the aggregation rules defined for 523 it by the particular specification. 525 Nothing in these documents specifically disallows aggregation rules 526 that deal with different index object types. This type of 527 heterogeneous mesh is difficult to formulate at best and thus is not 528 covered by these documents. If document authors wish to attempt such 529 a mesh they should be aware that it is considered an ill understood 530 concept that contains many pitfalls for the mesh builder. 532 3.4 Referral Generation Semantics 534 Since the method by which a client navigates the mesh is by 535 referrals, the document must address how a given access protocol 536 generates a referral from the index. Authors should pay particular 537 attention to the case where an index is accessed by different 538 protocols and the interaction between them. For example, an index 539 that supports referrals being generated for both RWhois and LDAP 540 must understand that one uses a Distinguished Name while the other 541 doesn't. The impacts of these differences on the referral should 542 be clear. 544 3.5 Matching Semantics 546 In order to generate a referral the decision of whether or not to do 547 so must be handled by the access protocol. The semantics surrounding 548 this decision have a large impact on the efficiency of searches as 549 well as the requirements on aggregation. Thus, index specification 550 authors must be very clear about how a match is determined. 552 3.6 Security Considerations 554 As is customary with Internet protocol documentation, a brief review 555 of security implications of the proposed object must be included. 556 This section may need to do little more than echo the considerations 557 expressed in this document's Security Considerations section. 559 RFCXXXX MIME Definitions for CIP November 1998 561 3.7 Optional Coverage 563 Because indexing algorithms, stop-lists, and data reduction 564 technologies are considered by some index object designers to be 565 proprietary, it is not necessary to discuss the process used to 566 derive indexing information from a body of source material. When 567 proprietary indexing technologies are used in a public mesh, all CIP 568 servers in the mesh should be able to parse the index object (and 569 perform aggregation operations, if necessary), though not all of them 570 need to be able to create these proprietary indices from source data. 572 Thus, index object designers may choose to remain silent on the 573 algorithms used for the generation of indices, as long as they 574 adequately document how to participate in a mesh of servers passing 575 these proprietary indices. 577 Designers should also seriously consider including useful examples of 578 source data, the generated index, and the expected results from 579 example matches. When the aggregation algorithm is complex, it is 580 recommended that a table showing two indices and the resultant 581 aggregate index be included. 583 4. Security Considerations 585 Security considerations come into play in at least the following two 586 scenarios. Indexing information can leak undesirable amounts of 587 proprietary information, unless carefully controlled. At a more 588 fundamental level, the CIP protocol itself requires external 589 security services to operate in a safe manner. Both topics are 590 covered below. 592 4.1 Secure Indexing 594 CIP is designed to index all kinds of data. Some of this data might 595 be considered valuable, proprietary, or even highly sensitive by the 596 data maintainer. Take, for example, a human resources database. 597 Certain bits of data, in moderation, can be very helpful for a 598 company to make public. However, the database in its entirety is a 599 very valuable asset, which the company must protect. Much experience 600 has been gained in the directory service community over the years as 601 to how best to walk this fine line between completely revealing the 602 database and making useful pieces of it available. 604 Another example where security becomes a problem is for a data 605 publisher who would like to participate in a CIP mesh. The data that 606 publisher creates and manages is the prime asset of the company. 607 There is a financial incentive to participate in a CIP mesh, since 608 exporting indices of the data will make it more likely that people 609 will search your database. (Making profit off of the search activity 610 is left as an exercise to the entrepreneur.) Once again, the index 611 must be designed carefully to protect the database while providing a 612 useful synopsis of the data. 614 RFCXXXX MIME Definitions for CIP November 1998 616 One of the basic premises of CIP is that data providers will be 617 willing to provide indices of their data to peer indexing servers. 618 Unless they are carefully constructed, these indices could constitute 619 a threat to the security of the database. Thus, security of the data 620 must be a prime consideration when developing a new index object 621 type. The risk of reverse engineering a database based only on the 622 index exported from it must be kept to a level consistent with the 623 value of the data and the need for fine-grained indexing. 625 Since CIP is encoded as MIME objects, MIME security solutions 626 should be used whenever possible. Specifically when dealing with 627 security between index servers. 629 4.2 Protocol Security 631 CIP protocol exchanges, taking the form of MIME messages, can be 632 secured using any technology available for securing MIME objects. In 633 particular, use of RFC-1847's Security Multiparts are recommended. A 634 solid application of RFC-1847 using widely available encryption 635 software is PGP/MIME, RFC-2016. Implementors are encouraged to 636 support PGP/MIME, as it is the first viable application of the MIME 637 Security Multiparts architecture. As other technologies become 638 available, they may be incorporated into the CIP mesh. 640 If an incoming request does not have a valid signature, it must be 641 considered anonymous for the purposes of access control. Servers may 642 choose to allow certain requests from anonymous peers, especially 643 when the request cannot cause permanent damage to the local server. 644 In particular, answering anonymous poll requests encourages index 645 builders to poll a server, making the server's resources better 646 known. 648 The explicit security policy with respect to incoming requests is 649 outside the scope of this specification. Implementors are free to 650 accept or reject any request based on the security attributes of the 651 incoming message. When a request is rejected due to authentication 652 reasons, a response code from the 530 series must be issued. 654 Acknowledgments 656 Thanks to the many helpful members of the FIND working group for 657 discussions leading to this specification. 659 Specific acknowledgment is given to Jeff Allen formerly of Bunyip 660 Information Systems. His original version of these documents helped 661 enormously in crystallizing the debate and consensus. Most of the 662 actual text in this document was originally authored by Jeff. 664 RFCXXXX MIME Definitions for CIP November 1998 666 Author's Address 668 Jeff R. Allen Michael Mealling 669 246 Hawthorne St. Network Solutions, Inc. 670 Palo Alto, CA 94301 505 Huntmar Park Drive 671 USA Herndon, VA 22070 673 Phone: +1-1-650-323-3456 Phone: (703) 742-0400 674 EMail: jeff.allen@acm.com Email: michael.mealling@RWhois.net 676 References 678 [FRAMEWORK] 679 Allen, J. and M. Mealling, "The Architecture of the Common 680 Indexing Protocol (CIP)", RFC XXX, IETF FIND WG, June 9, 1997. 682 [RFC2046] 683 Freed, N., and N. Borenstein, "Multipurpose Internet Mail 684 Extensions (MIME) Part Two: Media Types", RFC 2046, 685 Innosoft, First Virtual Holdings, January 1996. 687 [RFC2048] 688 Freed, N., Klensin, J., and J. Postel, "Multipurpose 689 Internet Mail Extensions (MIME) Part Four: MIME 690 Registration Procedures", RFC 2048, Innosoft, MCI, 691 ISI, January 1996. 693 [RFC2119] 694 Bradner, S., "Key words for use in RFCs to Indicate Requirement 695 Levels", RFC 2119, Harvard University, March 1997. 697 [RFC821] 698 Postel, J., "SIMPLE MAIL TRANSFER PROTOCOL", RFC 821, ISI, 699 August 1992. 701 Appendix A: Media Type Registration Templates 703 The following templates will be sent to the IANA for registration as 704 soon as this document is accepted by the IESG. 706 Index tree 708 To: ietf-types@iana.org 709 Subject: Registration of MIME media type tree application/index 711 MIME media type name: application 713 MIME subtype name: index 715 Required parameters: none 717 Optional parameters: none 719 Encoding considerations: none 721 RFCXXXX MIME Definitions for CIP November 1998 723 Security considerations: 725 Section 4 of this document should be copied here. 727 Interoperability considerations: 729 Published specification: 730 This draft will be referenced here once it has been approved 731 by the IESG. 733 Applications which use this media type: 734 This media type is used to contain information about indices 735 and how they inter-operate to form meshes of index servers. 737 Additional information: 738 This media type is not a standalone type. It is the top level 739 of a tree similar to the vnd or prs trees specified in 740 Section 2.1 of RFC2048. There are four specified branches 741 to this tree: 742 application/index.cmd 743 application/index.response 744 application/index.obj 745 application/index.vnd 747 Each of these branches is a tree in its own right with 748 types registered below them. See those registrations for 749 more information on the types allowed below those branches. 751 Person & email address to contact for further information: 753 Intended usage: LIMITED USE 755 Author/Change controller: 757 Command tree 759 To: ietf-types@iana.org 760 Subject: Registration of MIME media type application/index.cmd 762 MIME media type name: application 764 MIME subtype name: index.cmd 766 Required parameters: none 768 Optional parameters: none 770 Encoding considerations: none 772 Security considerations: 774 Section 4 of this document should be copied here. 776 RFCXXXX MIME Definitions for CIP November 1998 778 Interoperability considerations: 780 Implementors should handle unknown commands gracefully. 782 Published specification: 784 This internet draft should be referenced once it has been 785 approved by the IESG. 787 Applications which use this media type: 789 This media type is the top of a tree of media types that 790 express commands between hosts that exchange indices 791 for the purpose of routing referrals. 793 Additional information: 795 This media type is not a standalone type. It is the 796 top of a tree similar to the vnd and prs trees specified 797 in Section 2.1 of RFC2048. Types registered within this 798 tree are limited to being commands as specified in 799 the document(s) referenced in the "Published specifications" 800 section. 802 Person & email address to contact for further information: 804 Intended usage: LIMITED USE 806 Author/Change controller: 808 Response tree 810 To: ietf-types@iana.org 811 Subject: Registration of MIME media type application/index.response 813 MIME media type name: application 815 MIME subtype name: index.response 817 Required parameters: code 819 Optional parameters: none 821 Encoding considerations: none 823 Security considerations: 825 Section 4 of this document should be copied here. 827 Interoperability considerations: 829 Implementors should handle unknown responses gracefully 830 RFCXXXX MIME Definitions for CIP November 1998 832 Published specification: 834 This Internet draft should be referenced once it has been 835 approved by the IESG. 837 Applications which use this media type: 839 This media type is used to encode responses to CIP commands 840 passed between hosts that exchange indices for the purpose 841 of routing referrals. 843 Additional information: 845 This media type _is_ a standalone type. The code parameter 846 contains the specific response code as specified by 847 Appendix B of the specification document. 849 Person & email address to contact for further information: 851 Intended usage: LIMITED USE 853 Author/Change controller: 855 Index Object tree 857 To: ietf-types@iana.org 858 Subject: Registration of MIME media type application/index.obj 860 MIME media type name: application 862 MIME subtype name: index.obj 864 Required parameters: type, dsi, base-uri 866 Optional parameters: none 868 Encoding considerations: none 870 Security considerations: 872 Section 4 of this document should be copied here. 874 Interoperability considerations: 876 Implementors should handle unknown index objects 877 according to rules specified in the published 878 specification. 880 Published specification: 882 This Internet draft should be referenced once it has been 883 approved by the IESG. 885 RFCXXXX MIME Definitions for CIP November 1998 887 Applications which use this media type: 889 This media type is the top of a tree of media types that 890 express indexes that are exchanged between hosts that 891 operate within a referral mesh. 893 Additional information: 895 This media type is not a standalone type. It is the 896 top of a tree similar to the vnd and prs trees specified 897 in Section 2.1 of RFC2048. Types registered within this 898 tree are limited to being representations of indexes 899 that contain some summary of the data found in some 900 database and is used to generate referrals as specified 901 in the above specified publication. 903 Person & email address to contact for further information: 905 Intended usage: LIMITED USE 907 Author/Change controller: 909 Vendor tree 911 To: ietf-types@iana.org 912 Subject: Registration of MIME media type application/index.vnd 914 MIME media type name: application 916 MIME subtype name: index.vnd 918 Required parameters: none 920 Optional parameters: none 922 Encoding considerations: none 924 Security considerations: 926 Section 4 of this document should be copied here. 928 Interoperability considerations: 930 Implementors should handle unknown objects gracefully. 932 Published specification: 934 This Internet draft should be referenced once it has been 935 approved by the IESG. 937 Applications which use this media type: 939 This media type is the top of a tree of media types that 940 express vendor specific extensions to the framework 941 specified in the published specifications. 943 RFCXXXX MIME Definitions for CIP November 1998 945 Additional information: 947 This media type is not a standalone type. It is the 948 top of a tree similar to the vnd and prs trees specified 949 in Section 2.1 of RFC2048. Types registered within this 950 tree are limited to being vendor specific extensions to 951 the CIP framework as specified in the publications. 952 Any registrations within this tree are still limited to 953 dealing with indexes, meshes and referrals. 955 Person & email address to contact for further information: 957 Intended usage: LIMITED USE 959 Appendix B: Response Codes 961 The meaning of the various digits in the response codes is discussed 962 in RFC-821, Appendix E. 964 The following response codes are defined for use by CIPv3 servers. 965 Implementors must use these exact codes; undefined codes should be 966 interpreted by CIP servers as fatal protocol errors. Instead of 967 defining new codes for unforeseen situations, implementors must adapt 968 one of the given codes. The implementation should attach a useful 969 alternative comment to the reused response code. 971 Code Suggested description text 972 Sender-CIP action 973 -------------------------------------------------------- 974 220 Initial server banner message 976 300 Requested CIP version accepted 977 Continue with CIP transaction, in the specified 978 version. 980 222 Connection closing (in response to sender-CIP close) 981 Done with transaction. 983 200 MIME request received and processed 984 Expect no output, continue session (or close) 986 201 MIME request received and processed, output follows 987 Read a response, delimited by SMTP-style message 988 delimiter. 990 400 Temporarily unable to process request 991 Retry at a later time. May be used to indicate 992 that the server does not currently have the 993 resources available to accept an index. 995 500 Bad MIME message format 996 Retry with correctly formatted MIME request. 998 501 Unknown or missing request in application/index.cmd 999 Retry with correct CIP command. 1001 RFCXXXX MIME Definitions for CIP November 1998 1003 502 Request is missing required CIP attributes 1004 Retry with correct CIP attributes. 1006 520 Aborting connection for some unexpected reason 1007 Retry and/or alert local administrator. 1009 530 Request requires valid signature 1010 Sign the request, if possible, and retry. 1011 Otherwise, report problem to the administrator. 1013 531 Request has invalid signature 1014 Report problem to the administrator. 1016 532 Cannot check signature 1017 Alert local administrator, who should cooperate with 1018 remote administrator to diagnose and resolve the 1019 problem. (Probably missing a public key.)