Browse Prior Art Database

LDAPv2 Client vs. the Index Mesh (RFC2657)

IP.com Disclosure Number: IPCOM000003246D
Original Publication Date: 1999-Aug-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 12 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Hedberg: AUTHOR

Related Documents

10.17487/RFC2657: DOI

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 18% of the total text.

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,...

Processing...
Loading...