WDIFF

draft-zeilenga-ldap-namedref-00.txt --> draft-zeilenga-ldap-namedref-01.txt

Intended Category: Standard Track OpenLDAP Foundation
Expires: 4 January 17 May 2001 4 July 17 November 2000

Named Subordinate References in LDAP Directories
<draft-zeilenga-ldap-namedref-00.txt>
<draft-zeilenga-ldap-namedref-01.txt>

1. Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

Please see the Copyright section near the end of this document for
more information.

2. Abstract

This document defines details schema and protocol elements for representing
and manipulating generic knowledge information named subordinate references in LDAP [RFC2251]
directories. An attribute type "ref" is used to store URIs [RFC1738]
which may refer to LDAP and non-LDAP services. An A referral object class
"referral" is used to construct entries in an LDAP directory which hold references to other directories at
subordinate delegation points in the directory. These referral
objects hold one or services. An more URIs [RFC1738] contained in values of the ref
attribute type. A control, ManageDsaIT, is defined to allow clients to manipulate
manipulation of referral objects as normal
entries. The document describes procedures directory servers should
follow when supporting these elements.

Zeilenga [Page 1]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000 objects.

3. Background and intended usage

The broadening of interest in LDAP directories beyond their use as
front ends to X.500 [X.500] directories has created a need to
represent knowledge information in a more general way. Knowledge
information is information about one or more servers maintained in
another server, used to link servers and services together.

This document defines a general specific method of representing subordinate
knowledge
information references in LDAP directories, based on URIs. directories. Other forms of knowledge
information are not detailed by this document. These forms may be
described in subsequent documents.

This document details subordinate referral processing requirements for
servers. This document does not detail client processing of referral protocol syntax and search
reference responses. semantics.
This is detailed described in RFC 2251 or subsequent
documents. [RFC2251].

The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
"SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
interpreted as described in [RFC2119].

4. Schema

4.1

The ref attribute type

This section defines schema definitions are defined in terms of RFC 2252 [RFC2252].

4.1. The referral object class

A referral object is a directory entry whose structural object class
is (or is derived from) the ref attribute type for holding general
knowledge reference information. referral object class.

( 2.16.840.1.113730.3.1.34 2.16.840.1.113730.3.2.6
NAME 'ref' 'referral'
DESC 'URI reference'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE distributedOperation 'named subordinate reference object'
STRUCTURAL
MUST ref )

The ref attribute type has IA5 syntax and referral object class is case sensitive. a structural object class used to
represent a named reference in the directory. The ref
attribute is multi valued. Values placed referral object
class SHOULD be used in conjunction with the attribute MUST conform extensibleObject object
class to support the specification given for the labeledURI attribute defined naming attributes used in
[RFC2079]. The labeledURI specification defines a format that is a
URI, optionally followed by whitespace and a label. This document does
not make use of the label portion of the syntax. entry's
Distinguished Name (DN) [RFC2253]. Referral objects are directory
entries whose structural object call is (or is derived from) referral.

Referral objects SHOULD only be instantiated at the subordinate
delegation points.

In the presence of a ManageDsaIT control, referral objects are treated
as normal entries (as described in section 5). Note that the ref
attribute is operational and will only returned in a search entry
response when requested.

In the absence of a ManageDsaIT control, the content of referral
objects are used to construct referrals and search references (as
described in section 6) and, as such, the referral entries are not
themselves visible to clients.

4.2 The ref attribute type

( 2.16.840.1.113730.3.1.34
NAME 'ref'
DESC 'named reference - a labeledURI'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE distributedOperation )

The ref attribute type has IA5 syntax and is case sensitive. The ref
attribute is multi-valued. Values placed in the attribute MUST conform
to the specification given for the labeledURI attribute defined in
[RFC2079]. The labeledURI specification defines a format that is a
URI, optionally followed by whitespace and a label. This document does
not make use of the label portion of the syntax. Future documents MAY
enable new functionality by imposing additional structure on the label
portion of the syntax as it appears in the ref attribute.

