LDAPv2 Client vs. the Index Mesh
RFC 2657

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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 Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   LDAPv2 clients as implemented according to RFC 1777 [1] have no
   notion on referral.  The integration between such a client and an
   Index Mesh, as defined by the Common Indexing Protocol [2], heavily
   depends on referrals and therefore needs to be handled in a special
   way.  This document defines one possible way of doing this.

1. Background

   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 [1] would heavily depend on the passing of
   referrals.  Protocols like LDAPv2 [2] 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
   [5].

2.1.1 cIPIndex

   The cIPIndex objectClass, if present in a entry, allows it to hold
   one indexvalue and information connected to this value.

   ( 1.2.752.17.3.9
     NAME 'cIPIndex'
     SUP 'top'
     STRUCTURAL
     MUST ( extendedDSI $ idx )
     MAY ( indexOCAT )
   )

2.1.2 cIPDataSet

   The cIPDataSet objectClass, if present in a entry, allows it to hold
   information concerning one DataSet.

   ( 1.2.752.17.3.10
     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, consistencyBase) are all for
   usage in server to server interactions.

Hedberg                       Experimental                      [Page 2]
RFC 2657                 LDAPv2 vs. Index Mesh               August 1999

2.2.1 idx

   The index value, normally used as part of the RDN.

   ( 1.2.752.17.1.20
     NAME 'idx'
     EQUALITY caseIgnoreIA5Match
     SYNTAX IA5String
     SINGLE-VALUE
      )

2.2.2 dSI

   DataSet Identifier, a unique identifier for one particular set of
   information.  This should be an OID, but stored in a stringformat.

   ( 1.2.752.17.1.21
     NAME 'dSI'
     EQUALITY caseIgnoreIA5Match
     SYNTAX IA5String
   )

2.2.3 indexOCAT

   Describes the type of data that is stored in this entry, by using
   objectcClasses and attributeTypes. The information is stored as a
   objectClass name followed by a space and then an attributeType name.
   A typical example when dealing with whitepages information would be
   "person cn".

   ( 1.2.752.17.1.28
     NAME 'indexOCAT'
     EQUALITY caseIgnoreIA5Match
     SYNTAX IA5String
   )

2.2.5 supplierURI

   A URI describing which protocols, hostnames and ports should be used
   by an indexserver to interact with servers carrying indexinformation
   representing this dataSet.

     ( 1.2.752.17.1.22
      NAME 'supplierURI'
      EQUALITY caseIgnoreIA5Match
      SYNTAX IA5String
   )

Hedberg                       Experimental                      [Page 3]
RFC 2657                 LDAPv2 vs. Index Mesh               August 1999