Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

LDAPv2 Client vs (RFC2657)

IP.com Disclosure Number: IPCOM000003246D
Original Publication Date: 1999-Aug-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 9 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

the Index Mesh. R. Hedberg: AUTHOR

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 15% 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.

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 'cIPD...