If the URI contained in a ref attribute value refers to an LDAPv3 a LDAP
[RFC2251] server, it MUST be a in the form of a LDAP URI scheme described in URL [RFC2255].
In general, the LDAP URL should not contain an explicit scope
specifier, filter, attribute description list, or any extensions. If
the DN part is absent (or empty), the LDAP URL refers to entry of the
same DN as the referral object in which the value is held.

Other URI schemes MAY be used but MUST refer to services which are
capable of completing operations referred to the services. The URI
values, regardless of scheme, URIs
contained in a ref attribute must MUST point

Zeilenga [Page 2]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000 to services which are equally
capable of handling operations refer referring to
said these services.

The referential integrity of the URI SHALL NOT be validated by the
server holding or returning the reference.

When returning a referral result, the server MUST NOT return the label
portion of the labeledURI URI (whether as part of the referral. Only the URI
portion value of
the ref attribute SHOULD be returned.

The ref attribute SHOULD NOT be used for naming.

4.2. The referral object class

The referral object class is defined or as follows.

( 2.16.840.1.113730.3.2.6
NAME 'referral'
DESC 'named reference object'
STRUCTURAL MUST ref )

The referral object class is a structural object class used to
represent part of a named referral result or search reference in the directory. The
response).

When returning a referral object
class SHOULD be used in conjunction with the extensibleObject object
class to support the naming attributes used in result or search continuation, the entry's
distinguished name.

In server
MUST NOT return the presence separator or label portions of a ManageDsaIT control, referral objects are treated the attribute
values as normal entries. Note that part of the reference. When the ref attribute is operational and
will only returned in a search entry response when requested.

In contains multiple
values, the absence URI part of a ManageDsaIT control, referral objects contents are each value is used to construct referrals and search references and, as such, the referral entries themselves are general visible to clients.

5. Use of the
result or search continuation.

The ref attribute

Two uses values SHOULD NOT be used as an relative naming
component of an entry's DN [RFC2253].

This documents use of the ref attribute is defined in this document. The first
use, in conjunction with the
referral object class, represents a named
reference. The second use, in conjunction with the Root DSE,
represents superior class to represent subordinate reference. The following sections detail these
usages of the ref attribute.

Other uses of the ref
attribute MAY may be used for other purposes as defined in subsequent
documents, or by bilateral agreement between cooperating clients and
servers and SHOULD be defined in conjunction other
documents.

5. The ManageDsaIT control

The client MAY provide the ManageDsaIT control with an object class

Zeilenga [Page 3]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000

indicating operation to
indicates that the usage.

5.1. Named reference

A named reference operation is used intended to facilitate distributed name resolution or
search across multiple servers. The ref attribute appears in an
referral object (an entry manage objects with object class of referral) named in the
referencing server.
DSA (server) Information Tree. The value controls causes Directory-specific
entries (DSEs), regardless of the ref attribute points type, to be treated as normal entries
allowing clients to interrogate and update these entries using LDAP
operations. This control is analogous to the
corresponding entry maintained in the referenced server.

While the distinguished name ManageDsaIT option
described in a value of X.511(93) [X.511].

A client MAY specify the ref attribute is
typically that of following control when issuing an entry in a naming context below the naming
context held by add,
compare, delete, modify, modifyDN, search request or an extended
operation for which the referencing server, it control is permitted to defined.

The control type is 2.16.840.1.113730.3.4.2. The control criticality
may be the
distinguished name of any entry. If the ref attribute TRUE or FALSE. There is multi-valued
all no value; the DNs controlValue field SHALL
be absent.

When present in the values of the ref attribute SHOULD have the same
value. Administrators SHOULD avoid configuring naming loops using
referrals.

