LDAPv2 Client vs. the Index Mesh (RFC2657)
Original Publication Date: 1999-Aug-01
Included in the Prior Art Database: 2019-Feb-10
Internet Society Requests For Comment (RFCs)
LDAPv2 clients as implemented according to RFC 1777 have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. This memo defines an Experimental Protocol for the Internet community.
Network Working Group R. Hedberg Request for Comment: 2657 Catalogix Category: Experimental August 1999
LDAPv2 Client vs. the Index Mesh
Status of this Memo
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
LDAPv2 clients as implemented according to RFC 1777  have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol , heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this.
During the development of the Common Indexing Protocol (CIP), one of the underlying assumptions was that the interaction between clients and the Index Mesh Servers  would heavily depend on the passing of referrals. Protocols like LDAPv2  that lack this functionality need to compensate for it by some means. The way chosen in this memo is to add more intelligence into the client. There are two reasons behind this decision. First, this is not a major enhancement that is needed and secondly, that the intelligence when dealing with the Index Mesh, with or the knowledge about referrals, eventually has to go into the client.
2. The clients view of the Index Mesh
If a LDAPv2 client is going to be able to interact with the Index Mesh, the Mesh has to appear as something that is understandable to the client. Basically, this consists of representing the index servers and their contained indexes in a defined directory information tree (DIT) [3,4] structure and a set of object classes and attribute types that have been proven to be useful in this context.
Hedberg Experimental [Page 1]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.1 The CIP Object Classes
Object class descriptions are written according to the BNF defined in .
The cIPIndex objectClass, if present in a entry, allows it to hold one indexvalue and information connected to this value.
( 1.2.718.104.22.168 NAME ’cIPIndex’ SUP ’top’ STRUCTURAL MUST ( extendedDSI $ idx ) MAY ( indexOCAT ) )
The cIPDataSet objectClass, if present in a entry, allows it to hold information concerning one DataSet.
( 1.2.722.214.171.124 NAME ’cIPDataSet’ SUP ’top’ STRUCTURAL MUST ( dSI $ searchBase ) MAY ( indexOCAT $ description $ indexType $ accessPoint $ protocolVersion $ polledBy $ updateIntervall $ securityOption $ supplierURI $ consumerURI $ baseURI $ attributeNamespace $ consistencyBase ) )
2.2 The CIP attributeTypes
The attributes idx, indexOCAT, extendedDSI, description, cIPIndexType, baseURI, dSI are used by a client accessing the index server. The other attributes (accesspoint, protocolVersion, polledBy, updateIntervall, consumerURI, supplierURI and securityOption, attributeNamespace,...