LDAPv2 Client vs (RFC2657)
Original Publication Date: 1999-Aug-01
Included in the Prior Art Database: 2000-Sep-13
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.
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
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.
MUST ( extendedDSI $ idx )
MAY ( indexOCAT )
The cIPDataSet objectClass, if present in a entry, allows it to hold
information concerning one DataSet.
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,