The URI SHOULD NOT explicitly define a scope and request, the server SHOULD SHALL NOT
explicitly add a scope to the URI before returning it to the client as generate a referral
or search continuation reference as the scope is implied by for any referral object and instead perform
treat the
operation.

Named references MUST be treated referral object as an normal entries if the request
includes the ManageDsaIT control. The remainder of this section
describes processing of requests which do entry. When not include the ManageDsaIT
control.

5.1.1. Scenarios

The following sections contain specifications of how present,
referral objects
should SHALL be used in different scenarios followed by examples that handled as described above.

The control MAY cause other objects to be treated as normal entries as
defined by subsequent documents.

6. Named subordinate references

A named subordinate reference is constructed by instantiating a
referral object at the delegation point in the referencing server with
ref attribute values which to point to the corresponding subtree
maintained in the referenced server.

That is, if server A holds "dc=example,dc=net" and server B holds
"dc=sub,dc=example,dc=net", server A may contain a referral object
named "ou=sub,dc=example,dc=net" which contains a ref attribute with
value of "ldap://B/dc=sub,dc=example,dc=net".

dn: dc=sub,dc=example,dc=net
dc: sub
ref: ldap://B/dc=sub,dc=example,dc=net
objectClass: referral
objectClass: extensibleObject

While typically the DN of the referral object and the DN of the object
in the referenced server are the same, they need not be the same. If
they are the same, the DN part of the LDAP URL MAY be absent. That
is, in the above example, the ref attribute with the value of
"ldap://B/" is equivalent to "ldap://B/dc=sub,dc=example,dc=net".

If the ref attribute has multiple values, all the DNs contained (or
implied) by LDAP URL SHOULD have the same. Administrators SHOULD
avoid configuring naming loops using referrals.

Named references MUST be treated as normal entries if the request
includes the ManageDsaIT control as described in section 5.

7. Scenarios

The following sections contain specifications of how referral objects
should be used in different scenarios followed by examples that
illustrate that usage. The scenarios described consist of referral
operation when finding target of a non-search operation, when finding
the base of a search operation, and when generating search references.
Lastly, other operation processing considerations are presented.

It is to be noted that, in this document, a search operation is
conceptually divided into two distinct, sequential phases: (1) finding
the base object where the search is to begin, and (2) performing the
search itself. The operation of the server with respect to referrals
in first phase (1) is similar to the operation of to, but not the server while same as,
finding the target object for of a non-search operations. operation.

It is to should also be noted that the ref attribute may have multiple
values and, where these sections refer to a single ref attribute
value, multiple ref attribute values may be substituted and SHOULD be

Zeilenga [Page 4]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000
processed and returned (in any order) as a group in a referral or
search reference in the same way as described for a single ref
attribute value.

Search references returned for a given request may be returned in any
order.

5.1.1.1.

7.1. Example configuration

|------------------------------------------------------------|
| Server A |
| dn: o=abc,c=us dn: o=xyz,c=us |
| o: abc o: xyz |
| ref: ldap://hostB/o=abc,c=us ref: ldap://hostD/o=xyz,c=us |
| ref: ldap://hostC/o=abc,c=us objectclass: referral |
| objectclass: referral objectclass: extensibleObject|
| objectclass: extensibleObject |
|____________________________________________________________|

|------------------| |------------------| |------------------|
| Server B | | Server D | | Server C |
| dn: o=abc,c=us | | dn: o=xyz,c=us | | dn: o=abc,c=us |
| o: abc | | o: xyz | | o: abc |
| other attributes | | other attributes | | other attributes |
|__________________| |__________________| |__________________|

In this example, Server A holds references for two entries:
"o=abc,c=us" and "o=xyz,c=us". Configuration

For example, suppose the "o=abc,c=us" entry, Server A contacted server (hosta) holds two references, one to Server B and one to Server C. The
entries referenced are replicas of each other. For the "o=xyz,c=us"
entry, Server A holds a single reference to entry
"O=MNN,C=WW" and the entry contained in
Server D.

