rfc2657.txt

RFC 的详细文档！

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


2.2.6 baseURI

   The attribute value for this attribute is a LDAP URI. One can
   envisage other URI syntaxes, if the client knows about more access
   protocols besides LDAP, and the interaction between the client and
   the server can not use referrals for some reason.

   ( 1.2.752.17.1.26
     NAME 'baseURI'
     EQUALITY caseExactIA5Match
     SYNTAX IA5String
   )

2.2.7 protocolVersion

   At present, the Common Indexing Protocol version should be 3.

   ( 1.2.752.17.1.27
     NAME 'protocolVersion'
     EQUALITY numericStringMatch
     SYNTAX numericString
   )

2.2.8 cIPIndexType

   The type of index Object that is used to pass around index
   information.

   ( 1.2.752.17.1.29
     NAME 'cIPIndexType'
     EQUALITY caseIgnoreIA5Match
     SYNTAX IA5String
   )

2.2.10 polledBy

   The Distinguished Name of Index servers that polls data from this
   indexserver.

   ( 1.2.752.17.1.30
     NAME 'polledBy'
     EQUALITY distinguishedNameMatch
     SYNTAX DN
   )







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


2.2.11 updateIntervall

   The maximum duration in seconds between the generation of two updates
   by the supplier server.

   ( 1.2.752.17.1.31
     Name 'updateIntervall'
     EQUALITY numericStringMatch
     SYNTAX numericString
     SINGLE-VALUE
   )

2.2.12 securityOption

   Whether and how the supplier server should sign and encrypt the
   update before sending it to the consumer server.

   ( 1.2.752.17.1.32
     NAME 'securityOption'
     EQUALITY caseIgnoreIA5Match
     SYNTAX IA5String
     SINGLE-VALUE
   )

2.2.13 extendedDSI

   DataSet Identifier possibly followed by a space and a taglist, the
   later as specified by [6].

   ( 1.2.752.17.1.33
     NAME 'extendedDSI'
     EQUALITY caseIgnoreIA5Match
     SYNTAX IA5String
        )

2.2.14 consumerURI

   A URI describing which means a server can accept indexinformation.
   An example being a mailto URI for MIME email based index transport.

   ( 1.2.752.17.1.34
     NAME 'consumerURI'
     EQUALITY caseExactIA5Match
     SYNTAX IA5String
   )






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


2.2.15 attributeNamespace

   Any consumer supplier pair has to agree on what attribute that should
   be used and also possibly the meaning of the attributenames. The
   value of this attribute should, for example, be a URI pointing to a
   document wherein the agreement is described.

   ( 1.2.752.17.1.35 NAME 'attributeNamespace' EQUALITY
     caseExactIA5Match SYNTAX IA5String
   )

2.2.16 consistencyBase

   This attribute is specifically used by consumer supplier pairs that
   use the tagged index object [6].

   ( 1.2.752.17.1.36
     NAME 'consistencyBase'
     EQUALITY caseExactIA5Match
     SYNTAX IA5String
   )

3. The interaction between a client and the Index Mesh

   A client interaction with the Index Mesh consists of a couple of
   rather well defined actions. The first being to find a suitable index
   to start with, then to transverse the Index Mesh and finally to query
   the servers holding the original data.  Note when reading this text
   that what is discussed here is the client's perception of the DIT,
   how it is in fact implemented is not discussed.

3.1 Finding a Index Mesh

   This approach depends on the fact that every index server partaking
   in an Index Mesh is represented in the DIT by a entry of the type
   cIPDataSet, and has a distinguished name (DN) which most significant
   relative distinguished name (RDN) has the attributetype dSI.
   Therefore, finding a suitable indexserver to start the search from is
   a matter of searching the DIT at a suitable place for objects with
   the objectClass cIPIndexObject.  Every found entry can then be
   evaluated by looking at the description value as well as the
   indexOCAT value. The description string should be a human readable
   and understandable text that describes what the index server is
   indexing. An example of such a string could be, "This index covers
   all employees at Swedish Universities and University Colleges that
   has an email account". The indexOCAT attribute supplies information
   about which kind of entries and which attributes within these entries
   that the index information has emanated from.  For example, if the



Hedberg                       Experimental                      [Page 6]