The Architecture of the Common Indexing Protocol (CIP)
Extracted elements (24)
CIP evolved from Whois++ to extract and generalize the indexing subsystem, replacing ad-hoc data representations with MIME-based structures and abstracting index objects so they apply to multiple application domains beyond directory services.
CIP is a 'backend' protocol spoken only among servers; queries are answered via the server's native data access protocol (e.g., LDAP, HTTP), while index objects travel via separate CIP protocol exchanges. This separation is intentional and fundamental to the architecture.
In multi-protocol application domains, aggregation must ensure referral chains never pass through mesh nodes that don't support the client's native protocol, because clients cannot resolve referrals they can't speak. This is declared a failure of query routing.
Index object payloads are opaque to CIP itself and defined entirely by separate index object specifications. This abstraction is what makes CIP applicable across multiple application domains.
Query routing is a client responsibility: the client collates, filters, and chases referrals. This gives the end-user maximum control over query resolution at the cost of added client complexity. A proxy can optionally decouple referral chasing for simple clients.
The index pushing relationship is designed to lower the barrier to entry for dumb leaf nodes that want to make their index available to the global mesh without implementing the full CIP transaction protocol.
To avoid scaling issues, no single mandatory 'root' node exists in a CIP mesh. Clients should connect to a reasonably well-connected local server and expand their search upward through servers that poll the initial entry point if no match is found.
A CIP server that receives an index of an unknown type may pass it forward untouched, or return an error. This behavior exists to allow heterogeneous mesh experiments, though such meshes are considered ill-defined and dangerous.
CIP version 3 servers can interoperate with earlier Whois++-era servers (versions 1 and 2) via a short negotiation sequence, despite version 3 being a major protocol overhaul.
The Whois++ mesh traversal algorithm from RFC 1914 works unchanged with CIP by substituting 'DSI' for the Whois++ 'handle' concept.
All indices passed within a given mesh are assumed to be of the same type. Gateways between meshes carrying different index objects are undefined and outside the scope of this specification.
Clients following all referrals must implement a mesh traversal algorithm (as documented for Whois++ in RFC 1914) to detect and avoid referral loops, which could otherwise waste server and client resources infinitely.
If more than one index object indicates a referral must be generated to a given dataset, the server should generate only one referral to that dataset, as the client may not be able to detect duplicates.
Index object aggregation is only permitted when: (a) all objects to be aggregated cover exactly the same set of protocols per their Base-URI schemes, (b) the aggregating server supports every protocol in those Base-URIs, and (c) the index type specification explicitly defines the aggregation operation.
When a server aggregates index objects, the resulting object must have Base-URIs characteristic of the local server for each protocol it supports, and the outgoing objects should have the DSI of the local server.
A CIP index object consists of two parts: a header containing metadata (including 'type', 'DSI', and 'Base-URI' fields) and an opaque payload defined by the index object specification associated with the object's MIME type.
A CIP mesh is a set of servers passing indices of the same type, typically arranged hierarchically but explicitly allowed to have lateral links. Loops are discouraged but not prohibited; mesh administrators are encouraged to avoid them.
A referral must contain at minimum a DSI (to allow clients to detect and avoid referral loops) and a URI (derived from the Base-URI of the matching index object). An optional DSI-Description string should be included when available.
CIP defines two index-passing relationships: a 'polling relationship' where the polled server notifies the polling server of new indices and the polling server may retrieve them immediately or later; and an 'index pushing' relationship where a server sends its index unsolicited.
The Base-URI header in a CIP index object provides the URI(s) that form the basis of any referrals generated from the index block, and constrains aggregation due to multiprotocol concerns.
The DSI (Dataset Identifier) is an identifier chosen from the ISO/CCITT OID space that uniquely identifies a dataset among all datasets indexed by CIP. It is a required header in every index object.
CIP index objects can leak proprietary or sensitive data if not carefully designed. The risk of reverse-engineering a database from its exported index must be kept consistent with the value of the data; security must be a prime consideration when designing new index object types.
CIP requires external security services to operate safely; the protocol itself does not provide authentication or data integrity mechanisms for index objects exchanged between servers.
Insertion of false data into a CIP mesh can be used as an attack: adversarial indices can selectively prune parts of a mesh, and CIP provides no mechanism for trusting the authenticity or integrity of the index data it carries.