In "CN=Manager,O=MNN,C=WW" and the following protocol interaction examples,
referral objects:

dn: OU=People,O=MNN,C=WW
OU: People
ref: ldap://hostb/OU=People,O=MNN,C=US
ref: ldap://hostc/OU=People,O=MNN,C=US
objectClass: referral
objectClass: extensibleObject

dn: OU=Roles,O=MNN,C=WW
OU: Roles
ref: ldap://hostd/
objectClass: referral
objectClass: extensibleObject

The first referral object provides the client has
contacted Server A. Server A holds server with the naming context "c=us".

5.1.1.2. Base or Target object considerations

As previously described, knowledge that
subtree "OU=People,O=MNN,C=WW" is held by hostb and hostc (one is the process of generating referrals for
master and the other a
search can be described in two phases. shadow). The first, which second referral object provides
the server with the knowledge that the subtree "OU=Roles,O=MNN,C=WW"
is described held by hostd.

Also, in the context of this section, document, the "nearest naming context"
means the deepest context which the object is generating referrals based on within. That is, if the base
object
specified in is within multiple naming contexts, the search. This process nearest naming context
is similar to the process of
generating referrals based on one which is subordinate to all other naming contexts the target
object while processing other
operations (modify, is within.

7.2. Target object considerations

This section details referral handling to add, compare, delete, modify DN,
modify, and compare) with the sole
exception that for these other operations, the modify DN in the referral must
be modified in some cases.

Zeilenga [Page 5]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000 operations. If a the client requests any of these
operations, there are four cases that the server must handle with
respect to the base or target object
specified in object.

In cases where the request.

Case 1: The base or target object URI to be returned is not held by a LDAP URL, the server and is not
within or subordinate to any naming context nor is subordinate to SHOULD
trim any
referral object held by present search-specific parts (e.g. scope, filter, attribute
list) from the server.

The handling of this case is described URI before return it. Critical extensions MUST NOT be
trimmed nor modified. Other parts MAY be modified or trimmed.

The DN part MUST be modified such that it refers to the appropriate
target in section 6. the referenced server (as detailed below). If the modified
DN part is the same as the DN of the original request, the modified DN
part MAY be trimmed.

Case 2: 1: The base or target object is not held by the server and is a
referral object.

In this case, if the type of operation requested is a search not within
or the
URI contained subordinate to any naming context nor in the ref attribute of the requested base subordinate to any
referral object is NOT
an LDAP URI, held by the server.

The server SHOULD return the URI value contained in the
ref attribute of the base object whose DN is the DN requested by process the
client request normally as the base appropriate for the operation.

Example:

If the client issues
a search in non-existent base which not within any naming context of the base object is
"o=xyz,c=us",
server A will (generally return

SearchResultDone "referral" {
ldap://hostD/o=xyz,c=us
}

If the type of operation requested is not a search and the URI
contained in the ref attribute of the requested superior referral or noSuchObject).
This document does not detail management or processing superior
knowledge references.

Case 2: The target object is an
LDAP URI, held by the server SHOULD return and is a modified form of this URI. referral
object.

The
returned URI MUST have only the protocol, host, port, and trailing "/"
portion of server SHOULD return the URI value contained in the ref attribute. The server SHOULD
strip any DN, attributes, scope, and filter parts
attribute of the URI. referral object.

Example: If the client issues a modify request for the target object
of
"o=abc,c=us", "OU=People,O=MNN,c=WW", the server A will return may return:

ModifyResponse "referral" {
ldap://hostB/
ldap://hostC/
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}

or, if the server chooses to trim the DN from the LDAP URL, it may
return:

ModifyResponse "referral" {
ldap://hostb/
ldap://hostc/
}

Case 3: The base or target object is not held by the server, but is object
where the nearest naming context contains no referral object which
the base or target object is subordinate to.

Zeilenga [Page 6]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000

