mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
775 lines
26 KiB
Plaintext
775 lines
26 KiB
Plaintext
|
IETF LDAPEXT Working Group Christopher Lukas [Editor]
|
||
|
INTERNET-DRAFT Internet Scout Project
|
||
|
Tim Howes
|
||
|
Netscape Communications Corp.
|
||
|
Michael Roszkowski
|
||
|
Internet Scout Project
|
||
|
Mark C. Smith
|
||
|
Netscape Communications Corp.
|
||
|
Mark Wahl
|
||
|
Critial Angle, Inc.
|
||
|
June 1999
|
||
|
|
||
|
|
||
|
Named Referrals in LDAP Directories
|
||
|
<draft-ietf-ldapext-namedref-00.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.
|
||
|
|
||
|
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.
|
||
|
|
||
|
Distribution of this document is unlimited. Please send comments to the
|
||
|
authors or the LDAPEXT mailing list, ietf-ldapext@netscape.com.
|
||
|
|
||
|
Copyright Notice: Copyright (C) The Internet Society (1999). All Rights
|
||
|
Reserved.
|
||
|
|
||
|
This draft is a revision of a draft formerly published as draft-ietf-
|
||
|
ldapext-referral-00.txt.
|
||
|
|
||
|
This draft expires December 6, 1999.
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 1]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
2. Abstract
|
||
|
|
||
|
This document defines a "ref" attribute and associated "referral" object
|
||
|
class for representing generic knowledge information in LDAP directories
|
||
|
[RFC2251]. The attribute uses URIs [RFC1738] to represent knowledge,
|
||
|
enabling LDAP and non-LDAP services alike to be referenced. The object
|
||
|
class can be used to construct entries in an LDAP directory containing
|
||
|
references to other directories or services. This document also defines
|
||
|
procedures directory servers should follow when supporting these schema
|
||
|
elements and when responding to requests for which the directory server
|
||
|
does not contain the requested object but may contain some knowledge of
|
||
|
the location of the requested object.
|
||
|
|
||
|
3. Background and intended usage
|
||
|
|
||
|
The broadening of interest in LDAP directories beyond their use as front
|
||
|
ends to 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 method of representing knowledge infor-
|
||
|
mation in LDAP directories, based on URIs.
|
||
|
|
||
|
The key words "MUST", "SHOULD", and "MAY" used in this document are to
|
||
|
be interpreted as described in [RFC2119].
|
||
|
|
||
|
4. The ref attribute type
|
||
|
|
||
|
This section defines the ref attribute type for holding general
|
||
|
knowledge reference information.
|
||
|
|
||
|
( 2.16.840.1.113730.3.1.34 NAME 'ref' DESC 'URL reference'
|
||
|
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 multivalued. 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 the ref attribute refers to an LDAPv3 server, it
|
||
|
must be in the LDAP URI format described in [RFC2255].
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 2]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
When returning a referral result, the server must not return the label
|
||
|
portion of the labeledURI as part of the referral. Only the URI portion
|
||
|
of the ref attribute should be returned.
|
||
|
|
||
|
5. Use of the ref attribute
|
||
|
|
||
|
One usage of the ref attribute is defined in this document. Other uses
|
||
|
of the ref attribute MAY be defined in subsequent documents, or by bila-
|
||
|
teral agreement between cooperating clients and servers.
|
||
|
|
||
|
Except when the manageDsaIT control (documented in section 8 of this
|
||
|
document) is present in the operation request, the ref attribute is not
|
||
|
visible to clients, except as its value is returned in referrals or con-
|
||
|
tinuation references.
|
||
|
|
||
|
If the manageDsaIT control is not set, and the entry named in a request
|
||
|
contains the ref attribute, and the entry is not the root DSE, the
|
||
|
server returns an LDAPResult with the resultCode field set to "referral"
|
||
|
and the referral field set to contain the value(s) of the ref attribute
|
||
|
minus any optional trailing whitespace and labels that might be present.
|
||
|
|
||
|
If the manageDsaIT control is not set, and an entry containing the ref
|
||
|
attribute is in the scope of a one level or subtree search request, the
|
||
|
server returns a SearchResultReference for each such entry containing
|
||
|
the value(s) of the entry's ref attribute.
|
||
|
|
||
|
When the manageDsaIT control is present in a request, the server will
|
||
|
treat an entry containing the ref attribute as an ordinary entry, and
|
||
|
the ref attribute as an ordinary attribute, and the server will not
|
||
|
return referrals or continuation references corresponding to ref attri-
|
||
|
butes.
|
||
|
|
||
|
The following sections detail these usages of the ref attribute.
|
||
|
|
||
|
5.1. Named reference
|
||
|
|
||
|
This use of the ref attribute is to facilitate distributed name resolu-
|
||
|
tion or search across multiple servers. The ref attribute appears in an
|
||
|
entry named in the referencing server. The value of the ref attribute
|
||
|
points to the corresponding entry maintained in the referenced server.
|
||
|
|
||
|
While the distinguished name in a value of the ref attribute is typi-
|
||
|
cally that of an entry in a naming context below the naming context held
|
||
|
by the referencing server, it is permitted to be the distinguished name
|
||
|
of any entry. If the ref attribute is multi-valued all the DNs in the
|
||
|
values of the ref attribute SHOULD have the same value. It is the
|
||
|
responsibility of clients to not loop repeatedly if a naming loop is
|
||
|
present in the directory. Administrators SHOULD avoid configuring
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 3]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
naming loops using referrals.
|
||
|
|
||
|
Clients SHOULD perform at least simple "depth-of-referral count" loop
|
||
|
detection by incrementing a counter each time a new set of referrals is
|
||
|
received. Clients MAY perform more sophisticated loop detection, for
|
||
|
example not chasing the same URI twice.
|
||
|
|
||
|
If an entry containing the ref attribute is immediately subordinate to
|
||
|
the base object named in a one level search request, then the referring
|
||
|
server MUST include a scope of "base" in any LDAP URIs returned in the
|
||
|
corresponding SearchResultReference.
|
||
|
|
||
|
5.1.1. Scenarios
|
||
|
|
||
|
The following sections contain specifications of how the ref attribute
|
||
|
should be used in different scenarios followed by examples that illus-
|
||
|
trate that usage. The scenarios described consist of referral operation
|
||
|
when finding a base or target object, referral operation when performing
|
||
|
a one level search, and referral operation when performing a subtree
|
||
|
search.
|
||
|
|
||
|
It is to be noted that, in this document, a search operation is concep-
|
||
|
tually 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 phase
|
||
|
(1) is almost identical to the operation of the server while finding the
|
||
|
target object for a non-search operation.
|
||
|
|
||
|
It is to also be noted that multiple ref attributes are allowed in any
|
||
|
entry and, where these sections refer to a single ref attribute, multi-
|
||
|
ple ref attributes may be substituted and should be processed and
|
||
|
returned as a group in an LDAPResult or search result in the same way as
|
||
|
described for a single attribute. The order of the returned continuation
|
||
|
references within a result is not defined.
|
||
|
|
||
|
|
||
|
5.1.1.1. Example configuration
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 4]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
|------------------------------------------------------------|
|
||
|
| 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". For the "o=abc,c=us" entry, Server A holds two refer-
|
||
|
ences, 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 the entry contained in Server D.
|
||
|
|
||
|
In the following protocol interaction examples, the client has contacted
|
||
|
Server A. Server A holds the naming context "c=us".
|
||
|
|
||
|
5.1.1.2. Base or target object considerations
|
||
|
|
||
|
As previously described, the process of generating referrals for a
|
||
|
search can be described in two phases. The first, which is described in
|
||
|
this section, is generating referrals based on the base object specified
|
||
|
in the search. This process is identical to the process of generating
|
||
|
referrals based on the target object while processing other operations
|
||
|
(modify, add, delete, modify DN, and compare) with the sole exception
|
||
|
that for these other operations, the DN in the referral must be modified
|
||
|
in some cases.
|
||
|
|
||
|
If a client requests any of these operations, there are four cases that
|
||
|
the server must handle with respect to the base or target object speci-
|
||
|
fied in the request.
|
||
|
|
||
|
Case 1: The base or target object is not held by the server and is not
|
||
|
subordinate to any object held by the server with a ref attribute.
|
||
|
|
||
|
The handling of this case is described in section 6.
|
||
|
|
||
|
Case 2: The base or target object is held by the server and contains a
|
||
|
ref attribute
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 5]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
In this case, if the type of operation requested is a search or the URI
|
||
|
contained in the ref attribute of the requested base object is NOT an
|
||
|
LDAP URI as defined in [RFC2255], the server should return the URI value
|
||
|
contained in the ref attribute of the base object whose DN is the DN
|
||
|
requested by the client as the base for the operation.
|
||
|
|
||
|
Example:
|
||
|
|
||
|
If the client issues a search in which the base object is "o=xyz,c=us",
|
||
|
server A will 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 target object is an LDAP URI
|
||
|
[RFC2255], the server should return a modified form of this URL. The
|
||
|
returned URL must have only the protocol, host, port, and trailing "/"
|
||
|
portion of the URL contained in the ref attribute. The server should
|
||
|
strip any dn, attributes, scope, and filter parts of the URL.
|
||
|
|
||
|
Example:
|
||
|
|
||
|
If the client issues a modify request for the target object of
|
||
|
"o=abc,c=us", server A will return
|
||
|
|
||
|
ModifyResponse "referral" {
|
||
|
ldap://hostB/
|
||
|
ldap://hostC/
|
||
|
}
|
||
|
|
||
|
Case 3: The base or target object is not held by the server, but is
|
||
|
subordinate to an object with a ref attribute held by the server.
|
||
|
|
||
|
|
||
|
If a client requests an operation for which the base or target object is
|
||
|
not held by the server, but is subordinate to one or more objects with a
|
||
|
ref attribute held by the server, the server must return the referral
|
||
|
from the superior held object nearest to the requested base or target
|
||
|
object. Nearest superior object with a referral, in this document, means
|
||
|
an object superior to the base or target object with the DN that has the
|
||
|
most attribute values in common with the DN of the base or target object
|
||
|
and contains a ref attribute.
|
||
|
|
||
|
The process of finding the nearest superior object can be envisioned as
|
||
|
walking up the locally held part of the DIT from the requested base or
|
||
|
target object checking each superior object until either an object with
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 6]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
a ref attribute is found or the top-most locally held object is reached.
|
||
|
Once possible implementation of this algorithm is as follows:
|
||
|
|
||
|
1. Remove the leftmost attribute/value pair from the DN of the
|
||
|
requested base or target object.
|
||
|
2. If the remaining DN represents a locally held object that contains
|
||
|
a ref attribute, that object is the nearest superior object with a
|
||
|
referral. Stop and process the referral as described below.
|
||
|
3. If the remaining DN is the root of the locally held part of the
|
||
|
DIT, stop and proceed as described in section 6.
|
||
|
4. Continue with step 1.
|
||
|
|
||
|
Once the nearest superior object has been identified, if the referral
|
||
|
contained in that object is not an LDAP URI [RFC2255], it should be
|
||
|
returned as-is. If the referral is an LDAP URI, the referral must be
|
||
|
modified, regardless of the type of operation, as case 2 describes for a
|
||
|
non-search requuest. That is, the dn, attributes, scope, and filter
|
||
|
parts of the URL must be stripped from the referral and the referral
|
||
|
returned.
|
||
|
|
||
|
Example:
|
||
|
|
||
|
If the client issues an add request where the target object has a DN of
|
||
|
"cn=Chris Lukas,o=abc,c=us", server A will return
|
||
|
|
||
|
AddResponse "referral" {
|
||
|
ldap://hostB/
|
||
|
ldap://hostC/
|
||
|
}
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
5.1.1.3. Search with one level scope
|
||
|
|
||
|
For search operations, once the base object has been found and deter-
|
||
|
mined not to contain a ref attribute, the search may progress. Any
|
||
|
entries matching the filter and scope of the search that do NOT contain
|
||
|
a ref attribute are returned to the client normally as described in
|
||
|
[RFC2251]. Any entries matching the filter and one level scope that do
|
||
|
contain a ref attribute must be returned as referrals as described here.
|
||
|
|
||
|
If a matching entry contains a ref attribute and the URI contained in
|
||
|
the ref attribute is NOT an LDAP URI [RFC2255], the server should return
|
||
|
the URI value contained in the ref attribute of that entry in a Sear-
|
||
|
chResultReference.
|
||
|
|
||
|
If a matching entry contains a ref attribute in the LDAP URI syntax
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 7]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
[RFC2255], the URL from the ref attribute must be modified before it is
|
||
|
returned by adding or substituting a "base" scope into the URL. If the
|
||
|
URL does not contain a scope specifier, the "base" scope specifier must
|
||
|
be added. If the URL does contain a scope specifier, the existing scope
|
||
|
specifier must be replaced by the "base" scope.
|
||
|
|
||
|
Example:
|
||
|
|
||
|
If a client requests a one level search of "c=US" then, in addition to
|
||
|
any entries one level below the "c=US" naming context matching the
|
||
|
filter (shown below as "... SearchResultEntry responses ..."), the
|
||
|
server will also return referrals modified to include the "base" scope
|
||
|
to maintain the one level search semantics.
|
||
|
|
||
|
The order of the SearchResultEntry responses and the SearchResultRefer-
|
||
|
ence responses is undefined. One possible sequence is shown.
|
||
|
|
||
|
... SearchResultEntry responses ...
|
||
|
|
||
|
SearchResultReference {
|
||
|
ldap://hostB/o=abc,c=us??base
|
||
|
ldap://hostC/o=abc,c=us??base
|
||
|
}
|
||
|
|
||
|
SearchResultReference {
|
||
|
ldap://hostD/o=xyz,c=us??base
|
||
|
}
|
||
|
|
||
|
SearchResultDone "success"
|
||
|
|
||
|
|
||
|
5.1.1.4. Search with subtree scope
|
||
|
|
||
|
For a search operation with a subtree scope, once the base object has
|
||
|
been found, the search progresses. As with the one level search, any
|
||
|
entries matching the filter and scope of the search that do NOT contain
|
||
|
a ref attribute are returned to the client normally as described in
|
||
|
[RFC2251].
|
||
|
|
||
|
If an entry matching the requested scope and filter contains a ref
|
||
|
attribute, the server should return the URI value in a SearchResul-
|
||
|
tReference.
|
||
|
|
||
|
Example:
|
||
|
|
||
|
If a client requests a subtree search of "c=us", then in addition to any
|
||
|
entries in the "c=us" naming context which match the filter, Server A
|
||
|
will also return two continuation references. As described in the
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 8]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
preceding section, the order of the responses is not defined.
|
||
|
|
||
|
One possible response might be:
|
||
|
|
||
|
... SearchResultEntry responses ...
|
||
|
|
||
|
SearchResultReference {
|
||
|
ldap://hostB/o=abc,c=us
|
||
|
ldap://hostC/o=abc,c=us
|
||
|
}
|
||
|
|
||
|
SearchResultReference {
|
||
|
ldap://hostD/o=xyz,c=us
|
||
|
}
|
||
|
|
||
|
SearchResultDone "success"
|
||
|
|
||
|
|
||
|
6. Superior Reference
|
||
|
|
||
|
An LDAP server may be configured to return a superior reference in the
|
||
|
case where the server does not hold either the requested base object or
|
||
|
an object containing a ref attribute that is superior to that base
|
||
|
object.
|
||
|
|
||
|
An LDAP server's root DSE MAY contain a ref attribute. The values of the
|
||
|
ref attribute in the root DSE that are LDAP URIs SHOULD NOT contain any
|
||
|
dn part, just the host name and optional port number.
|
||
|
|
||
|
If the LDAP server's root DSE contains a ref attribute and a client
|
||
|
requests an object not held by the server and not subordinate to any
|
||
|
held object, the server must return the URI component of the values in
|
||
|
the ref attribute of the root DSE as illustrated in the example.
|
||
|
|
||
|
If the LDAP server's root DSE does not contain a ref attribute, the
|
||
|
server may return one or more references that the server determines via
|
||
|
a method not defined in this document to be appropriate.
|
||
|
|
||
|
The default reference may be to any server that might contain more
|
||
|
knowledge of the namespace than the responding server. In particular,
|
||
|
the client must not expect the superior reference to be identical from
|
||
|
session to session as the reference may be dynamically created by the
|
||
|
server based on the details of the query submitted by the client.
|
||
|
|
||
|
When the server receives an operation for which the base or target entry
|
||
|
of the request is not contained in or subordinate to any naming context
|
||
|
held by the server or a referral entry, the server will return an
|
||
|
LDAPResult with the resultCode set to "referral", and with the referral
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 9]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
field filled with a referral that the server has determined to be
|
||
|
appropriate.
|
||
|
|
||
|
Example:
|
||
|
|
||
|
If a client requests a subtree search of "c=de" from server A in the
|
||
|
example configuration, and server A has the following ref attribute
|
||
|
defined in it's root DSE:
|
||
|
|
||
|
ref: ldap://hostG/
|
||
|
|
||
|
then server A will return
|
||
|
|
||
|
SearchResultDone "referral" {
|
||
|
ldap://hostG/
|
||
|
}
|
||
|
|
||
|
|
||
|
7. The referral object class
|
||
|
|
||
|
The referral object class is defined as follows.
|
||
|
|
||
|
( 2.16.840.1.113730.3.2.6 NAME 'referral' SUP top STRUCTURAL
|
||
|
MAY ( ref ) )
|
||
|
|
||
|
The referral object class is a subclass of top and may contain the
|
||
|
referral attribute. The referral object class should, in general, be
|
||
|
used in conjunction with the extensibleObject object class to support
|
||
|
the naming attributes used in the entry's distinguished name.
|
||
|
|
||
|
Servers must support the ref attribute through use of the referral
|
||
|
object class. Any named reference must be of the referral object class
|
||
|
and will likely also be of the extensibleObject object class to support
|
||
|
naming and use of other attributes.
|
||
|
|
||
|
8. The manageDsaIT control
|
||
|
|
||
|
A client MAY specify the following control when issuing a search, com-
|
||
|
pare, add, delete, modify, or modifyDN request or an extended operation
|
||
|
for which the control is defined.
|
||
|
|
||
|
The control type is 2.16.840.1.113730.3.4.2. The control SHOULD be
|
||
|
marked as critical. There is no value; the controlValue field is
|
||
|
absent.
|
||
|
|
||
|
This control causes entries with the "ref" attribute to be treated as
|
||
|
normal entries, allowing clients to read and modify these entries.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 10]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
This control is not needed if the entry containing the referral attri-
|
||
|
bute is one used for directory administrative purposes, such as the root
|
||
|
DSE, or the server change log entries. Operations on these entries
|
||
|
never cause referrals or continuation references to be returned.
|
||
|
|
||
|
9. Relationship to X.500 Knowledge References
|
||
|
|
||
|
The X.500 standard defines several types of knowledge references, used
|
||
|
to bind together different parts of the X.500 namespace. In X.500,
|
||
|
knowledge references can be associated with a set of unnamed entries
|
||
|
(e.g., a reference, associated with an entry, to a server containing the
|
||
|
descendants of that entry).
|
||
|
|
||
|
This creates a potential problem for LDAP clients resolving an LDAPv3
|
||
|
URL referral referring to an LDAP directory back-ended by X.500. Sup-
|
||
|
pose the search is a subtree search, and that server A holds the base
|
||
|
object of the search, and server B holds the descendants of the base
|
||
|
object. The behavior of X.500(1993) subordinate references is that the
|
||
|
base object on server A is searched, and a single continuation reference
|
||
|
is returned pointing to all of the descendants held on server B.
|
||
|
|
||
|
An LDAP URI only allows the base object to be specified. It is not pos-
|
||
|
sible using standard LDAP URIs to indicate a search of several entries
|
||
|
whose names are not known to the server holding the superior entry.
|
||
|
|
||
|
X.500 solves this problem by having two fields, one indicating the pro-
|
||
|
gress of name resolution and the other indicating the target of the
|
||
|
search. In the above example, name resolution would be complete by the
|
||
|
time 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 of
|
||
|
name resolution.
|
||
|
|
||
|
10. Security Considerations
|
||
|
|
||
|
This document defines mechanisms that can be used to "glue" LDAP (and
|
||
|
other) servers together. The information used to specify this glue
|
||
|
information should be protected from unauthorized modification. If the
|
||
|
server topology information itself is not public information, the infor-
|
||
|
mation should be protected from unauthorized access as well.
|
||
|
|
||
|
Clients should use caution when re-using credentials while following
|
||
|
referrals as the client may be directed to any server which may or may
|
||
|
not respect or use those credentials appropriately.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 11]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
11. 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 Lev-
|
||
|
els", RFC 2119, March 1997. (Format: TXT=4723 bytes) (Also BCP0014)
|
||
|
(Status: BEST CURRENT PRACTICE)
|
||
|
|
||
|
[RFC2251]
|
||
|
M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
|
||
|
(v3)", RFC 2251, December 1997.
|
||
|
|
||
|
[RFC2255]
|
||
|
T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December, 1997.
|
||
|
(Format: TXT=20685 bytes) (Status: PROPOSED STANDARD)
|
||
|
|
||
|
[X500]
|
||
|
ITU-T Rec. X.501, "The Directory: Models", 1993.
|
||
|
|
||
|
12. Author's Address
|
||
|
|
||
|
Tim Howes
|
||
|
Netscape Communications Corp.
|
||
|
501 E. Middlefield Rd.
|
||
|
Mailstop MV068
|
||
|
Mountain View, CA 94043
|
||
|
USA
|
||
|
+1 650 937-3419
|
||
|
EMail: howes@netscape.com
|
||
|
|
||
|
Christopher E. Lukas
|
||
|
Internet Scout Project
|
||
|
Computer Sciences Dept.
|
||
|
University of Wisconsin-Madison
|
||
|
1210 W. Dayton St.
|
||
|
Madison, WI 53706
|
||
|
USA
|
||
|
EMail: lukas@cs.wisc.edu
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 12]
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
INTERNET-DRAFT LDAPv3 Named Referrals March 1999
|
||
|
|
||
|
|
||
|
Michael Roszkowski
|
||
|
Internet Scout Project
|
||
|
Computer Sciences Dept.
|
||
|
University of Wisconsin-Madison
|
||
|
1210 W. Dayton St.
|
||
|
Madison, WI 53706
|
||
|
USA
|
||
|
EMail: mfr@cs.wisc.edu
|
||
|
|
||
|
Mark C. Smith
|
||
|
Netscape Communications Corp.
|
||
|
501 E. Middlefield Rd.
|
||
|
Mailstop MV068
|
||
|
Mountain View, CA 94043
|
||
|
USA
|
||
|
EMail: mcs@netscape.com
|
||
|
|
||
|
Mark Wahl
|
||
|
Innosoft International, Inc.
|
||
|
8911 Capital of Texas Hwy #4140
|
||
|
Austin TX 78759
|
||
|
EMail: M.Wahl@innosoft.com
|
||
|
|
||
|
|
||
|
This draft expires December 6, 1999.
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
Howes, et al. IETF LDAPEXT Working Group [Page 13]
|
||
|
|
||
|
|