MIME Object Definitions for the Common Indexing Protocol (CIP)
Extracted elements (28)
Aggregation must not compromise the ability to correctly route queries while avoiding excessive false negatives. The acceptable likelihood of false negatives must be established per application domain, controlled by index granularity and aggregation rules. Heterogeneous mesh aggregation across different index types is considered ill-understood and is not covered.
Implementations must not attempt to parse individual DSI integers unless prepared to handle arbitrary-length integers; treating a DSI as anything other than an opaque US-ASCII string is not recommended. This avoids integer overflow issues on resource-constrained machines.
Servers may choose to allow certain requests from anonymous peers, especially when the request cannot cause permanent damage. Answering anonymous poll requests encourages index builders to discover the server's resources. The explicit security policy for incoming requests is outside the scope of the specification.
Since CIP MIME objects can be sent over multiple transport protocols, body termination is specified by the transfer protocol rather than the MIME object itself. New protocols are encouraged to use SMTP-style (RFC 821) body termination.
A new index type name must be assigned whenever changes to the index object type specification are not completely backwards compatible.
A noop command must be acknowledged with response code 200 (command OK, no response forthcoming). The noop command must not require a signed MIME object, though implementations should accept validly signed noop commands.
All CIP requests must be followed by a response code, except when a return path is unavailable.
All index object specifications must address aggregation: either providing the algorithm by which two or more indexes are combined, or explicitly explaining why aggregation is not supported and the impact on scalability.
Every index type definition document must address the type-specific bodies of the Poll and DataChanged requests, specifying all parameters included in the body.
Extra optional parameters that are unrecognized must be silently ignored by the receiver.
If no index objects are available for the requested DSI or the receiver-CIP does not support the requested type, the receiver-CIP must respond with code 200; otherwise it must respond with code 201 (response forthcoming).
Implementors must use the exact response codes defined in Appendix B; undefined codes should be interpreted as fatal protocol errors. Instead of defining new codes for unforeseen situations, implementors must adapt one of the given codes and attach an alternative comment.
In response to a poll, if one or more index objects are returned, the response must take the form of a MIME multipart/mixed message, with each part being an application/index.obj.<type> MIME object.
Under no circumstances shall the total length of a DSI string exceed 255 characters; OIDs that cannot conform to this limit must not be used as CIP dataset identifiers.
When a CIP request is rejected due to authentication or authorization reasons, a response code from the 530 series must be issued (530 = requires valid signature, 531 = invalid signature, 532 = cannot check signature).
Appendix B defines the CIP response code set: 200 (request processed, no output), 201 (request processed, output follows), 220 (server banner), 222 (connection closing), 300 (CIP version accepted), 400 (temporarily unable), 500–502 (bad format/unknown command/missing attributes), 520 (aborting), 530–532 (signature-related failures).
CIP commands are sent as application/index.cmd.<command> MIME messages. The type and dsi parameters are optional with respect to MIME parsing but required by specific commands; missing required parameters result in response code 502.
CIP defines four branches of the application/index MIME type tree: application/index.cmd.<command> for commands, application/index.response for responses, application/index.obj.<type> for index objects, and application/index.vnd.<xxx> for vendor extensions. Type names are case-insensitive for comparison but limited to 1–20 characters from [a-zA-Z0-9-].
Index objects use the application/index.obj.<type> MIME type with required parameters dsi (globally unique dataset identifier) and base-uri (one or more URIs forming the base for referral generation). The type in the MIME subtype name distinguishes syntactically different index formats.
The application/index.response MIME type encodes CIP responses. Its required parameter 'code' contains a 3-digit return code; the optional 'charset' parameter has its normal MIME meaning. The body's first line is a human-readable comment, followed by a linebreak and optional payload.
The datachanged command (application/index.cmd.datachanged) requires parameters 'type' and 'dsi'. It is used by a pollee to notify a poller that index data has changed. The body is formatted as RFC 822 attribute-value pairs, with allowed attributes defined by the index type specification.
The poll command (application/index.cmd.poll) requires parameters 'type' (index object type) and 'dsi' (target dataset). It is used by a poller to request transfer of an index object from a receiver-CIP.
RFC 2652 registers five MIME media types with IANA: application/index (top-level tree), application/index.cmd (command subtree), application/index.response (responses, required parameter: code), application/index.obj (index objects, required parameters: type, dsi, base-uri), and application/index.vnd (vendor extensions). All are designated LIMITED USE.
CIP indexes can leak proprietary or sensitive data if not carefully constructed. The risk of reverse-engineering a database from its exported index must be kept to a level consistent with the data's value; security must be a prime consideration when developing any new index object type.
CIP protocol exchanges should be secured using RFC 1847 Security Multiparts. PGP/MIME (RFC 2016) is recommended as the first viable application of that architecture. Incoming requests without a valid signature must be treated as anonymous for access control purposes.
A DSI (Dataset Identifier) is an ASCII-encoded OID: dsi = integer *('.' integer), where leading zeros are forbidden except for the value '0'. The total encoded string must not exceed 255 characters.
The Base-URI parameter carries a whitespace-delimited list of RFC-1738 URLs: base-uri = genericurl *(1*whitespace genericurl), where whitespace is space (32), tab (9), CR (13), or LF (10).
The response body format is: body = comment linebreak payload, where linebreak = CR (13) LF (10). The comment is intended for human consumption only and must not be depended upon by the protocol; if absent, the first line must be empty.