In the context of this document, the nearest naming context means the
deepest context which the object is within. That is, if the object is
within multiple naming contexts, the nearest naming context the one
which is subordinate to all other naming contexts the object is
within.

If the nearest naming context contains no referral object which
the
base or target object is subordinate to to, the request, request SHOULD be
process processed
normally as appropriate for a nonexistent base or target
object (generally return
noSuchObject).

Case 4: The base or target object is not held by the server, but is object
where the nearest naming context contains a referral object which
the base or target object is subordinate to.

As noted above, the nearest naming context means the deepest context
which the object is within.

If a client requests an operation for which the base or target object is
not held by the server but the nearest naming context contains a
referral object which the base or target object is subordinate to, the
server MUST SHALL return a referral response which contains referral values constructed from the
URI components portion of the ref attribute values value of the referral object.

For each ref attribute value, if the URI component is not an LDAP
URIs, it SHOULD be returned as-is. If URI component is an LDAP URI,
the URI MUST be modified, regardless of the type of operation, as case
2 describes for a non-search request. That is, the DN, attributes,
scope, and filter parts of the URI MUST be stripped from the returned
URI.

Example: If the client issues an add request where the target object
has a DN of "cn=Chris Lukas,o=abc,c=us", "cn=Manager,OU=Roles,O=MNN,C=WW", the server A will
return

AddResponse "referral" {
ldap://hostB/
ldap://hostC/
ldap://hostd/cn=Manager,OU=Roles,O=MNN,C=WW"
}

5.1.1.3. Search with one level or subtree scope

For search operations, once the base object has been found and
determined not to be a referral object, the search may progress. Any
entries matching

Note that the filter and scope DN part of the search which LDAP URL is not a

Zeilenga [Page 7]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000

referral object are returned modified such that it
refers to the client normally as described appropriate entry in
[RFC2251].

For each referral object within the requested scope, regardless of the
filter, referenced server. As the server SHOULD return a SearchResultReference which
DN part is
constructed from the URI component of values of same original target DN (in this example), the ref attribute. If
server may trim the URI component is not an LDAP URI, it should be returned as is. If DN and return

AddResponse "referral" {
ldap://hostd/
}

7.3. Base object considerations

This section details referral handling for base object processing
within search operations. Like target object considerations for non-
search operations, there are the four cases.

In cases where the URI component to be returned is an a LDAP URI, URL, the URI must be modified to server MUST
remove any explicit scope specifier.

One Level Example:

If a client requests a one level search of "c=US" then, in addition specifier from the LDAP URL prior to
any entries one level below return
it. In addition, the "c=US" naming context matching DN part MUST be modified such that it refers to
the
filter (shown below as "... SearchResultEntry responses ..."), appropriate target in the referenced server will also return search references for any referral object
within (as detailed below).
If the scope of modified DN part is the search.

The order same as the DN of the SearchResultEntry responses and original request,
the
SearchResultReference responses is undefined. One possible sequence
is shown.

... SearchResultEntry responses ...

SearchResultReference {
ldap://hostB/o=abc,c=us
ldap://hostC/o=abc,c=us
}

SearchResultReference {
ldap://hostD/o=xyz,c=us
}

SearchResultDone "success"

Subtree Example: modified DN part MAY be trimmed.

If a client requests a subtree search of "c=us", then in addition to
any entries aliasing dereferencing was necessary in finding, the "c=us" naming context which match DN part of URI
MUST be replaced with the filter,
Server A will also return two continuation references. As described in base DN as modified by the preceding section, alias
dereferencing such that the return URL refers to the order new target object
per [RFC2251, 4.1.11].

Critical extensions MUST NOT trimmed nor modified. Other parts of the responses is not defined.

One possible response might be:

SearchResultReference {
ldap://hostB/o=abc,c=us
ldap://hostC/o=abc,c=us

Zeilenga [Page 8]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000

}

... SearchResultEntry responses ...

SearchResultReference {
ldap://hostD/o=xyz,c=us
}

SearchResultDone "success"

6. Superior Reference

An
LDAP server may URL MAY be configured to return a superior reference in the
case where the requested modified.

Case 1: The base or target object is not contained held by the server and is not within or
subordinate to a any naming context nor in subordinate to any
referral object held by the server or referral
object.

An LDAP server's root DSE MAY contain a ref attribute. server.

The values of
the ref attribute in the root DSE that are LDAP URIs server SHOULD NOT
contain any DN part nor other search parameters (scope, filter,
attribute list). They MUST include the URI hostpart.

If process the LDAP server's root DSE contains a ref attribute and a client
requests request normally as appropriate for
a target or non-existent base object not held by the server and which not
contained within or subordinate to any naming context of the
server (generally return a superior referral or noSuchObject).
This document does not detail management or processing superior
knowledge references.

Case 2: The base object is held by the server or and is a referral object, the
object.

The server MUST SHOULD return the URI component of
the values value contained in the ref
attribute of the root DSE as illustrated in the
example. referral object. If the LDAP server's root DSE does not contain URI is a ref attribute, LDAP URL, in
addition to trimming search-specific parts as described above, the
server may return referral result with or more URIs determined via an
appropriate method, return noSuchObject, or other appropriate
resultCode.

The presence of the ref attribute within the root DSE SHALL MUST NOT cause
operations upon trim the DN of the root DSE URI if it is not equal to generate a referral. the
target DN but MAY if it equal.

Example: If a the client requests issues a subtree search of "c=de" from server A in which the
example configuration, and server A has base object is
"OU=Roles,O=MNN,C=WW", the following ref attribute
defined in it's root DSE:

ref: ldap://hostG/

then server A will return

Zeilenga [Page 9]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000

SearchResultDone "referral" {
ldap://hostG/
ldap://hostd/OU=Roles,O=MNN,C=WW
}

8. The ManageDsaIT control

or, if it chooses to trim the DN:

SearchResultDone "referral" {
ldap://hostd/
}

Case 3: The ManageDsaIT control indicates that base object is not held by the operation has been
requested so that server, but is object where
the DSA (server) Information Tree nearest naming context contains no referral object which the
base object is managed. The
controls causes DSEs, regardless of type, to subordinate to.

If the nearest naming context contains no referral object which
the base is subordinate to, the request SHOULD be treated processed
normally as normal
entries allowing clients to interrogate and update these entries using
LDAP operations. This control appropriate for a nonexistent base (generally return
noSuchObject).

Case 4: The base object is analogous to not held by the ManageDsaIT option
described in X.511(93) [X.511].

A client MAY specify server, but is object where
the following control when issuing an add,
compare, delete, modify, modifyDN, search request or nearest naming context contains a referral object which the
base object is subordinate to.

If a client requests an extended operation for which the control is defined.

The control type is 2.16.840.1.113730.3.4.2. The control criticality
may be TRUE or FALSE. There target object is no value;
not held by the controlValue field is
absent.

When present in server but the request, nearest naming context contains a
referral object which the target object is subordinate to, the
server SHALL NOT generate return a referral
or continuation reference for any response which constructed from the
URI portion of the ref value of the referral object object.

Example: If the client issues an search request for
"cn=Manager,OU=Roles,O=MNN,C=WW", the server will return

SearchResultDone "referral" {
ldap://hostd/cn=Manager,OU=Roles,O=MNN,C=WW"
}

Note that the DN part of the LDAP URL is modified such that it
refers to the appropriate entry in the referenced server. As the
DN part is the same original base DN (in this example), the server
may trim the DN and instead perform
treat return

SearchResultDone "referral" {
ldap://hostd/
}

7.4. Search continuation considerations

For search operations, once the referral base object as an normal entry. When has been found and
determined not present,
referral objects SHALL be handled as described above.

The control MAY cause other objects to be treated as normal a referral object, the search may progress. Any
entries as
defined by subsequent documents.

9. Relationship to X.500 Knowledge References

The X.500 standard defines several types matching the filter and scope of knowledge references, used the search which is not a
referral object are returned to bind together different parts the client normally as described in
[RFC2251].

For each referral object within the requested scope, regardless of the X.500 namespace. In X.500,
knowledge references can be associated with
search filter, the server SHOULD return a set SearchResultReference which
is constructed from the URI component of unnamed entries
(e.g., a reference, associated with an entry, to values of the ref attribute.
If the URI component is not a server containing LDAP URL, it should be returned as is.
If the descendants of that entry).

This creates URI component is a potential problem for LDAP clients resolving an LDAPv3 URL, the URI referral referring must be modified to an LDAP directory back-ended by X.500.
Suppose remove
any explicit scope specifier. If the search LDAP URL's DN part is a subtree search, and that server A holds the
base object of absent or
empty, the search, and server B holds DN part must be modified to contain the descendants DN of the
base referral
object. The behavior

Subtree Example:

If a client requests a subtree search of X.500(1993) subordinate "O=MNN,C=WW", then in
addition to any entries within scope which match the filter, hosta
will also return two search references is
that as the base object on server A is searched, and two referral objects
are within scope. One possible response might be:

SearchEntry for O=MNN,C=WW
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW
}
SearchResultDone "success"

One Level Example:

If a single
continuation reference is returned pointing to all client requests a one level search of "O=MNN,C=WW" then, in
addition to any entries one level below the "O=MNN,C=WW" entry
matching the filter, the descendants
held on server B.

Zeilenga [Page 10]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000

An LDAP URI only allows will also return two search
references as the base two referral objects are within scope. One
possible sequence is shown:

SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW
}
SearchResultDone "success"

7.6. Other considerations

This section details other operation processing considerations.

7.6.1 Bind

A server SHOULD process a bind request as if it held no referral
objects. That is, if the bind name is a referral object to be specified. It or is not
possible using standard LDAP URIs
subordinate to indicate a search of several
entries whose names are not known to referral object, the server holding the superior
entry.

X.500 solves this problem by having two fields, one indicating the
progress of name resolution and the other indicating SHOULD process the target of
request normally as appropriate for a non-existent bind name.

7.6.2 Modify DN

If the
search. In newSuperior is a referral object or is subordinate to a
referral object, the above example, name resolution would be complete by servers SHOULD return affectsMultipleDSAs. If
the
time newRDN already exists but is a referral object, the query reached server B, indicating that it should not refer
the request.

This document does not address this problem. This problem will be
addressed in separate documents which define the changes to the X.500
distribution model and LDAPv3 extensions to indicate the progress
return affectsMultipleDSAs instead of
name resolution.

10. entryAlreadyExists.

8. Security Considerations

This document defines mechanisms that can be used to "glue" bind together
LDAP (and other) servers together. The information used to specify this glue
information bind
services together should be protected from unauthorized modification.
If the server topology information itself is not public information,
the information should be protected from unauthorized access as well.

11.

9. References

[RFC1738] Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform
Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
University of Minnesota, December 1994.

[RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997.

[RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", RFC 2119 (Also BCP0014), March 1997.

[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.

[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.

[RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.

[RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.

[X.500] ITU-T Rec. X.501, "The Directory: Models", 1993.

[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service

Zeilenga [Page 11]

INTERNET-DRAFT draft-zeilenga-ldap-namedref-00 4 July 2000
Definition", 1993.

12.

10. Acknowledgments

This document is borrows heavily from previous work by IETF LDAPext
working group. In particular, this document is based upon "Named
Referral in LDAP Directories" (a work in progress) by Christopher
Lukes, Tim Howes, Michael Roszkowski, Mark C. Smith, and Mark Wahl.

13.

11. Author's Address

Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>

This draft expires 4 Jan. 2001.

Zeilenga [Page 12] document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

----