#$@%#$%!

Ngiler SH3LL 360
: / opt / alt / openldap11 / share / doc / alt-openldap11-devel / drafts /

Information Server
MySQL : OFF Perl : OFF CURL : ON WGET : OFF PKEXEC : OFF

Directive	Local Value
IP Address	162.0.209.101
System	Linux premium169.web-hosting.com 4.18.0-553.50.1.lve.el8.x86_64 #1 SMP Thu Apr 17 19:10:24 UTC 2025 x86_64
User	luxeelil
PHP Version	8.0.30
Software	LiteSpeed
Doc root	Writable

Edit File : draft-sermersheim-ldap-distproc-xx.txt \| Size : 82.27 KB
Network Working Group J. Sermersheim Internet-Draft Novell, Inc Expires: August 26, 2005 February 22, 2005 Distributed Procedures for LDAP Operations draft-sermersheim-ldap-distproc-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on August 26, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides the data types and procedures used while servicing Lightweight Directory Access Protocol (LDAP) user operations in order to participate in a distributed directory. In particular, it describes the way in which an LDAP user operation in a distributed directory environment finds its way to the proper DSA(s) for servicing. Sermersheim Expires August 26, 2005 [Page 1] Internet-Draft Distributed Procedures for LDAP Operations February 2005 Discussion Forum Technical discussion of this document will take place on the IETF LDAP Extensions mailing list <ldapext@ietf.org>. Please send editorial comments directly to the author. Table of Contents 1. Distributed Operations Overview . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Distributed Operation Data Types . . . . . . . . . . . . . . 5 3.1 ContinuationReference . . . . . . . . . . . . . . . . . . . 5 3.2 ChainedRequest . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Chained Response . . . . . . . . . . . . . . . . . . . . . . 11 4. Distributed Procedures . . . . . . . . . . . . . . . . . . . 14 4.1 Name resolution . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Operation Evaluation . . . . . . . . . . . . . . . . . . . . 16 4.3 Populating the ContinuationReference . . . . . . . . . . . . 19 4.4 Sending a ChainedRequest . . . . . . . . . . . . . . . . . . 21 4.5 Emulating the Sending of a ChainedRequest . . . . . . . . . 23 4.6 Receiving a ChainedRequest . . . . . . . . . . . . . . . . . 24 4.7 Returning a Chained Response . . . . . . . . . . . . . . . . 25 4.8 Receiving a Chained Response . . . . . . . . . . . . . . . . 26 4.9 Returning a Referral or Intermediate Referral . . . . . . . 27 4.10 Acting on a Referral or Intermediate Referral . . . . . . . 30 4.11 Ensuring non-existence of an entry under an nssr . . . . . . 31 4.12 Mapping a referralURI to an LDAP URI . . . . . . . . . . . . 31 4.13 Using the ManageDsaIT control . . . . . . . . . . . . . . . 32 5. Security Considerations . . . . . . . . . . . . . . . . . . 33 6. Normative References . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . 34 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 A.1 LDAP Object Identifier Registrations . . . . . . . . . . . . 35 A.2 LDAP Protocol Mechanism Registrations . . . . . . . . . . . 35 A.3 LDAP Descriptor Registrations . . . . . . . . . . . . . . . 37 A.4 LDAP Result Code Registrations . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . 39 Sermersheim Expires August 26, 2005 [Page 2] Internet-Draft Distributed Procedures for LDAP Operations February 2005 1. Distributed Operations Overview One characteristic of X.500-based directory systems [X500] is that, given a distributed Directory Information Tree (DIT), a user should potentially be able to have any service request satisfied (subject to security, access control, and administrative policies) irrespective of the Directory Service Agent (DSA) to which the request was sent. To accommodate this requirement, it is necessary that any DSA involved in satisfying a particular service request have some knowledge (as specified in {TODO: Link to future Distributed Data Model doc}) of where the requested information is located and either return this knowledge to the requester or attempt to satisfy the request satisfied on the behalf of the requester (the requester may either be a Directory User Agent (DUA) or another DSA). Two modes of operation distribution are defined to meet these requirements, namely "chaining" and "returning referrals". "Chaining" refers to the attempt by a DSA to satisfy a request by sending one or more chained operations to other DSAs. "Returning referrals", is the act of returning distributed knowledge information to the requester, which may then itself interact with the DSA(s) identified by the distributed knowledge information. It is a goal of this document to provide the same level of service whether the chaining or referral mechanism is used to distribute an operation. The processing of an operation is talked about in two major phases, namely "name resolution", and "operation evaluation". Name resolution is the act of locating a local DSE held on a DSA given a distinguished name (DN). Operation evaluation is the act of performing the operation after the name resolution phase is complete. While distributing an operation, a request operation may be decomposed into several sub-operations. The distributed directory operation procedures described in this document assume the absense of the ManageDsaIT control defined in [RFC3296] and described in Section 4.13. Sermersheim Expires August 26, 2005 [Page 3] Internet-Draft Distributed Procedures for LDAP Operations February 2005 2. Conventions Imperative keywords defined in [RFC2119] are used in this document, and carry the meanings described there. All Basic Encoding Rules (BER) [X690] encodings follow the conventions found in Section 5.1 of [RFC2251]. Sermersheim Expires August 26, 2005 [Page 4] Internet-Draft Distributed Procedures for LDAP Operations February 2005 3. Distributed Operation Data Types The data types in this section are used by the chaining and referral distributed operation mechanisms described in Section 4 3.1 ContinuationReference As an operation is being processed by a DSA, it is useful to group the information passed between various procedures as a collection of data. The ContinuationReference data type is introduced for this purpose. This data type is populated and consumed by various procedures discussed in various sections of this document. In general, a ContinuationReference is used when indicating that directory information being acted on is not present locally, but may be present elsewhere. A ContinuationReference consists of one or more addresses which identify remote DSAs along with other information pertaining both to the distributed knowledge information held on the local DSA as well as information relevant to the operation. This data type is expressed here in Abstract Syntax Notation One (ASN.1) [X680]. ContinuationReference ::= SET { referralURI [0] SET SIZE (1..MAX) OF URI, localReference [2] LDAPDN, referenceType [3] ReferenceType, remainingName [4] RelativeLDAPDN OPTIONAL, searchScope [5] SearchScope OPTIONAL, searchedSubtrees [6] SearchedSubtrees OPTIONAL, failedName [7] LDAPDN OPTIONAL, ... } <Editor's Note: Planned for addition is a searchCriteria field which is used both for assuring that the remote object is in fact the object originally pointed to (this mechanism provides a security measure), and also to allow moved or renamed remote entries to be found. Typically the search criteria would have a filter value of (entryUUID=<something>)> URI ::= LDAPString -- limited to characters permitted in URIs [RFC2396]. ReferenceType ::= ENUMERATED { superior (0), subordinate (1), cross (2), nonSpecificSubordinate (3), Sermersheim Expires August 26, 2005 [Page 5] Internet-Draft Distributed Procedures for LDAP Operations February 2005 suplier (4), master (5), immediateSuperior (6), self (7), ... } SearchScope ::= ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2), subordinateSubtree (3), ... } SearchedSubtrees ::= SET OF RelativeLDAPDN LDAPDN, RelativeLDAPDN, and LDAPString, are defined in [RFC2251]. The following subsections introduce the fields of the ContinuationReference data type, but do not provide in-depth semantics or instructions on the population and consumption of the fields. These topics are discussed as part of the procedural instructions. 3.1.1 ContinuationReference.referralURI The list of referralURI values is used by the receiver to progress the operation. Each value specifies (at minimum) the protocol and address of one or more remote DSA(s) holding the data sought after. URI values which are placed in ContinuationReference.referralURI must allow for certain elements of data to be conveyed. Section 3.1.1.1 describes these data elements. Furthermore, a mapping must exist which relates the parts of a specified URI to these data elements. This document provides such a mapping for the LDAP URL [RFC2255] in Section 4.12. In some cases, a referralURI will contain data which has a counterpart in the fields of the ContinuationReference (an example is where the referralURI is an LDAP URL, holds a <scope> value, and the ContinuationReference.searchScope field is also present). In these cases, the data held on the referralURI overrides the field in the ContinuationReference. Specific examples of this are highlighted in other sections. Providing a means for these values to exist as fields of the ContinuationReference allows one value to be applied to all values of referralURI (as opposed to populating duplicate data on all referralURI values). If a referralURI value identifies an LDAP-enabled DSA [RFC3377], the LDAP URL form is used. Sermersheim Expires August 26, 2005 [Page 6] Internet-Draft Distributed Procedures for LDAP Operations February 2005 3.1.1.1 Elements of referralURI Values The following data elements must be allowed and identified for a specified URI type to be used to convey referral information. Each element is given a name which begins with 'referralURI.' for clarity when referencing the elements conceptually in other parts of this document. o referralURI.protocolIdentifier. There must be an indication of the protocol to be used to contact the DSA identified by the URI. o referralURI.accessPoint. The URI must identify a DSA in a manner that can be used to contact it using the protocol specified in protocolIdentifier. o referralURI.targetObject. Holds the name to be used as the base DN of the operation being progressed. This field must be allowed by the URI specification, but may be omitted in URI instances for various reasons. o referralURI.localReference. See Section 3.1.2. This field must be allowed by the URI specification, but may be omitted in URI instances for various reasons. o referralURI.searchScope. See Section 3.1.5. This field must be allowed by the URI specification, but may be omitted in URI instances for various reasons. o referralURI.searchedSubtrees. See Section 3.1.6. This field must be allowed by the URI specification, but may be omitted in URI instances for various reasons. o referralURI.failedName. See Section 3.1.7. This field must be allowed by the URI specification, but may be omitted in URI instances for various reasons. 3.1.2 ContinuationReference.localReference This names the DSE which was found to hold distributed knowledge information, and thus which caused the ContinuationReference to be formed. This field is primarily used to help convey the new target object name, but may also be used for purposes referential integrity (not discussed here). In the event that the root object holds the distributed knowledge information, this field is present and is populated with an empty DN. 3.1.3 ContinuationReference.referenceType Indicates the DSE Type of the ContinuationReference.localReference. This field may be used to determine how to progress an operations (i.e. if the value is nonSpecificSubordinate, a search continuation will exclude the ContinuationReference.referenceType). Sermersheim Expires August 26, 2005 [Page 7] Internet-Draft Distributed Procedures for LDAP Operations February 2005 3.1.4 ContinuationReference.remainingName In certain scenarios, the localReference does not completely name the DSE to be used as the new target object name. In these cases, remainingName is populated with the RDNSequence relative to the localReference of the target object name being resolved. Some examples of these scenarios include (but are not restricted to): o During name resolution, the name is not fully resolved, but a DSE holding distributed knowledge information is found, causing a ContinuationReference to be generated. o While searching, an alias is dereferenced. The aliasedObjectName points to a DSE of type glue which is subordinate to a DSE holding distributed knowledge information. 3.1.5 ContinuationReference.searchScope Under certain circumstances, when progressing a search operation, a search scope different than that of the original search request must be used. This field facilitates the conveyance of the proper search scope to be used when progressing the distributed operation. The scope of subordinateSubtree has been added to the values allowed by the LDAP SearchRequest.scope field. This scope includes the subtree of entries below the base DN, but does not include the base DN itself. This is used here when progressing distributed search operations caused by the existence of a DSE of type nssr. If a referralURI.searchScope is present, it overrides this field while that referralURI is being operated upon. 3.1.6 ContinuationReference.searchedSubtrees For ContinuationReferences generated while processing a search operation with a scope of wholeSubtree, each value of this field indicates that a particular subtree below the target object has already been searched. Consumers of this data use it to cause the progression of the search operation to exclude these subtrees as a mechanism to avoid receiving duplicate entries. If a referralURI.searchedSubtrees is present, it overrides this field while that referralURI is being operated upon. 3.1.7 ContinuationReference.failedName When an operation requires that multiple names be resolved (as is the case with the ModifyDN operation), this field is used to specify which name was found to be non-local. Sermersheim Expires August 26, 2005 [Page 8] Internet-Draft Distributed Procedures for LDAP Operations February 2005 If a referralURI.failedName is present, it overrides this field while that referralURI is being operated upon. 3.2 ChainedRequest The Chained Request is sent as an LDAP extended operation. The requestName is IANA-ASSIGNED-OID.1. The requestValue is the BER encoding of the following ChainedRequestValue ASN.1 definition: ChainedRequestValue ::= SEQUENCE { chainingArguments ChainingArguments, operationRequest OperationRequest } ChainingArguments ::= SEQUENCE { targetObject [0] LDAPDN OPTIONAL, referenceType [1] ReferenceType, traceInformation [2] ChainingTraceInformation, searchScope [3] SearchScope OPTIONAL, searchedSubtrees [4] SearchedSubtrees OPTIONAL} ChainingTraceInformation ::= SET OF LDAPURL OperationRequest ::= SEQUENCE { Request ::= CHOICE { bindRequest BindRequest, searchRequest SearchRequest, modifyRequest ModifyRequest, addRequest AddRequest, delRequest DelRequest, modDNRequest ModifyDNRequest, compareRequest CompareRequest, extendedReq ExtendedRequest, ... }, controls [0] Controls COPTIONAL } BindRequest, SearchRequest, ModifyRequest, AddRequest, DelRequest, ModifyDNRequest, CompareRequest, ExtendedRequest and Controls are defined in [RFC2251]. 3.2.1 ChainedRequestValue.chainingArguments In general, these fields assist in refining the original operation as it is to be executed on the receiving DSA. Sermersheim Expires August 26, 2005 [Page 9] Internet-Draft Distributed Procedures for LDAP Operations February 2005 3.2.1.1 ChainedRequestValue.chainingArguments.targetObject This field contains the new target (or base) DN for the operation. The sending DSA populates this under different scenarios including the case where an alias has been dereferenced while resolving the DN, and also the case where a referral carries a target name different from the reference object that caused the referral. This field can be omitted only if it would be the the same value as the object or base object parameter in the ChainedRequestValue.operationRequest, in which case its implied value is that value. The receiving DSA examines this field and (if present) uses it rather than the base DN held in the ChainedRequestValue.operationRequest. 3.2.1.2 ChainedRequestValue.chainingArguments.referenceType See Section 3.1.3. If the receiver encounters a value of nonSpecificSubordinate in this field, it indicates that the operation is being chained due to DSE of type nssr. In this case, the receiver allows (and expects) the base DN to name the immediate superior of a context prefix. 3.2.1.3 ChainedRequestValue.chainingArguments.traceInformation This contains a set of URIs. Each value represents the address of a DSA and DN that has already been contacted while attempting to service the operation. This field is used to detect looping while servicing a distributed operation. The sending DSA populates this with its own URI, and also the URIs of any DSAs that have already been chained to. The receiving DSA examines this list of URIs and returns a loopDetect error if it finds that any of the addresses and DNs in the listed URI's represent it's own. 3.2.1.4 ChainedRequestValue.chainingArguments.searchScope See Section 3.1.5. 3.2.1.5 ChainedRequestValue.chainingArguments.searchedSubtrees See Section 3.1.6. Sermersheim Expires August 26, 2005 [Page 10] Internet-Draft Distributed Procedures for LDAP Operations February 2005 3.2.2 ChainedRequestValue.operationRequest This holds the original LDAP operation request. This is restricted to a subset of all LDAP operations. Namely, the following LDAP operation types are not allowed: o Abandon/Cancel operations. When an abandon or cancel operation needs to be chained, it is sent to the remote DSA as-is. This is because there is no need to track it for loop detection or pass on any other information normally found in ChainingArguments. o Unbind. Again, there is no need to send chaining-related information to a DSA to perform an unbind. DSAs which chain operations maintain connections as they see fit. o Chained Operation. When a DSA receives a chained operation, and must again chain that operation to a remote DSA, it sends a ChainedRequest where the ChainedRequestValue.operationRequest is that of the incoming ChainedRequestValue.operationRequest. 3.3 Chained Response The Chained Response is sent as an LDAP IntermediateResponse [RFC3771], or LDAP ExtendedResponse [RFC2251], depending on whether the operation is complete or not. In either case, the responseName is omitted. For intermediate responses, the IntermediateResponse.responseValue is the BER encoding of the ChainedIntermediateResponseValue ASN.1 definition. For completed operations, the ExtendedResponse.value is the BER encoding of the ChainedFinalResponseValue ASN.1 definition. ChainedIntermediateResponseValue ::= SEQUENCE { chainedResults ChainingResults, operationResponse IntermediateResponse } ChainedFinalResponseValue ::= SEQUENCE { chainedResults ChainingResults, operationResponse FinalResponse } ChainingResults ::= SEQUENCE { searchedSubtrees [0] SearchedSubtrees OPTIONAL, ... } IntermediateResponse ::= SEQUENCE { Response ::= CHOICE { Sermersheim Expires August 26, 2005 [Page 11] Internet-Draft Distributed Procedures for LDAP Operations February 2005 searchResEntry SearchResultEntry, searchResRef SearchResultReference, intermediateResponse IntermediateResponse ... }, controls [0] Controls COPTIONAL } FinalResponse ::= SEQUENCE { Response ::= CHOICE { bindResponse BindResponse, searchResDone SearchResultDone, modifyResponse ModifyResponse, addResponse AddResponse, delResponse DelResponse, modDNResponse ModifyDNResponse, compareResponse CompareResponse, extendedResp ExtendedResponse, ... }, controls [0] Controls COPTIONAL } BindResponse, SearchResultEntry, SearchResultDone, SearchResultReference, ModifyResponse, AddResponse, DelResponse, ModifyDNResponse, CompareResponse, ExtendedResponse, and Controls are defined in [RFC2251]. IntermediateResponse is defined in [RFC3771]. 3.3.1 ChainingResults In general, this is used to convey additional information that may needed in the event that the operation needs to be progressed further. 3.3.1.1 ChainingResults.searchedSubtrees Each value of this field indicates that a particular subtree below the target object has already been searched. This is particularly useful while chaining search operations during operation evaluation caused by the presence of a DSA of type nssr. Each DSA referenced by the nssr holds one or more naming contexts subordinate to the nssr DSE. The ChainingResults.searchedSubtrees field allows the DSA being chained to, to inform the sending DSA which subordinate naming contexts have been searched. This information may be passed to further DSAs listed on the nssr in order to reduce the possibility of duplicate entries being returned. Sermersheim Expires August 26, 2005 [Page 12] Internet-Draft Distributed Procedures for LDAP Operations February 2005 3.3.2 ChainedIntermediateResponseValue.intermediateResponse and ChainedFinalResponseValue.finalResponse This holds the directory operation response message tied to the ChainedRequestValue.operationRequest. Sermersheim Expires August 26, 2005 [Page 13] Internet-Draft Distributed Procedures for LDAP Operations February 2005 4. Distributed Procedures For the purposes of describing a distributed operation, operations are said to consist of two major phases -- name resolution and operation evaluation. These terms are adopted from [X518]. Name resolution is the act of locating a DSE said to be held locally by a DSA given a distinguished name (DN). Operation evaluation is the act of performing the operation after the name resolution phase is complete. Furthermore, there are two modes of distributing an operation -- chaining, and returning referrals. Chaining is the act of forwarding an unfinished operation to another DSA for completion (this may happen during name resolution or operation evaluation). In this case, the forwarding DSA sends a chained operation to a receiving DSA, which attempts to complete the operation. Alternately, the DSA may return a referral (or intermediate referral), and the client may use that referral in order to forward the unfinished operation to another DSA. Whether the operation is distributed via chaining or referrals is a decision left to the DSA and or DUA. The term 'intermediate referral' describes a referral returned during the operation evaluation phase of an operation. These include searchResultReferences, referrals returned with an intermediateResponse [RFC3771], or future referrals which indicate that they are intermediate referrals. An operation which is distributed while in the operation evaluation phase is termed a 'sub-operation'. This document inserts a step between the two distributed operation phases in order to commonize the data and processes followed prior to chaining an operation or returning a referral. This step consists of populating a ContinuationReference data type. 4.1 Name resolution Before evaluating (enacting) most directory operations, the DSE named by the target (often called the base DN) of the operation must be located . This is done by evaluating the RDNs of the target DN one at a time, starting at the rootmost RDN. Each RDN is compared to the DSEs held by the DSA until the set of RDNs is exhausted, or an RDN cannot be found. If the DSE named by the target is found to be local, the name resolution phase of the operation completes and the operation evaluation phase begins. Sermersheim Expires August 26, 2005 [Page 14] Internet-Draft Distributed Procedures for LDAP Operations February 2005 If it is found that the target does not name a local DSE nor a DSE that may held by another DSA, it is said that the target does not exist, and the operation fails with noSuchObject (subject to local policy). If it is found that the DSE named by the target is non-local to the DSA, but may reside elsewhere, name resolution is said to be incomplete. In this case, the operation may be distributed by creating a ContinuationReference (Section 4.3) and either chaining the operation (Section 4.4 and Section 4.5)or returning a referral (Section 4.9). 4.1.1 Determining that a named DSE is local to a DSA If a DSE held by a DSA falls within a naming context held by the DSA, or is the root DSE on a first-level DSA, it is said to be local to that DSA 4.1.2 Determining that a named DSE does not exist A named DSE is said to not exist if, during name resolution the DSE is not found, but if found it would fall within a naming context held by the DSA. 4.1.3 Determining that a named DSE is non-local If a named DSE is niether found to be local to the DSA, nor found to not exist, it is said to be non-local to a DSA. In this case, it is indeterminate whether the named DSE exists. When a named DSE is found to be non-local, there should be distributed knowledge information available to be used to either return a referral or chain the operation. 4.1.3.1 Locating distributed knowledge information for a non-local target If it has been determined that a target names a non-local DSE, distributed knowledge information may be found by first examining the DSE named by the target, and subsequently all superior DSEs beginning with the immediate superior and ending with the root, until an examined DSE is one of types: {TODO: should DSE types be all caps? It would be easier to read.} o subr o supr o immsupr Sermersheim Expires August 26, 2005 [Page 15] Internet-Draft Distributed Procedures for LDAP Operations February 2005 o xr o nssr The examined DSE which is of one of these types holds the distributed knowledge information for the non-local named target. This DSE is said to be the found distributed knowledge information of the non-local target. This found distributed knowledge information may then be used to distribute the operation. If no examined DSEs are of any of these types, the distributed knowledge information is mis-configured, and the error invalidReference is returned. 4.1.4 Special case for the Add operation During the name resolution phase of the Add operation, the immediate parent of the base DN is resolved. If the immediate parent of the entry to be added is a DSE of type nssr, then further interrogation is needed to ensure that the entry to be added does not exist. Methods for doing this are found in Section 4.11. {TODO: don't make this mandatory. Also, it doesn't work without transaction semantics. Same prob in the mod dn below.}. 4.1.5 Special case for the ModifyDN operation When the modifyDN operation includes a newSuperior name, it must be resolved as well as the base DN being modified. If either of these result in a non-local name, the name causing the operation to be distributed should be conveyed (Section 4.3.5). {TODO: also mention access control problems, and mention (impl detail) that affectsmultidsa can be used.} If during operation evaluation of a ModifyDN operation, the newSuperior names a DSE type of nssr, then further interrogation is needed to ensure that the entry to be added does not exist. Methods for doing this are found in Section 4.11. 4.2 Operation Evaluation Once name resolution has completed. The DSE named in the target has been found to be local to a DSA. At this point the operation can be carried out. During operation evaluation distributed knowledge information may be found that may cause the DSA to distribute the operation. When this happens, the operation may be distributed by creating a ContinuationReference (Section 4.3) and either chaining the operation (Section 4.4 and Section 4.5)or returning a referral (Section 4.9). Sermersheim Expires August 26, 2005 [Page 16] Internet-Draft Distributed Procedures for LDAP Operations February 2005 If, during the location of the distributed knowledge information, the distributed knowledge information is found to be mis-configured, operation semantics are followed (some operations may call for an error to be returned, while others call for the error to be ignored). {TODO: either make this more specific, or less specific, or just toss it out.} 4.2.1 Search operation During operation evaluation of a search operation, the DSA must determine whether there is distributed knowledge information in the scope of the search. Any DSE in the search scope which is of the following types is considered to be 'found distributed knowledge information' {TODO: use a better term than found distributed knowledge information} in the search scope: o subr o nssr (see nssr note) o xr {TODO: I think xr only qualifies when an alias is dereferenced to an xr. Otherwisw, there should always be a subr above the xr if it falls in the search scope.} Note that due to alias dereferencing, the search scope may expand to include entries outside of the scope originally specified in the search operation. {TODO: note that an aliased object may be glue which needs to result in any subr or xr above it to be found} Nssr Note: A DSE of type nssr is only considered to be found distributed knowledge information when the scope of the search includes entries below it. For example, when the search scope is wholeSubtree or subordinateSubtree and a DSE of type nssr is found in the scope, or if the search scope is singleLevel and the target object names a DSE of type nsssr. {TODO: The following sections are talking about how the continuation reference is to be populated. Move to next secion. Can probably just say that whole subtree or subordinare subtree encountering nssr, and single level rooted at nssr result in a continuation reference. base at, and single level above do not result in a continuation reference.} 4.2.1.1 Search operation with singleLevel scope If distributed knowledge information is found during operation evaluation of a search with a singleLevel scope, it will cause the resulting ContinuationReference.searchScope to be set to baseObject. Sermersheim Expires August 26, 2005 [Page 17] Internet-Draft Distributed Procedures for LDAP Operations February 2005 4.2.1.2 Search operation encountering nssr knowledge reference When a search operation encounters distributed knowledge information which is a DSE type of nssr during operation evaluation, the following instructions are followed: Note that when a search operation is being progressed due to nssr knowledge information, the subsequent distributed progression of the search is caused to be applied to each DSA listed as non-specific knowledge information (This is talked about in Section 4.3.2). In the event that multiple DSAs listed in the knowledge information hold copies of the same directory entries, the 'already searched' and 'duplicate elimination' mechanisms SHOULD be used to prevent duplicate search result entries from ultimately being returned. 4.2.1.2.1 wholeSubtree search scope When the search scope is wholeSubtree, the ContinuationReference.searchScope is set to subordinateSubtree. Because the ContinuationReference.referrenceType is set to nonSpecificSubordinate, the receiving protocol peer allows (and expects) name resolution to stop at an immsupr DSE type which is treated as a local DSE. The subordinateSubtree scope instructs the receiving protocol peer to exclude the target object from the sub-search. 4.2.1.2.2 singleLevel search scope When the search scope is singleLevel, and the base DN is resolved to a DSE of type nssr, subsequent distributed progressions of the search are caused to use the same base DN, and a scope of singleLevel. Receiving protocol peers will only apply the search to entries below the target object. When the search scope is singleLevel and an evaluated DSE is of type nssr, no special handling is required. The search is applied to that DSE if it is of type entry. 4.2.1.2.3 baseObject search scope No special handling is needed when the search scope is baseObject and the base DN is an nssr DSEType. The search is applied to that DSE if it is of type entry. 4.2.1.3 Search operation rooted at an nssr DSE type (TODO: a subordinateSubtree scope needs to change to wholeSubtree if references are found.) Sermersheim Expires August 26, 2005 [Page 18] Internet-Draft Distributed Procedures for LDAP Operations February 2005 4.3 Populating the ContinuationReference When an entry is found to be non-local to a DSA (whether during name resolution or operation evaluation), the DSA prepares for operation distribution by generating a ContinuationReference. This is a conceptual step, given to help explain the interactions that occur between discovering that an operation must be distributing, and actually invoking the operation distribution mechanism. Implementations are not required to perform this step, but will effectively work with the same information. After the ContinuationReference has been created, the DSA may choose to chain the operation or return a referral (or intermediate referral(s)). the ContinuationReference is made up of data held on the found distributed knowledge information, as well as state information gained during name resolution or operation evaluation. 4.3.1 Conveying the Target Object The consumer of the ContinuationReference will examine various fields in order to determine the target object name of the operation being progressed. The fields examined are the localReference and remainingName. If name resolution did not complete, and the found distributed knowledge information names the same DSE as the base DN of the operation, the ContinuationReference MAY omit the localReference and/or remainingName fields. localReference is populated with the name of the found distributed knowledge information DSE. In the event that the root object holds the distributed knowledge information, this field will be populated with an empty DN. Contrast this with the omission of this field. referenceType is populated with a value reflecting the reference type of the localReference DSE. remainingName is populated with the RDNSequence which has not yet been resolved. This is the difference between the localReference value and the name of the DSE to be resolved. In cases where the DSE named by the {TODO, use a dash or different term to make 'found distributed knowledge' more like a single term} found distributed knowledge is not the same as the base DN of the operation, the ContinuationReference must contain the localReference and/or remainingName fields. Such cases include but are not limited Sermersheim Expires August 26, 2005 [Page 19] Internet-Draft Distributed Procedures for LDAP Operations February 2005 to: o Distributed knowledge information is found during operation evaluation. o Aliases were dereferenced during name resolution. o Name resolution did not complete and there were remaining RDNs to be resolved. 4.3.2 Conveying the Remote DSA The referralURI field must contain at least one value. Each referralURI value must hold a referralURI.accessPoint. Other requirements on this field as noted may also apply. Note for nssr DSE types: During operation evaluation, if a DSE of type nssr causes the operation to be distributed (the scenarios in Section 4.2.1.2 are an example), then an intermediate referral {TODO: this is talking about referral/intermediate referral, but this section is only dealing with populating continuation reference} is returned for each value of the ref attribute, where each intermediate referral only holds a single referralURI value. 4.3.3 Conveying new search scope During the evaluation of the search operation, the instructions in Section 4.2.1.2.1 and Section 4.2.1.2.2 are followed and the searchScope field is updated with the new search scope. 4.3.4 Preventing duplicates In order to prevent duplicate entries from being evaluated while progressing a search operation, the searchedSubtrees field is populated with any naming context below the ContinuationReference.targetObject which have been fully searched. During the evaluation of the search operation, if the scope is wholeSubtree, it is possible that the DSA may search the contents of a naming context which is subordinate to another naming context which is subordinate to the search base (See figure). Sermersheim Expires August 26, 2005 [Page 20] Internet-Draft Distributed Procedures for LDAP Operations February 2005 O X / \ / \ / \ / \ \_______O Y /\|\ / \| \ / \| \ / \| \ A B O C / \ / \ / \ / \ \_______/ In this figure, the DSA holds the naming context X and C,Y,X, but not Y,X. If the search base was X, an intermediate referral would be returned for Y,X. The DSA holding Y,X may also hold a copy of C,Y,X. In this case, the receiver of the ContinuationReference benefits by knowing that the DSA already searched C,Y,X so that it can prevent other DSAs from returning those entries again. Data already searched is in the form of an RDNSequence, consisting of the RDNs relative to the target object. 4.3.5 Conveying the Failed Name At least one DS operation (modifyDN) requires that multiple DNs be resolved (the entry being modified and the newSuperior entry). In this case, the failedName field will be populated with the DN being resolved which failed name resolution. This may aid in the determination of how the operation is to be progressed. If both names are found to be non-local, this field is omitted. 4.4 Sending a ChainedRequest When an entry is found to be non-local to a DSA (whether during name resolution or operation evaluation), the DSA may progress the operation by sending a chained operation to another DSA (or DSAs). The instructions in this section assume that a ContinuationReference has been generated which will be used to form the ChainedRequest. It is also assumed that it can be determined whether the operation is being progressed due to name resolution or due to operation evaluation. A DSA which is able to chain operations may advertise this by Sermersheim Expires August 26, 2005 [Page 21] Internet-Draft Distributed Procedures for LDAP Operations February 2005 returning a value of IANA-ASSIGNED-OID.2; in the supportedFeatures attribute on the root DSE. {TODO: does this and discovery of the extended op belong in a new 'discovery mechanisms' sections.} 4.4.1 Forming a ChainedRequest The following fields are populated as instructed: 4.4.1.1 ChainedRequestValue.chainingArguments.targetObject The ContinuationReference may convey a new target object. If present, the ContinuationReference.localReference field becomes the candidate target object. Otherwise the candidate target object is assumed to be that of the original directory operation. Note that an empty value in the ContinuationReference.localReference field denotes the root object. After performing the above determination as to the candidate target object, any RDNSequence in ContinuationReference.remainingName is prepended to the determined candidate target object. This value becomes the ChainedRequestValue.chainingArguments.targetObject. If this value matches the value of the original operation, this field may be omitted. 4.4.1.2 ChainedRequestValue.chainingArguments.referenceType This is populated with the ContinuationReference.referralURI.referenceType. 4.4.1.3 ChainedRequestValue.chainingArguments.traceInformation This is populated as specified in Section 3.2.1.3. 4.4.1.4 ChainedRequestValue.chainingArguments.searchScope This is populated with the ContinuationReference.referralURI.searchScope if present, otherwise by the ContinuationReference.searchScope if present, and not populated otherwise. 4.4.1.5 ChainedRequestValue.chainingArguments.searchedSubtrees This is populated with ContinuationReference.searchedSubtrees, as well as any previously received values of ChainedFinalResponseValue.chainingResults.searchedSubtrees or ChainedIntermediateResponseValue.chainingResults.searchedSubtrees which are subordinate, relative to the target object. (If thsi is relative to the target object, it can't contain non-relative Sermersheim Expires August 26, 2005 [Page 22] Internet-Draft Distributed Procedures for LDAP Operations February 2005 subtrees) 4.4.1.6 ChainedRequestValue.operationRequest This is populated with the original directory operation request. 4.4.2 Attempting Each Referral URI A ContinuationReference consists of one or more referralURIs which represent(s a) remote DSA(s). The chaining DSA attempts to chain to each of these DSAs until one succeeds in completing the operation. An operation is considered to be completed if it reaches the remote DSA and a response is sent back that indicates that the operation was executed. Operations which are sent to the remote DSA, but don't complete are indicated by a result code of unavailable or busy. A result code of protocolError may indicate that the DSA does not support the chained operation, and in this case, it is also treated as an uncompleted operation. Other errors may in the future specify that they also indicate non-completion. Note that the response may itself contain referral(s), these are still considered completed operations and thus would subsequently be handled and chained. {TODO: could use soft/hard, or transient/permanent referral/non-referral error terms here.} 4.4.3 Loop Prevention Prior to sending a ChainedRequest, the DSA may attempt to prevent looping scenarios by comparing {TODO: what matching rule is used? Suggest we don't convert dns names to ip addresses due to NATs} the address of the remote DSA and target object to the values of ChainedRequestValue.chainingArguments.traceInformation. If a match is found, the DSA returns a loopDetect error. Note that while this type of loop prevention aids in detecting loops prior to sending data to a remote DSA, it is not a substitute for loop detection (Section Section 4.6.2). This is because the sending DSA is only aware of a single address on which the receiving DSA accepts connections. 4.5 Emulating the Sending of a ChainedRequest When it is determined that the operation cannot be distributed by means of the ChainedRequest, the chaining DSA may instead emulate the steps involved in chaining the operation. These steps consist of performing loop prevention, forming a new directory operation request from the original request and possibly updating the base DN, search scope, and search filter(in order to emulate searchedSubtrees), and, similar to the steps in Section 4.4.2, attempting to send the operation request to each DSA listed in the ContinuationReference.referralURI until one succeeds in completing Sermersheim Expires August 26, 2005 [Page 23] Internet-Draft Distributed Procedures for LDAP Operations February 2005 the operation. {TODO: We need a way (control) to tell the receiver to allow name resolution to end on the parent of a cp (typically an immsupr). This would be sent when the ContinuationReference.referenceType is nonSpecificSubordinate} 4.5.1 Emulated Loop Detection For this step, the loop prevention instructions in Section 4.4.3 are followed. Note that this method of loop detection may actually allow some looping to occur before the loop is detected. 4.5.2 Forming the New Request The new directory operation request is formed from the fields of the original request, and the following fields may be updated: o The base DN is formed from the new target object as determined by following the instructions in Section 4.4.1.1 and using the value which would have been placed in ChainedRequestValue.chainingArguments.targetObject. o For the search operation, the scope is populated with ContinuationReference.searchScope if present, otherwise the scope of the original operation request is used. o For the search operation, if the ContinuationReference.searchedSubtrees field is present, causes the search filter to be augmented by adding a filter item of the 'and' CHOICE. The filter consists of {TODO: weasel Kurt into finishing his entryDN draft and reference the appropriate section there. See <http://www.openldap.org/lists/ietf-ldapext/200407/msg00000.html> for context} o Other fields (such as the messageID, and non-critical controls) may also need to be updated or excluded. If the service being chained to does not support directory operations, other operations may be used as long as they provide the same level as service as those provided by the analogous directory operation. 4.6 Receiving a ChainedRequest A DSA which is able to receive and service a ChainedRequest may advertise this feature by returning a value of IANA-ASSIGNED-OID.1 in the supportedExtension attribute of the root DSE. {TODO: move?} The ChainedRequestValue data type is the requestValue of an Sermersheim Expires August 26, 2005 [Page 24] Internet-Draft Distributed Procedures for LDAP Operations February 2005 extendedRequest. In general, receiving and servicing a ChainedRequest consists of performing loop detection and, using components of the ChainedRequestType.chainingArguments along with the ChainedRequestType.operationRequest, service the request. 4.6.1 Target Object determination Prior to checking for a loop condition, the target object must be determined. If the ChainedRequestType.chainingArguments.targetObject field is present, its value becomes the target object. Otherwise, the base DN found in the ChainedRequestType.operationRequest becomes the target object. 4.6.2 Loop Detection The loop detection check happens when a DSA receives a chained operation, prior to acting on the operation. The DSA compares {TODO: matching rule? DNS expansion?} each value of ChainedRequestValue.traceInformation to the list of addresses at which it accepts directory communications. A value of ChainedRequestValue.traceInformation matches when the DSA accepts directory communications on the address found in the ChainedRequestValue.traceInformation value, and the target object (as determined in Section 4.6.1 matches the DN {TODO: using DN matching?} value found in the ChainedRequestValue.traceInformation value. If a match is found the DSA returns a loopDetect result. 4.6.3 Processing the ChainedRequestValue.operationRequest In processing the operationRequest, the DSA uses the target object determined in Section 4.6.1. For search operations, it uses the scope found in ChainedRequestValue.chainingArguments.searchScope, and excludes any subtrees relative to the target object indicated in ChainedRequestValue.chainingArguments.searchedSubtrees. Responses are returned in the form of a Chained Response. 4.7 Returning a Chained Response When returning responses to a ChainedRequest, the Chained Response as documented in Section 3.3 is used. If the ChainedFinalResponseValue.operationResponse is a searchResultDone, the ChainedFinalResponseValue.chainingResults.searchedSubtrees field is populated with values consisting of the RDNSequence relative to the target object of naming contexts that the DSA searched. See Section 3.3.1.1 for details on why this is done. Sermersheim Expires August 26, 2005 [Page 25] Internet-Draft Distributed Procedures for LDAP Operations February 2005 4.7.1 Chained Response resultCode The resultCode for the Chained Response is distinct from the result code of the ChainedIntermediateResponseValue.intermediateResponse or ChainedFinalResponseValue.finalResponse. If the act of chaining the operation completed, then this value will be success. Other result codes refer to the chained operation itself, and not the result of the embedded operation. 4.7.2 Returning referrals in the Chained Response {TODO: it would be less complicated if rather than using the simple LDAP URL, we used the ContinuationReference type to return referrals and intermediate referrals.} {TODO: We need an example of why we should allow referrals on a chained response. Why not just use the referral field in the operation?} 4.8 Receiving a Chained Response Processing a received Chained Response is generally straight forward -- typically the response is simply extracted and returned, but there are some extra steps to be taken when chaining sub-operations. 4.8.1 Handling Sub-operation controls and result codes When sub-operations are chained, there is the possibility that different result codes will be encountered. Similarly, if controls which elicit response controls were attached to the operation, it's possible that multiple response controls will be encountered. Both of these possibilities require that the chaining DSA take appropriate steps to ensure that the response being returned is correct. In general, when a result code indicating an error is received, the operation will terminate and the error will be returned. In cases where multiple sub-operations are being concurrently serviced, the operation will terminate and the most relevant, or first received result code is returned -- determining the result code to be returned in this case is a local matter. A DSA which chains an operation having a control (or controls) attached must ensure that a properly formed response is returned. This requires that the DSA understand and know how to aggrigate the results of all controls which it allows to remain attached to an operation being chained. If the DSA does not understand or support a control which is marked non-critical, it removes the control prior to chaining the operation. The DSA may return unavailableCriticalExtension for critical controls that it cannot or will not chain. {TODO: give SSS as an example?} Sermersheim Expires August 26, 2005 [Page 26] Internet-Draft Distributed Procedures for LDAP Operations February 2005 4.8.1.1 Handling referrals during sub-operations If a referral is returned in response to a sub-operation, the sending DSA may attempt to further chain the operation. In the event that the DSA does not further chain the sub-operation, it will use the referral to construct an intermediate referral, and return it appropriately. When using a referral to construct an intermediate referral, certain transformations may have to happen. For example, when using a referral to construct a searchResultReference, it must be assured that the <dn> field is present, and that the <scope> field is properly updated. 4.8.2 Duplicate Elimination When search result references cause the DSA to chain a search, it is possible that duplicate objects will be returned by different remote DSAs. These duplicate objects must be sensed and not returned. {TODO: Even though there are costs associated with returning duplicates, is it a worthy exercise to build in an allowance for them to be returned? In other words, do we want to add a way for a client (or administrator) to say "it's ok, return the duplicates, let the client deal with them"? Allowing is seen as a cost benefit to the DSA.} 4.9 Returning a Referral or Intermediate Referral There are two ways in which the fields of the ContinuationReference may be conveyed in a response containing or consisting of referral or intermediate referral. A paired control is introduced for the purpose of soliciting and returning a ContinuationReference. In absence of this control, a referral or intermediate referral may be returned which conveys the information present in the ContinuationReference. A method of converting a ContinuationReference to an LDAP URL is provided for referrals and intermediate referrals which identify LDAP-enabled DSAs. Methods for converting a ContinuationReference to URIs which identify non-LDAP servers is not provided here, but may be specified in future documents, as long as they can represent the data needed to provide the same level of service. 4.9.1 ReturnContinuationReference controls This control is sent when a client wishes to receive a ContinuationReference in the event that a referral or intermediate referral is being returned. If returned, the ContinuationReference will hold all data but the referralURI field. the referralURI values will be held in the referral or intermediate referral (Referral, Sermersheim Expires August 26, 2005 [Page 27] Internet-Draft Distributed Procedures for LDAP Operations February 2005 SearchResultReference, etc.). 4.9.1.1 ReturnContinuationReference request control Solicits the return of a ReturnContinuationReference response control on messages consisting of (or carrying) a referral or intermediate referral. The controlType is IANA-ASSIGNED-OID.3, the criticality is set at the sender's discretion, the controlValue is omitted. 4.9.1.2 ReturnContinuationReference response control In response to the ReturnContinuationReference request control, this holds a ContinuationReference for messages consisting of (or carrying) a referral or intermediate referral. The controlType is IANA-ASSIGNED-OID.3, the controlValue is the BER-encoding of a ContinuationReference. Note that the referralURI field is optionally omitted when the ContinuationReference is sent in this control value. In this event, the URI(s) found in the referral or intermediate referral (Referral, SearchContinuationReference, etc.) are to be used in its stead. {TODO: is returining the referralURI outside an unneeded complication?} 4.9.2 Converting a ContinuationReference to an LDAP URL This section details the way in which an LDAP URL (from the referral or intermediate referral) is used to convey the fields of a ContinuationReference. Where existing LDAP URL fields are insufficient, extensions are introduced. Note that further extensions to the ContinuationReference type require further specifications here. {TODO: explain that each ldap url in the continuation refrerence is examined and converted} These instructions must be applied to each LDAP URL value within the referral or intermediate referral. 4.9.2.1 Conveying the target name If the <dn> part of the LDAP URL is already present, it is determined to be the candidate target object. Otherwise, the candidate target object comes from the ContinuationReference.localReference. Once the candidate target object is determined, the value of ContinuationReference.remainingName is prepended to the candidate target object. This new value becomes the target object and its string value (as specified by <distinguishedName> in [RFC2253]) is placed in the <dn> part of the LDAP URL. Sermersheim Expires August 26, 2005 [Page 28] Internet-Draft Distributed Procedures for LDAP Operations February 2005 4.9.2.2 ContinuationReference.localReference This is conveyed as an extension. The extype is IANA-ASSIGNED-OID.4 or the descriptor 'localReference', and the exvalue is the string DN encoding (as specified by <distinguishedName> in [RFC2253]) of the ContinuationReference.localReference value. 4.9.2.3 ContinuationReference.referenceType This is conveyed as an extension. The extype is IANA-ASSIGNED-OID.5 or the descriptor 'referenceType'. If the ContinuationReference.referenceType is one of superior, subordinate, cross, nonSpecificSubordinate, suplier, master, immediateSuperior, or self, the exvalue 'superior', 'subordinate', 'cross', 'nonSpecificSubordinate', 'suplier', 'master', 'immediateSuperior', or 'self' respectively. 4.9.2.4 ContinuationReference.searchScope If the search scope is one of baseObject, singleLevel, or wholeSubtree, then it may be conveyed in the 'scope' part of the LDAP URL as 'base', 'one', or 'sub' respectively. If the search scope is subordinateSubtree, then it may be conveyed in the <extension> form as documented in [LDAP-SUBORD]. If this extension is present, it MUST be marked critical. This ensures that a receiver which is unaware of this extension uses the proper search scope, or fails to progress the operation. 4.9.2.5 ContinuationReference.searchedSubtrees This field is conveyed as an extension. The extype is IANA-ASSIGNED-OID.6 or the descriptor 'searchedSubtrees', and the exvalue is the ContinuationReference.searchedSubtree value encoded according to the following searchedSubtrees ABNF: searchedSubtrees = 1*(LANGLE searchedSubtree RANGLE) searchedSubtree = <distinguishedName> from [RFC2253] LANGLE = %x3C ; left angle bracket ("<") RANGLE = %x3E ; right angle bracket (">") Each searchedSubtree represents one RDNSequence value in the ContinuationReference.searchedSubtree field. An example of a searchedSubtrees value containing two searched subtrees is: <dc=example,dc=com><cn=ralph,dc=users,dc=example,dc=com>. 4.9.2.6 ContinuationReference.failedName This field is conveyed as an extension. The extype is Sermersheim Expires August 26, 2005 [Page 29] Internet-Draft Distributed Procedures for LDAP Operations February 2005 IANA-ASSIGNED-OID.7 or the descriptor 'failedName', and the exvalue is the string DN encoding (as specified in [RFC2253]) of the ContinuationReference.failedName value. 4.10 Acting on a Referral or Intermediate Referral When a protocol peer receives a referral or intermediate referral, it may distribute the operation either by sending a ChainedRequest, or by emulating the ChainedRequest. Prior to taking these steps, the protocol peer effectively converts the referral or intermediate referral into a ContinuationReference. Then, acting in the same manner as a DSA would, follows the directions in Section 4.4 if sending a ChainedRequest, or Section 4.5 otherwise. 4.10.1 Converting a Referral or Intermediate Referral to a ContinuationReference A referral or intermediate referral may be converted (or conceptually converted) to a ContinuationReference type in order to follow the distributed operation procedures in Section 4.4, or Section 4.5. The following steps may only be used to convert a referral or intermediate referral containing LDAP URL values. Converting other types of URIs may be specified in future documents as long as the conversion provides the same level of service found here. o The ContinuationReference.referralURI is populated with all LDAP URL values in the referral or intermediate referral. o The ContinuationReference.localReference populate with the value of the localReference extension value (Section 4.9.2.2) if one exists. Otherwise it is omitted. o The ContinuationReference.referenceType populate with the value of the referenceType extension value (Section 4.9.2.3) if one exists. Otherwise it is omitted. o The ContinuationReference.remainingName is omitted. o The ContinuationReference.searchScope is populated with subordinateSubtree if the subordScope LDAP URL extension [LDAP-SUBORD] is present. If the <scope> field contains te value 'base', 'one', 'sub', or 'subordinates', this filed is populated with baseObject, singleLevel, wholeSubtree, or subordinateSubtree respectively. Otherwise this field is omitted. o The ContinuationReference.searchedSubtrees is populated with any searchedSubtrees LDAP URI extension Section 4.9.2.5 value found on an LDAP URI in the referral or intermediate referral. If none exist, this field is omitted. o The ContinuationReference.failedName is populated with any failedName LDAP URI extension Section 4.9.2.6 value found on an LDAP URI in the referral or intermediate referral. If none exist, this field is omitted. Sermersheim Expires August 26, 2005 [Page 30] Internet-Draft Distributed Procedures for LDAP Operations February 2005 Note that many fields are simply omitted. This is either because they are conveyed within the LDAP URL values themselves, and subsequent instructions will check for their presence, or because they are not needed (they are redundant or not used in further instructions). 4.11 Ensuring non-existence of an entry under an nssr {TODO: add a huge disclaimer here that says without transactional semantics, you can never be sure that the entry didn't get added. Maybe we should just punt on this and say it's a local matter} In order to ensure there are no entries matching the name of the entry to be added or renamed immediately subordinate to an nssr, these steps may be followed. If the DSA is able and allowed to chain operations, it may contact each of the DSAs listed as access points in the nssr (in the ref attribute) and using a base-level search operation it will determine whether or not the object to be added exists. Note that access control or other policies may hide the entry from the sending DSA. If the entry does not exist on any of the DSAs listed in the nssr, the operation may progress on the local DSA. If the DSA cannot make this determination, the operation fails with affectsMultipleDSAs. 4.12 Mapping a referralURI to an LDAP URI As with any URI specification which is intended to be used as a URI which conveys referral information, the LDAP URI specification is given a mapping to the elements of a referralURI as specified in. Section 3.1.1.1. These mappings are given here using the ABNF identifiers given in [RFC2255]. referralURI to LDAP URI mapping: +---------------------------------+---------------------------------+ \| referralURI element \| LDAP URL element \| +---------------------------------+---------------------------------+ \| protocolIdentifier \| <scheme> \| \| \| \| \| accessPoint \| <hostport> \| \| \| \| \| targetObject \| <dn>. This must be encoded as a \| \| \| <distinguishedName> as \| \| \| specified in [RFC2253] \| \| \| \| \| localReference \| LDAP URL localReference \| Sermersheim Expires August 26, 2005 [Page 31] Internet-Draft Distributed Procedures for LDAP Operations February 2005 \| \| extension as specified in \| \| \| Section 4.9.2.2 \| \| \| \| \| referenceType \| LDAP URL referenceType \| \| \| extension as specified in \| \| \| Section 4.9.2.3 \| \| \| \| \| searchScope \| <scope> or LDAP URL subordScope \| \| \| extension as specified in \| \| \| Section 4.9.2.4 \| \| \| \| \| searchedSubtrees \| LDAP URL searchedSubtrees \| \| \| extension as specified in \| \| \| Section 4.9.2.5 \| \| \| \| \| failedName \| LDAP URL failedName extension \| \| \| as specified in Section 4.9.2.6 \| +---------------------------------+---------------------------------+ 4.13 Using the ManageDsaIT control This control, defined in [RFC3296], allows the management of the distributed knowledge information held by a DSA, and thus overrides the determinations made during name resolution and operation evaluation. When this control is attached to an operation, all resolved and acted upon DSEs are treated as being local to the DSA. This is true regardless of the phase the operation is in. Thus referrals are never returned and chaining never occurs. Sermersheim Expires August 26, 2005 [Page 32] Internet-Draft Distributed Procedures for LDAP Operations February 2005 5. Security Considerations This document introduces a mechanism (chaining) which can be used to propagate directory operation requests to servers which may be inaccessible otherwise. Implementers and deployers of this technology should be aware of this and take appropriate steps such that firewall mechanisms are not compromised. This document introduces the ability to return auxiliary data when returning referrals. Measures should be taken to ensure proper protection of his data. Implementers must ensure that any specified time, size, and administrative limits are not circumvented due to the mechanisms introduced here. 6. Normative References [LDAP-SUBORD] Sermersheim, J., "Subordinate Subtree Search Scope for LDAP", Internet-Draft draft-sermersheim-ldap-subordinate-scope, July 2004. [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories", RFC 3296, July 2002. Sermersheim Expires August 26, 2005 [Page 33] Internet-Draft Distributed Procedures for LDAP Operations February 2005 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002. [RFC3771] Harrison, R. and K. Zeilenga, "The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message", RFC 3771, April 2004. [X500] International Telephone and Telegraph Consultative Committee, "The Directory - overview of concepts, models and services", ITU-T Recommendation X.500, November 1993. [X518] International Telephone and Telegraph Consultative Committee, "The Directory - The Directory: Procedures for distributed operation", ITU-T Recommendation X.518, November 1993. [X680] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, July 2002. [X690] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002. Author's Address Jim Sermersheim Novell, Inc 1800 South Novell Place Provo, Utah 84606 USA Phone: +1 801 861-3088 Email: jimse@novell.com Sermersheim Expires August 26, 2005 [Page 34] Internet-Draft Distributed Procedures for LDAP Operations February 2005 Appendix A. IANA Considerations Registration of the following values is requested [RFC3383]. A.1 LDAP Object Identifier Registrations It is requested that IANA register upon Standards Action an LDAP Object Identifier in identifying the protocol elements defined in this technical specification. The following registration template is provided: Subject: Request for LDAP OID Registration Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Specification: RFCXXXX Author/Change Controller: IESG Comments: Seven delegations will be made under the assigned OID: IANA-ASSIGNED-OID.1 ChainedRequest LDAP Extended Operation IANA-ASSIGNED-OID.2 Supported Feature: Can Chain Operations IANA-ASSIGNED-OID.3 ReturnContinuationReference LDAP Controls IANA-ASSIGNED-OID.4 localReference: LDAP URL Extension IANA-ASSIGNED-OID.6 searchedSubtree: LDAP URL Extension IANA-ASSIGNED-OID.7 failedName: LDAP URL Extension A.2 LDAP Protocol Mechanism Registrations It is requested that IANA register upon Standards Action the LDAP protocol mechanism described in this document. The following registration templates are given: Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: IANA-ASSIGNED-OID.1 Description: ChainedRequest LDAP Extended Operation Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: IANA-ASSIGNED-OID.2 Description: Can Chain Operations Supported Feature Person & email address to contact for further information: Sermersheim Expires August 26, 2005 [Page 35] Internet-Draft Distributed Procedures for LDAP Operations February 2005 Jim Sermersheim jimse@novell.com Usage: Feature Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: IANA-ASSIGNED-OID.3 Description: ReturnContinuationReference LDAP Controls Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: Control Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: IANA-ASSIGNED-OID.4 Description: localReference LDAP URL Extension Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: IANA-ASSIGNED-OID.5 Description: referenceType LDAP URL Extension Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: IANA-ASSIGNED-OID.6 Description: searchedSubtree LDAP URL Extension Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: Extension Sermersheim Expires August 26, 2005 [Page 36] Internet-Draft Distributed Procedures for LDAP Operations February 2005 Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: IANA-ASSIGNED-OID.7 Description: failedName LDAP URL Extension Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none A.3 LDAP Descriptor Registrations It is requested that IANA register upon Standards Action the LDAP descriptors described in this document. The following registration templates are given: Subject: Request for LDAP Descriptor Registration Descriptor (short name): localReference Object Identifier: IANA-ASSIGNED-OID.4 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: URL Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Descriptor Registration Descriptor (short name): referenceType Object Identifier: IANA-ASSIGNED-OID.5 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: URL Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Descriptor Registration Descriptor (short name): searchedSubtree Object Identifier: IANA-ASSIGNED-OID.6 Person & email address to contact for further information: Sermersheim Expires August 26, 2005 [Page 37] Internet-Draft Distributed Procedures for LDAP Operations February 2005 Jim Sermersheim jimse@novell.com Usage: URL Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none Subject: Request for LDAP Descriptor Registration Descriptor (short name): failedName Object Identifier: IANA-ASSIGNED-OID.7 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: URL Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none A.4 LDAP Result Code Registrations It is requested that IANA register upon Standards Action the LDAP result codes described in this document. The following registration templates are given: Subject: Request for LDAP Result Code Registration Result Code Name: invalidReference Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: URL Extension Specification: RFCXXXX Author/Change Controller: IESG Comments: none Sermersheim Expires August 26, 2005 [Page 38] Internet-Draft Distributed Procedures for LDAP Operations February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sermersheim Expires August 26, 2005 [Page 39] Back

Edit File : draft-sermersheim-ldap-distproc-xx.txt | Size : 82.27 KB

Network Working Group                                     J. Sermersheim
Internet-Draft                                               Novell, Inc
Expires: August 26, 2005                               February 22, 2005

Distributed Procedures for LDAP Operations
                 draft-sermersheim-ldap-distproc-02.txt

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

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.

This Internet-Draft will expire on August 26, 2005.

Abstract

This document provides the data types and procedures used while
   servicing Lightweight Directory Access Protocol (LDAP) user
   operations in order to participate in a distributed directory.  In
   particular, it describes the way in which an LDAP user operation in a
   distributed directory environment finds its way to the proper DSA(s)
   for servicing.

Sermersheim              Expires August 26, 2005                [Page 1]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

Discussion Forum

Technical discussion of this document will take place on the IETF
   LDAP Extensions mailing list <ldapext@ietf.org>.  Please send
   editorial comments directly to the author.

Table of Contents

1.   Distributed Operations Overview  . . . . . . . . . . . . . .   3
   2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Distributed Operation Data Types . . . . . . . . . . . . . .   5
   3.1  ContinuationReference  . . . . . . . . . . . . . . . . . . .   5
   3.2  ChainedRequest . . . . . . . . . . . . . . . . . . . . . . .   9
   3.3  Chained Response . . . . . . . . . . . . . . . . . . . . . .  11
   4.   Distributed Procedures . . . . . . . . . . . . . . . . . . .  14
   4.1  Name resolution  . . . . . . . . . . . . . . . . . . . . . .  14
   4.2  Operation Evaluation . . . . . . . . . . . . . . . . . . . .  16
   4.3  Populating the ContinuationReference . . . . . . . . . . . .  19
   4.4  Sending a ChainedRequest . . . . . . . . . . . . . . . . . .  21
   4.5  Emulating the Sending of a ChainedRequest  . . . . . . . . .  23
   4.6  Receiving a ChainedRequest . . . . . . . . . . . . . . . . .  24
   4.7  Returning a Chained Response . . . . . . . . . . . . . . . .  25
   4.8  Receiving a Chained Response . . . . . . . . . . . . . . . .  26
   4.9  Returning a Referral or Intermediate Referral  . . . . . . .  27
   4.10 Acting on a Referral or Intermediate Referral  . . . . . . .  30
   4.11 Ensuring non-existence of an entry under an nssr . . . . . .  31
   4.12 Mapping a referralURI to an LDAP URI . . . . . . . . . . . .  31
   4.13 Using the ManageDsaIT control  . . . . . . . . . . . . . . .  32
   5.   Security Considerations  . . . . . . . . . . . . . . . . . .  33
   6.   Normative References . . . . . . . . . . . . . . . . . . . .  33
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  34
   A.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  35
   A.1  LDAP Object Identifier Registrations . . . . . . . . . . . .  35
   A.2  LDAP Protocol Mechanism Registrations  . . . . . . . . . . .  35
   A.3  LDAP Descriptor Registrations  . . . . . . . . . . . . . . .  37
   A.4  LDAP Result Code Registrations . . . . . . . . . . . . . . .  38
        Intellectual Property and Copyright Statements . . . . . . .  39

Sermersheim              Expires August 26, 2005                [Page 2]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

1.  Distributed Operations Overview

One characteristic of X.500-based directory systems [X500] is that,
   given a distributed Directory Information Tree (DIT), a user should
   potentially be able to have any service request satisfied (subject to
   security, access control, and administrative policies) irrespective
   of the Directory Service Agent (DSA) to which the request was sent.
   To accommodate this requirement, it is necessary that any DSA
   involved in satisfying a particular service request have some
   knowledge (as specified in {TODO: Link to future Distributed Data
   Model doc}) of where the requested information is located and either
   return this knowledge to the requester or attempt to satisfy the
   request satisfied on the behalf of the requester (the requester may
   either be a Directory User Agent (DUA) or another DSA).

Two modes of operation distribution are defined to meet these
   requirements, namely "chaining" and "returning referrals".
   "Chaining" refers to the attempt by a DSA to satisfy a request by
   sending one or more chained operations to other DSAs.  "Returning
   referrals", is the act of returning distributed knowledge information
   to the requester, which may then itself interact with the DSA(s)
   identified by the distributed knowledge information.  It is a goal of
   this document to provide the same level of service whether the
   chaining or referral mechanism is used to distribute an operation.

The processing of an operation is talked about in two major phases,
   namely "name resolution", and "operation evaluation".  Name
   resolution is the act of locating a local DSE held on a DSA given a
   distinguished name (DN).  Operation evaluation is the act of
   performing the operation after the name resolution phase is complete.

While distributing an operation, a request operation may be
   decomposed into several sub-operations.

The distributed directory operation procedures described in this
   document assume the absense of the ManageDsaIT control defined in
   [RFC3296] and described in Section 4.13.

Sermersheim              Expires August 26, 2005                [Page 3]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

2.  Conventions

Imperative keywords defined in [RFC2119] are used in this document,
   and carry the meanings described there.

All Basic Encoding Rules (BER) [X690] encodings follow the
   conventions found in Section 5.1 of [RFC2251].

Sermersheim              Expires August 26, 2005                [Page 4]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

3.  Distributed Operation Data Types

The data types in this section are used by the chaining and referral
   distributed operation mechanisms described in Section 4

3.1  ContinuationReference

As an operation is being processed by a DSA, it is useful to group
   the information passed between various procedures as a collection of
   data.  The ContinuationReference data type is introduced for this
   purpose.  This data type is populated and consumed by various
   procedures discussed in various sections of this document.  In
   general, a ContinuationReference is used when indicating that
   directory information being acted on is not present locally, but may
   be present elsewhere.

A ContinuationReference consists of one or more addresses which
   identify remote DSAs along with other information pertaining both to
   the distributed knowledge information held on the local DSA as well
   as information relevant to the operation.  This data type is
   expressed here in Abstract Syntax Notation One (ASN.1) [X680].

ContinuationReference ::= SET {
         referralURI      [0] SET SIZE (1..MAX) OF URI,
         localReference   [2] LDAPDN,
         referenceType    [3] ReferenceType,
         remainingName    [4] RelativeLDAPDN OPTIONAL,
         searchScope      [5] SearchScope OPTIONAL,
         searchedSubtrees [6] SearchedSubtrees OPTIONAL,
         failedName       [7] LDAPDN OPTIONAL,
         ...  }

<Editor's Note: Planned for addition is a searchCriteria field which
   is used both for assuring that the remote object is in fact the
   object originally pointed to (this mechanism provides a security
   measure), and also to allow moved or renamed remote entries to be
   found.  Typically the search criteria would have a filter value of
   (entryUUID=<something>)>

URI ::= LDAPString     -- limited to characters permitted in URIs
   [RFC2396].

ReferenceType ::= ENUMERATED {
         superior               (0),
         subordinate            (1),
         cross                  (2),
         nonSpecificSubordinate (3),

Sermersheim              Expires August 26, 2005                [Page 5]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

suplier                (4),
         master                 (5),
         immediateSuperior      (6),
         self                   (7),
         ...  }
      SearchScope ::= ENUMERATED {
         baseObject         (0),
         singleLevel        (1),
         wholeSubtree       (2),
         subordinateSubtree (3),
         ...  }

SearchedSubtrees ::= SET OF RelativeLDAPDN

LDAPDN, RelativeLDAPDN, and LDAPString, are defined in [RFC2251].

The following subsections introduce the fields of the
   ContinuationReference data type, but do not provide in-depth
   semantics or instructions on the population and consumption of the
   fields.  These topics are discussed as part of the procedural
   instructions.

3.1.1  ContinuationReference.referralURI

The list of referralURI values is used by the receiver to progress
   the operation.  Each value specifies (at minimum) the protocol and
   address of one or more remote DSA(s) holding the data sought after.
   URI values which are placed in ContinuationReference.referralURI must
   allow for certain elements of data to be conveyed.  Section 3.1.1.1
   describes these data elements.  Furthermore, a mapping must exist
   which relates the parts of a specified URI to these data elements.
   This document provides such a mapping for the LDAP URL [RFC2255] in
   Section 4.12.

In some cases, a referralURI will contain data which has a
   counterpart in the fields of the ContinuationReference (an example is
   where the referralURI is an LDAP URL, holds a <scope> value, and the
   ContinuationReference.searchScope field is also present).  In these
   cases, the data held on the referralURI overrides the field in the
   ContinuationReference.  Specific examples of this are highlighted in
   other sections.  Providing a means for these values to exist as
   fields of the ContinuationReference allows one value to be applied to
   all values of referralURI (as opposed to populating duplicate data on
   all referralURI values).

If a referralURI value identifies an LDAP-enabled DSA [RFC3377], the
   LDAP URL form is used.

Sermersheim              Expires August 26, 2005                [Page 6]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

3.1.1.1  Elements of referralURI Values

The following data elements must be allowed and identified for a
   specified URI type to be used to convey referral information.  Each
   element is given a name which begins with 'referralURI.' for clarity
   when referencing the elements conceptually in other parts of this
   document.

o  referralURI.protocolIdentifier.  There must be an indication of
      the protocol to be used to contact the DSA identified by the URI.
   o  referralURI.accessPoint.  The URI must identify a DSA in a manner
      that can be used to contact it using the protocol specified in
      protocolIdentifier.
   o  referralURI.targetObject.  Holds the name to be used as the base
      DN of the operation being progressed.  This field must be allowed
      by the URI specification, but may be omitted in URI instances for
      various reasons.
   o  referralURI.localReference.  See Section 3.1.2.  This field must
      be allowed by the URI specification, but may be omitted in URI
      instances for various reasons.
   o  referralURI.searchScope.  See Section 3.1.5.  This field must be
      allowed by the URI specification, but may be omitted in URI
      instances for various reasons.
   o  referralURI.searchedSubtrees.  See Section 3.1.6.  This field must
      be allowed by the URI specification, but may be omitted in URI
      instances for various reasons.
   o  referralURI.failedName.  See Section 3.1.7.  This field must be
      allowed by the URI specification, but may be omitted in URI
      instances for various reasons.

3.1.2  ContinuationReference.localReference

This names the DSE which was found to hold distributed knowledge
   information, and thus which caused the ContinuationReference to be
   formed.  This field is primarily used to help convey the new target
   object name, but may also be used for purposes referential integrity
   (not discussed here).  In the event that the root object holds the
   distributed knowledge information, this field is present and is
   populated with an empty DN.

3.1.3  ContinuationReference.referenceType

Indicates the DSE Type of the ContinuationReference.localReference.
   This field may be used to determine how to progress an operations
   (i.e.  if the value is nonSpecificSubordinate, a search continuation
   will exclude the ContinuationReference.referenceType).

Sermersheim              Expires August 26, 2005                [Page 7]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

3.1.4  ContinuationReference.remainingName

In certain scenarios, the localReference does not completely name the
   DSE to be used as the new target object name.  In these cases,
   remainingName is populated with the RDNSequence relative to the
   localReference of the target object name being resolved.  Some
   examples of these scenarios include (but are not restricted to):

o  During name resolution, the name is not fully resolved, but a DSE
      holding distributed knowledge information is found, causing a
      ContinuationReference to be generated.
   o  While searching, an alias is dereferenced.  The aliasedObjectName
      points to a DSE of type glue which is subordinate to a DSE holding
      distributed knowledge information.

3.1.5  ContinuationReference.searchScope

Under certain circumstances, when progressing a search operation, a
   search scope different than that of the original search request must
   be used.  This field facilitates the conveyance of the proper search
   scope to be used when progressing the distributed operation.

The scope of subordinateSubtree has been added to the values allowed
   by the LDAP SearchRequest.scope field.  This scope includes the
   subtree of entries below the base DN, but does not include the base
   DN itself.  This is used here when progressing distributed search
   operations caused by the existence of a DSE of type nssr.

If a referralURI.searchScope is present, it overrides this field
   while that referralURI is being operated upon.

3.1.6  ContinuationReference.searchedSubtrees

For ContinuationReferences generated while processing a search
   operation with a scope of wholeSubtree, each value of this field
   indicates that a particular subtree below the target object has
   already been searched.  Consumers of this data use it to cause the
   progression of the search operation to exclude these subtrees as a
   mechanism to avoid receiving duplicate entries.

If a referralURI.searchedSubtrees is present, it overrides this field
   while that referralURI is being operated upon.

3.1.7  ContinuationReference.failedName

When an operation requires that multiple names be resolved (as is the
   case with the ModifyDN operation), this field is used to specify
   which name was found to be non-local.

Sermersheim              Expires August 26, 2005                [Page 8]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

If a referralURI.failedName is present, it overrides this field while
   that referralURI is being operated upon.

3.2  ChainedRequest

The Chained Request is sent as an LDAP extended operation.  The
   requestName is IANA-ASSIGNED-OID.1.  The requestValue is the BER
   encoding of the following ChainedRequestValue ASN.1 definition:

ChainedRequestValue ::= SEQUENCE {

chainingArguments ChainingArguments,
         operationRequest  OperationRequest }

ChainingArguments ::= SEQUENCE {

targetObject     [0] LDAPDN OPTIONAL,
         referenceType    [1] ReferenceType,
         traceInformation [2] ChainingTraceInformation,
         searchScope      [3] SearchScope OPTIONAL,
         searchedSubtrees [4] SearchedSubtrees OPTIONAL}

ChainingTraceInformation ::= SET OF LDAPURL

OperationRequest ::= SEQUENCE {

Request ::= CHOICE {

bindRequest    BindRequest,
            searchRequest  SearchRequest,
            modifyRequest  ModifyRequest,
            addRequest     AddRequest,
            delRequest     DelRequest,
            modDNRequest   ModifyDNRequest,
            compareRequest CompareRequest,
            extendedReq    ExtendedRequest,
            ...  },
         controls       [0] Controls COPTIONAL }

BindRequest, SearchRequest, ModifyRequest, AddRequest, DelRequest,
   ModifyDNRequest, CompareRequest, ExtendedRequest and Controls are
   defined in [RFC2251].

3.2.1  ChainedRequestValue.chainingArguments

In general, these fields assist in refining the original operation as
   it is to be executed on the receiving DSA.

Sermersheim              Expires August 26, 2005                [Page 9]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

3.2.1.1  ChainedRequestValue.chainingArguments.targetObject

This field contains the new target (or base) DN for the operation.

The sending DSA populates this under different scenarios including
   the case where an alias has been dereferenced while resolving the DN,
   and also the case where a referral carries a target name different
   from the reference object that caused the referral.

This field can be omitted only if it would be the the same value as
   the object or base object parameter in the
   ChainedRequestValue.operationRequest, in which case its implied value
   is that value.

The receiving DSA examines this field and (if present) uses it rather
   than the base DN held in the ChainedRequestValue.operationRequest.

3.2.1.2  ChainedRequestValue.chainingArguments.referenceType

See Section 3.1.3.

If the receiver encounters a value of nonSpecificSubordinate in this
   field, it indicates that the operation is being chained due to DSE of
   type nssr.  In this case, the receiver allows (and expects) the base
   DN to name the immediate superior of a context prefix.

3.2.1.3  ChainedRequestValue.chainingArguments.traceInformation

This contains a set of URIs.  Each value represents the address of a
   DSA and DN that has already been contacted while attempting to
   service the operation.  This field is used to detect looping while
   servicing a distributed operation.

The sending DSA populates this with its own URI, and also the URIs of
   any DSAs that have already been chained to.  The receiving DSA
   examines this list of URIs and returns a loopDetect error if it finds
   that any of the addresses and DNs in the listed URI's represent it's
   own.

3.2.1.4  ChainedRequestValue.chainingArguments.searchScope

See Section 3.1.5.

3.2.1.5  ChainedRequestValue.chainingArguments.searchedSubtrees

See Section 3.1.6.

Sermersheim              Expires August 26, 2005               [Page 10]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

3.2.2  ChainedRequestValue.operationRequest

This holds the original LDAP operation request.  This is restricted
   to a subset of all LDAP operations.  Namely, the following LDAP
   operation types are not allowed:

o  Abandon/Cancel operations.  When an abandon or cancel operation
      needs to be chained, it is sent to the remote DSA as-is.  This is
      because there is no need to track it for loop detection or pass on
      any other information normally found in ChainingArguments.
   o  Unbind.  Again, there is no need to send chaining-related
      information to a DSA to perform an unbind.  DSAs which chain
      operations maintain connections as they see fit.
   o  Chained Operation.  When a DSA receives a chained operation, and
      must again chain that operation to a remote DSA, it sends a
      ChainedRequest where the ChainedRequestValue.operationRequest is
      that of the incoming ChainedRequestValue.operationRequest.

3.3  Chained Response

The Chained Response is sent as an LDAP IntermediateResponse
   [RFC3771], or LDAP ExtendedResponse [RFC2251], depending on whether
   the operation is complete or not.  In either case, the responseName
   is omitted.  For intermediate responses, the
   IntermediateResponse.responseValue is the BER encoding of the
   ChainedIntermediateResponseValue ASN.1 definition.  For completed
   operations, the ExtendedResponse.value is the BER encoding of the
   ChainedFinalResponseValue ASN.1 definition.

ChainedIntermediateResponseValue ::= SEQUENCE {

chainedResults    ChainingResults,
         operationResponse IntermediateResponse }

ChainedFinalResponseValue ::= SEQUENCE {

chainedResults    ChainingResults,
         operationResponse FinalResponse }

ChainingResults ::= SEQUENCE {

searchedSubtrees [0] SearchedSubtrees OPTIONAL,
         ...  }

IntermediateResponse ::= SEQUENCE {

Response ::= CHOICE {

Sermersheim              Expires August 26, 2005               [Page 11]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

searchResEntry       SearchResultEntry,
            searchResRef         SearchResultReference,
            intermediateResponse IntermediateResponse
            ...  },
         controls [0] Controls COPTIONAL }

FinalResponse ::= SEQUENCE {

Response ::= CHOICE {

bindResponse    BindResponse,
            searchResDone   SearchResultDone,
            modifyResponse  ModifyResponse,
            addResponse     AddResponse,
            delResponse     DelResponse,
            modDNResponse   ModifyDNResponse,
            compareResponse CompareResponse,
            extendedResp    ExtendedResponse,
            ...  },
         controls [0] Controls COPTIONAL }

BindResponse, SearchResultEntry, SearchResultDone,
   SearchResultReference, ModifyResponse, AddResponse, DelResponse,
   ModifyDNResponse, CompareResponse, ExtendedResponse, and Controls are
   defined in [RFC2251].  IntermediateResponse is defined in [RFC3771].

3.3.1  ChainingResults

In general, this is used to convey additional information that may
   needed in the event that the operation needs to be progressed
   further.

3.3.1.1  ChainingResults.searchedSubtrees

Each value of this field indicates that a particular subtree below
   the target object has already been searched.  This is particularly
   useful while chaining search operations during operation evaluation
   caused by the presence of a DSA of type nssr.  Each DSA referenced by
   the nssr holds one or more naming contexts subordinate to the nssr
   DSE.  The ChainingResults.searchedSubtrees field allows the DSA being
   chained to, to inform the sending DSA which subordinate naming
   contexts have been searched.  This information may be passed to
   further DSAs listed on the nssr in order to reduce the possibility of
   duplicate entries being returned.

Sermersheim              Expires August 26, 2005               [Page 12]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

3.3.2  ChainedIntermediateResponseValue.intermediateResponse and
      ChainedFinalResponseValue.finalResponse

This holds the directory operation response message tied to the
   ChainedRequestValue.operationRequest.

Sermersheim              Expires August 26, 2005               [Page 13]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

4.  Distributed Procedures

For the purposes of describing a distributed operation, operations
   are said to consist of two major phases -- name resolution and
   operation evaluation.  These terms are adopted from [X518].  Name
   resolution is the act of locating a DSE said to be held locally by a
   DSA given a distinguished name (DN).  Operation evaluation is the act
   of performing the operation after the name resolution phase is
   complete.

Furthermore, there are two modes of distributing an operation --
   chaining, and returning referrals.  Chaining is the act of forwarding
   an unfinished operation to another DSA for completion (this may
   happen during name resolution or operation evaluation).  In this
   case, the forwarding DSA sends a chained operation to a receiving
   DSA, which attempts to complete the operation.  Alternately, the DSA
   may return a referral (or intermediate referral), and the client may
   use that referral in order to forward the unfinished operation to
   another DSA.  Whether the operation is distributed via chaining or
   referrals is a decision left to the DSA and or DUA.

The term 'intermediate referral' describes a referral returned during
   the operation evaluation phase of an operation.  These include
   searchResultReferences, referrals returned with an
   intermediateResponse [RFC3771], or future referrals which indicate
   that they are intermediate referrals.

An operation which is distributed while in the operation evaluation
   phase is termed a 'sub-operation'.

This document inserts a step between the two distributed operation
   phases in order to commonize the data and processes followed prior to
   chaining an operation or returning a referral.  This step consists of
   populating a ContinuationReference data type.

4.1  Name resolution

Before evaluating (enacting) most directory operations, the DSE named
   by the target (often called the base DN) of the operation must be
   located .  This is done by evaluating the RDNs of the target DN one
   at a time, starting at the rootmost RDN.  Each RDN is compared to the
   DSEs held by the DSA until the set of RDNs is exhausted, or an RDN
   cannot be found.

If the DSE named by the target is found to be local, the name
   resolution phase of the operation completes and the operation
   evaluation phase begins.

Sermersheim              Expires August 26, 2005               [Page 14]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

If it is found that the target does not name a local DSE nor a DSE
   that may held by another DSA, it is said that the target does not
   exist, and the operation fails with noSuchObject (subject to local
   policy).

If it is found that the DSE named by the target is non-local to the
   DSA, but may reside elsewhere, name resolution is said to be
   incomplete.  In this case, the operation may be distributed by
   creating a ContinuationReference (Section 4.3) and either chaining
   the operation (Section 4.4 and Section 4.5)or returning a referral
   (Section 4.9).

4.1.1  Determining that a named DSE is local to a DSA

If a DSE held by a DSA falls within a naming context held by the DSA,
   or is the root DSE on a first-level DSA, it is said to be local to
   that DSA

4.1.2  Determining that a named DSE does not exist

A named DSE is said to not exist if, during name resolution the DSE
   is not found, but if found it would fall within a naming context held
   by the DSA.

4.1.3  Determining that a named DSE is non-local

If a named DSE is niether found to be local to the DSA, nor found to
   not exist, it is said to be non-local to a DSA.  In this case, it is
   indeterminate whether the named DSE exists.

When a named DSE is found to be non-local, there should be
   distributed knowledge information available to be used to either
   return a referral or chain the operation.

4.1.3.1  Locating distributed knowledge information for a non-local
        target

If it has been determined that a target names a non-local DSE,
   distributed knowledge information may be found by first examining the
   DSE named by the target, and subsequently all superior DSEs beginning
   with the immediate superior and ending with the root, until an
   examined DSE is one of types:

{TODO: should DSE types be all caps? It would be easier to read.}
   o  subr
   o  supr
   o  immsupr

Sermersheim              Expires August 26, 2005               [Page 15]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

o  xr
   o  nssr

The examined DSE which is of one of these types holds the distributed
   knowledge information for the non-local named target.  This DSE is
   said to be the found distributed knowledge information of the
   non-local target.  This found distributed knowledge information may
   then be used to distribute the operation.

If no examined DSEs are of any of these types, the distributed
   knowledge information is mis-configured, and the error
   invalidReference is returned.

4.1.4  Special case for the Add operation

During the name resolution phase of the Add operation, the immediate
   parent of the base DN is resolved.

If the immediate parent of the entry to be added is a DSE of type
   nssr, then further interrogation is needed to ensure that the entry
   to be added does not exist.  Methods for doing this are found in
   Section 4.11.  {TODO: don't make this mandatory.  Also, it doesn't
   work without transaction semantics.  Same prob in the mod dn below.}.

4.1.5  Special case for the ModifyDN operation

When the modifyDN operation includes a newSuperior name, it must be
   resolved as well as the base DN being modified.  If either of these
   result in a non-local name, the name causing the operation to be
   distributed should be conveyed (Section 4.3.5).  {TODO: also mention
   access control problems, and mention (impl detail) that
   affectsmultidsa can be used.}

If during operation evaluation of a ModifyDN operation, the
   newSuperior names a DSE type of nssr, then further interrogation is
   needed to ensure that the entry to be added does not exist.  Methods
   for doing this are found in Section 4.11.

4.2  Operation Evaluation

Once name resolution has completed.  The DSE named in the target has
   been found to be local to a DSA.  At this point the operation can be
   carried out.  During operation evaluation distributed knowledge
   information may be found that may cause the DSA to distribute the
   operation.  When this happens, the operation may be distributed by
   creating a ContinuationReference (Section 4.3) and either chaining
   the operation (Section 4.4 and Section 4.5)or returning a referral
   (Section 4.9).

Sermersheim              Expires August 26, 2005               [Page 16]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

If, during the location of the distributed knowledge information, the
   distributed knowledge information is found to be mis-configured,
   operation semantics are followed (some operations may call for an
   error to be returned, while others call for the error to be ignored).
   {TODO: either make this more specific, or less specific, or just toss
   it out.}

4.2.1  Search operation

During operation evaluation of a search operation, the DSA must
   determine whether there is distributed knowledge information in the
   scope of the search.  Any DSE in the search scope which is of the
   following types is considered to be 'found distributed knowledge
   information' {TODO: use a better term than found distributed
   knowledge information} in the search scope:

o  subr
   o  nssr (see nssr note)
   o  xr {TODO: I think xr only qualifies when an alias is dereferenced
      to an xr.  Otherwisw, there should always be a subr above the xr
      if it falls in the search scope.}

Note that due to alias dereferencing, the search scope may expand to
   include entries outside of the scope originally specified in the
   search operation.  {TODO: note that an aliased object may be glue
   which needs to result in any subr or xr above it to be found}

Nssr Note: A DSE of type nssr is only considered to be found
   distributed knowledge information when the scope of the search
   includes entries below it.  For example, when the search scope is
   wholeSubtree or subordinateSubtree and a DSE of type nssr is found in
   the scope, or if the search scope is singleLevel and the target
   object names a DSE of type nsssr.

{TODO: The following sections are talking about how the continuation
   reference is to be populated.  Move to next secion.  Can probably
   just say that whole subtree or subordinare subtree encountering nssr,
   and single level rooted at nssr result in a continuation reference.
   base at, and single level above do not result in a continuation
   reference.}

4.2.1.1  Search operation with singleLevel scope

If distributed knowledge information is found during operation
   evaluation of a search with a singleLevel scope, it will cause the
   resulting ContinuationReference.searchScope to be set to baseObject.

Sermersheim              Expires August 26, 2005               [Page 17]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

4.2.1.2  Search operation encountering nssr knowledge reference

When a search operation encounters distributed knowledge information
   which is a DSE type of nssr during operation evaluation, the
   following instructions are followed:

Note that when a search operation is being progressed due to nssr
   knowledge information, the subsequent distributed progression of the
   search is caused to be applied to each DSA listed as non-specific
   knowledge information (This is talked about in Section 4.3.2).  In
   the event that multiple DSAs listed in the knowledge information hold
   copies of the same directory entries, the 'already searched' and
   'duplicate elimination' mechanisms SHOULD be used to prevent
   duplicate search result entries from ultimately being returned.

4.2.1.2.1  wholeSubtree search scope

When the search scope is wholeSubtree, the
   ContinuationReference.searchScope is set to subordinateSubtree.
   Because the ContinuationReference.referrenceType is set to
   nonSpecificSubordinate, the receiving protocol peer allows (and
   expects) name resolution to stop at an immsupr DSE type which is
   treated as a local DSE.  The subordinateSubtree scope instructs the
   receiving protocol peer to exclude the target object from the
   sub-search.

4.2.1.2.2  singleLevel search scope

When the search scope is singleLevel, and the base DN is resolved to
   a DSE of type nssr, subsequent distributed progressions of the search
   are caused to use the same base DN, and a scope of singleLevel.
   Receiving protocol peers will only apply the search to entries below
   the target object.

When the search scope is singleLevel and an evaluated DSE is of type
   nssr, no special handling is required.  The search is applied to that
   DSE if it is of type entry.

4.2.1.2.3  baseObject search scope

No special handling is needed when the search scope is baseObject and
   the base DN is an nssr DSEType.  The search is applied to that DSE if
   it is of type entry.

4.2.1.3  Search operation rooted at an nssr DSE type

(TODO: a subordinateSubtree scope needs to change to wholeSubtree if
   references are found.)

Sermersheim              Expires August 26, 2005               [Page 18]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

4.3  Populating the ContinuationReference

When an entry is found to be non-local to a DSA (whether during name
   resolution or operation evaluation), the DSA prepares for operation
   distribution by generating a ContinuationReference.  This is a
   conceptual step, given to help explain the interactions that occur
   between discovering that an operation must be distributing, and
   actually invoking the operation distribution mechanism.
   Implementations are not required to perform this step, but will
   effectively work with the same information.

After the ContinuationReference has been created, the DSA may choose
   to chain the operation or return a referral (or intermediate
   referral(s)).

the ContinuationReference is made up of data held on the found
   distributed knowledge information, as well as state information
   gained during name resolution or operation evaluation.

4.3.1  Conveying the Target Object

The consumer of the ContinuationReference will examine various fields
   in order to determine the target object name of the operation being
   progressed.  The fields examined are the localReference and
   remainingName.

If name resolution did not complete, and the found distributed
   knowledge information names the same DSE as the base DN of the
   operation, the ContinuationReference MAY omit the localReference
   and/or remainingName fields.

localReference is populated with the name of the found distributed
   knowledge information DSE.  In the event that the root object holds
   the distributed knowledge information, this field will be populated
   with an empty DN.  Contrast this with the omission of this field.

referenceType is populated with a value reflecting the reference type
   of the localReference DSE.

remainingName is populated with the RDNSequence which has not yet
   been resolved.  This is the difference between the localReference
   value and the name of the DSE to be resolved.

In cases where the DSE named by the {TODO, use a dash or different
   term to make 'found distributed knowledge' more like a single term}
   found distributed knowledge is not the same as the base DN of the
   operation, the ContinuationReference must contain the localReference
   and/or remainingName fields.  Such cases include but are not limited

Sermersheim              Expires August 26, 2005               [Page 19]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

to:

o  Distributed knowledge information is found during operation
      evaluation.
   o  Aliases were dereferenced during name resolution.
   o  Name resolution did not complete and there were remaining RDNs to
      be resolved.

4.3.2  Conveying the Remote DSA

The referralURI field must contain at least one value.  Each
   referralURI value must hold a referralURI.accessPoint.  Other
   requirements on this field as noted may also apply.

Note for nssr DSE types: During operation evaluation, if a DSE of
   type nssr causes the operation to be distributed (the scenarios in
   Section 4.2.1.2 are an example), then an intermediate referral {TODO:
   this is talking about referral/intermediate referral, but this
   section is only dealing with populating continuation reference} is
   returned for each value of the ref attribute, where each intermediate
   referral only holds a single referralURI value.

4.3.3  Conveying new search scope

During the evaluation of the search operation, the instructions in
   Section 4.2.1.2.1 and Section 4.2.1.2.2 are followed and the
   searchScope field is updated with the new search scope.

4.3.4  Preventing duplicates

In order to prevent duplicate entries from being evaluated while
   progressing a search operation, the searchedSubtrees field is
   populated with any naming context below the
   ContinuationReference.targetObject which have been fully searched.

During the evaluation of the search operation, if the scope is
   wholeSubtree, it is possible that the DSA may search the contents of
   a naming context which is subordinate to another naming context which
   is subordinate to the search base (See figure).

Sermersheim              Expires August 26, 2005               [Page 20]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

O X
                       / \
                      /   \
                     /     \
                    /       \
                    \_______O Y
                           /|\
                          / | \
                         /  |  \
                        /   |   \
                       A    B    O C
                                / \
                               /   \
                              /     \
                             /       \
                             \_______/

In this figure, the DSA holds the naming context X and C,Y,X, but not
   Y,X.  If the search base was X, an intermediate referral would be
   returned for Y,X.  The DSA holding Y,X may also hold a copy of C,Y,X.
   In this case, the receiver of the ContinuationReference benefits by
   knowing that the DSA already searched C,Y,X so that it can prevent
   other DSAs from returning those entries again.

Data already searched is in the form of an RDNSequence, consisting of
   the RDNs relative to the target object.

4.3.5  Conveying the Failed Name

At least one DS operation (modifyDN) requires that multiple DNs be
   resolved (the entry being modified and the newSuperior entry).  In
   this case, the failedName field will be populated with the DN being
   resolved which failed name resolution.  This may aid in the
   determination of how the operation is to be progressed.  If both
   names are found to be non-local, this field is omitted.

4.4  Sending a ChainedRequest

When an entry is found to be non-local to a DSA (whether during name
   resolution or operation evaluation), the DSA may progress the
   operation by sending a chained operation to another DSA (or DSAs).
   The instructions in this section assume that a ContinuationReference
   has been generated which will be used to form the ChainedRequest.  It
   is also assumed that it can be determined whether the operation is
   being progressed due to name resolution or due to operation
   evaluation.

A DSA which is able to chain operations may advertise this by

Sermersheim              Expires August 26, 2005               [Page 21]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

returning a value of IANA-ASSIGNED-OID.2; in the supportedFeatures
   attribute on the root DSE.  {TODO: does this and discovery of the
   extended op belong in a new 'discovery mechanisms' sections.}

4.4.1  Forming a ChainedRequest

The following fields are populated as instructed:

4.4.1.1  ChainedRequestValue.chainingArguments.targetObject

The ContinuationReference may convey a new target object.  If
   present, the ContinuationReference.localReference field becomes the
   candidate target object.  Otherwise the candidate target object is
   assumed to be that of the original directory operation.  Note that an
   empty value in the ContinuationReference.localReference field denotes
   the root object.

After performing the above determination as to the candidate target
   object, any RDNSequence in ContinuationReference.remainingName is
   prepended to the determined candidate target object.  This value
   becomes the ChainedRequestValue.chainingArguments.targetObject.  If
   this value matches the value of the original operation, this field
   may be omitted.

4.4.1.2  ChainedRequestValue.chainingArguments.referenceType

This is populated with the
   ContinuationReference.referralURI.referenceType.

4.4.1.3  ChainedRequestValue.chainingArguments.traceInformation

This is populated as specified in Section 3.2.1.3.

4.4.1.4  ChainedRequestValue.chainingArguments.searchScope

This is populated with the
   ContinuationReference.referralURI.searchScope if present, otherwise
   by the ContinuationReference.searchScope if present, and not
   populated otherwise.

4.4.1.5  ChainedRequestValue.chainingArguments.searchedSubtrees

This is populated with ContinuationReference.searchedSubtrees, as
   well as any previously received values of
   ChainedFinalResponseValue.chainingResults.searchedSubtrees or
   ChainedIntermediateResponseValue.chainingResults.searchedSubtrees
   which are subordinate, relative to the target object.  (If thsi is
   relative to the target object, it can't contain non-relative

Sermersheim              Expires August 26, 2005               [Page 22]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

subtrees)

4.4.1.6  ChainedRequestValue.operationRequest

This is populated with the original directory operation request.

4.4.2  Attempting Each Referral URI

A ContinuationReference consists of one or more referralURIs which
   represent(s a) remote DSA(s).  The chaining DSA attempts to chain to
   each of these DSAs until one succeeds in completing the operation.
   An operation is considered to be completed if it reaches the remote
   DSA and a response is sent back that indicates that the operation was
   executed.  Operations which are sent to the remote DSA, but don't
   complete are indicated by a result code of unavailable or busy.  A
   result code of protocolError may indicate that the DSA does not
   support the chained operation, and in this case, it is also treated
   as an uncompleted operation.  Other errors may in the future specify
   that they also indicate non-completion.  Note that the response may
   itself contain referral(s), these are still considered completed
   operations and thus would subsequently be handled and chained.
   {TODO: could use soft/hard, or transient/permanent
   referral/non-referral error terms here.}

4.4.3  Loop Prevention

Prior to sending a ChainedRequest, the DSA may attempt to prevent
   looping scenarios by comparing {TODO: what matching rule is used?
   Suggest we don't convert dns names to ip addresses due to NATs} the
   address of the remote DSA and target object to the values of
   ChainedRequestValue.chainingArguments.traceInformation.  If a match
   is found, the DSA returns a loopDetect error.  Note that while this
   type of loop prevention aids in detecting loops prior to sending data
   to a remote DSA, it is not a substitute for loop detection (Section
   Section 4.6.2).  This is because the sending DSA is only aware of a
   single address on which the receiving DSA accepts connections.

4.5  Emulating the Sending of a ChainedRequest

When it is determined that the operation cannot be distributed by
   means of the ChainedRequest, the chaining DSA may instead emulate the
   steps involved in chaining the operation.  These steps consist of
   performing loop prevention, forming a new directory operation request
   from the original request and possibly updating the base DN, search
   scope, and search filter(in order to emulate searchedSubtrees), and,
   similar to the steps in Section 4.4.2, attempting to send the
   operation request to each DSA listed in the
   ContinuationReference.referralURI until one succeeds in completing

Sermersheim              Expires August 26, 2005               [Page 23]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

the operation.

{TODO: We need a way (control) to tell the receiver to allow name
   resolution to end on the parent of a cp (typically an immsupr).  This
   would be sent when the ContinuationReference.referenceType is
   nonSpecificSubordinate}

4.5.1  Emulated Loop Detection

For this step, the loop prevention instructions in Section 4.4.3 are
   followed.  Note that this method of loop detection may actually allow
   some looping to occur before the loop is detected.

4.5.2  Forming the New Request

The new directory operation request is formed from the fields of the
   original request, and the following fields may be updated:

o  The base DN is formed from the new target object as determined by
      following the instructions in Section 4.4.1.1 and using the value
      which would have been placed in
      ChainedRequestValue.chainingArguments.targetObject.
   o  For the search operation, the scope is populated with
      ContinuationReference.searchScope if present, otherwise the scope
      of the original operation request is used.
   o  For the search operation, if the
      ContinuationReference.searchedSubtrees field is present, causes
      the search filter to be augmented by adding a filter item of the
      'and' CHOICE.  The filter consists of {TODO: weasel Kurt into
      finishing his entryDN draft and reference the appropriate section
      there.  See
      <http://www.openldap.org/lists/ietf-ldapext/200407/msg00000.html>
      for context}
   o  Other fields (such as the messageID, and non-critical controls)
      may also need to be updated or excluded.

If the service being chained to does not support directory
   operations, other operations may be used as long as they provide the
   same level as service as those provided by the analogous directory
   operation.

4.6  Receiving a ChainedRequest

A DSA which is able to receive and service a ChainedRequest may
   advertise this feature by returning a value of IANA-ASSIGNED-OID.1 in
   the supportedExtension attribute of the root DSE.  {TODO: move?}

The ChainedRequestValue data type is the requestValue of an

Sermersheim              Expires August 26, 2005               [Page 24]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

extendedRequest.

In general, receiving and servicing a ChainedRequest consists of
   performing loop detection and, using components of the
   ChainedRequestType.chainingArguments along with the
   ChainedRequestType.operationRequest, service the request.

4.6.1  Target Object determination

Prior to checking for a loop condition, the target object must be
   determined.  If the ChainedRequestType.chainingArguments.targetObject
   field is present, its value becomes the target object.  Otherwise,
   the base DN found in the ChainedRequestType.operationRequest becomes
   the target object.

4.6.2  Loop Detection

The loop detection check happens when a DSA receives a chained
   operation, prior to acting on the operation.  The DSA compares {TODO:
   matching rule? DNS expansion?} each value of
   ChainedRequestValue.traceInformation to the list of addresses at
   which it accepts directory communications.  A value of
   ChainedRequestValue.traceInformation matches when the DSA accepts
   directory communications on the address found in the
   ChainedRequestValue.traceInformation value, and the target object (as
   determined in Section 4.6.1 matches the DN {TODO: using DN matching?}
   value found in the ChainedRequestValue.traceInformation value.  If a
   match is found the DSA returns a loopDetect result.

4.6.3  Processing the ChainedRequestValue.operationRequest

In processing the operationRequest, the DSA uses the target object
   determined in Section 4.6.1.  For search operations, it uses the
   scope found in ChainedRequestValue.chainingArguments.searchScope, and
   excludes any subtrees relative to the target object indicated in
   ChainedRequestValue.chainingArguments.searchedSubtrees.

Responses are returned in the form of a Chained Response.

4.7  Returning a Chained Response

When returning responses to a ChainedRequest, the Chained Response as
   documented in Section 3.3 is used.  If the
   ChainedFinalResponseValue.operationResponse is a searchResultDone,
   the ChainedFinalResponseValue.chainingResults.searchedSubtrees field
   is populated with values consisting of the RDNSequence relative to
   the target object of naming contexts that the DSA searched.  See
   Section 3.3.1.1 for details on why this is done.

Sermersheim              Expires August 26, 2005               [Page 25]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

4.7.1  Chained Response resultCode

The resultCode for the Chained Response is distinct from the result
   code of the ChainedIntermediateResponseValue.intermediateResponse or
   ChainedFinalResponseValue.finalResponse.  If the act of chaining the
   operation completed, then this value will be success.  Other result
   codes refer to the chained operation itself, and not the result of
   the embedded operation.

4.7.2  Returning referrals in the Chained Response

{TODO: it would be less complicated if rather than using the simple
   LDAP URL, we used the ContinuationReference type to return referrals
   and intermediate referrals.} {TODO: We need an example of why we
   should allow referrals on a chained response.  Why not just use the
   referral field in the operation?}

4.8  Receiving a Chained Response

Processing a received Chained Response is generally straight forward
   -- typically the response is simply extracted and returned, but there
   are some extra steps to be taken when chaining sub-operations.

4.8.1  Handling Sub-operation controls and result codes

When sub-operations are chained, there is the possibility that
   different result codes will be encountered.  Similarly, if controls
   which elicit response controls were attached to the operation, it's
   possible that multiple response controls will be encountered.  Both
   of these possibilities require that the chaining DSA take appropriate
   steps to ensure that the response being returned is correct.

In general, when a result code indicating an error is received, the
   operation will terminate and the error will be returned.  In cases
   where multiple sub-operations are being concurrently serviced, the
   operation will terminate and the most relevant, or first received
   result code is returned -- determining the result code to be returned
   in this case is a local matter.

A DSA which chains an operation having a control (or controls)
   attached must ensure that a properly formed response is returned.
   This requires that the DSA understand and know how to aggrigate the
   results of all controls which it allows to remain attached to an
   operation being chained.  If the DSA does not understand or support a
   control which is marked non-critical, it removes the control prior to
   chaining the operation.  The DSA may return
   unavailableCriticalExtension for critical controls that it cannot or
   will not chain.  {TODO: give SSS as an example?}

Sermersheim              Expires August 26, 2005               [Page 26]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

4.8.1.1  Handling referrals during sub-operations

If a referral is returned in response to a sub-operation, the sending
   DSA may attempt to further chain the operation.  In the event that
   the DSA does not further chain the sub-operation, it will use the
   referral to construct an intermediate referral, and return it
   appropriately.  When using a referral to construct an intermediate
   referral, certain transformations may have to happen.  For example,
   when using a referral to construct a searchResultReference, it must
   be assured that the <dn> field is present, and that the <scope> field
   is properly updated.

4.8.2  Duplicate Elimination

When search result references cause the DSA to chain a search, it is
   possible that duplicate objects will be returned by different remote
   DSAs.  These duplicate objects must be sensed and not returned.

{TODO: Even though there are costs associated with returning
   duplicates, is it a worthy exercise to build in an allowance for them
   to be returned? In other words, do we want to add a way for a client
   (or administrator) to say "it's ok, return the duplicates, let the
   client deal with them"? Allowing is seen as a cost benefit to the
   DSA.}

4.9  Returning a Referral or Intermediate Referral

There are two ways in which the fields of the ContinuationReference
   may be conveyed in a response containing or consisting of referral or
   intermediate referral.  A paired control is introduced for the
   purpose of soliciting and returning a ContinuationReference.  In
   absence of this control, a referral or intermediate referral may be
   returned which conveys the information present in the
   ContinuationReference.  A method of converting a
   ContinuationReference to an LDAP URL is provided for referrals and
   intermediate referrals which identify LDAP-enabled DSAs.  Methods for
   converting a ContinuationReference to URIs which identify non-LDAP
   servers is not provided here, but may be specified in future
   documents, as long as they can represent the data needed to provide
   the same level of service.

4.9.1  ReturnContinuationReference controls

This control is sent when a client wishes to receive a
   ContinuationReference in the event that a referral or intermediate
   referral is being returned.  If returned, the ContinuationReference
   will hold all data but the referralURI field.  the referralURI values
   will be held in the referral or intermediate referral (Referral,

Sermersheim              Expires August 26, 2005               [Page 27]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

SearchResultReference, etc.).

4.9.1.1  ReturnContinuationReference request control

Solicits the return of a ReturnContinuationReference response control
   on messages consisting of (or carrying) a referral or intermediate
   referral.  The controlType is IANA-ASSIGNED-OID.3, the criticality is
   set at the sender's discretion, the controlValue is omitted.

4.9.1.2  ReturnContinuationReference response control

In response to the ReturnContinuationReference request control, this
   holds a ContinuationReference for messages consisting of (or
   carrying) a referral or intermediate referral.  The controlType is
   IANA-ASSIGNED-OID.3, the controlValue is the BER-encoding of a
   ContinuationReference.  Note that the referralURI field is optionally
   omitted when the ContinuationReference is sent in this control value.
   In this event, the URI(s) found in the referral or intermediate
   referral (Referral, SearchContinuationReference, etc.) are to be used
   in its stead.  {TODO: is returining the referralURI outside an
   unneeded complication?}

4.9.2  Converting a ContinuationReference to an LDAP URL

This section details the way in which an LDAP URL (from the referral
   or intermediate referral) is used to convey the fields of a
   ContinuationReference.  Where existing LDAP URL fields are
   insufficient, extensions are introduced.  Note that further
   extensions to the ContinuationReference type require further
   specifications here.  {TODO: explain that each ldap url in the
   continuation refrerence is examined and converted}

These instructions must be applied to each LDAP URL value within the
   referral or intermediate referral.

4.9.2.1  Conveying the target name

If the <dn> part of the LDAP URL is already present, it is determined
   to be the candidate target object.  Otherwise, the candidate target
   object comes from the ContinuationReference.localReference.  Once the
   candidate target object is determined, the value of
   ContinuationReference.remainingName is prepended to the candidate
   target object.  This new value becomes the target object and its
   string value (as specified by <distinguishedName> in [RFC2253]) is
   placed in the <dn> part of the LDAP URL.

Sermersheim              Expires August 26, 2005               [Page 28]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

4.9.2.2  ContinuationReference.localReference

This is conveyed as an extension.  The extype is IANA-ASSIGNED-OID.4
   or the descriptor 'localReference', and the exvalue is the string DN
   encoding (as specified by <distinguishedName> in [RFC2253]) of the
   ContinuationReference.localReference value.

4.9.2.3  ContinuationReference.referenceType

This is conveyed as an extension.  The extype is IANA-ASSIGNED-OID.5
   or the descriptor 'referenceType'.  If the
   ContinuationReference.referenceType is one of superior, subordinate,
   cross, nonSpecificSubordinate, suplier, master, immediateSuperior, or
   self, the exvalue 'superior', 'subordinate', 'cross',
   'nonSpecificSubordinate', 'suplier', 'master', 'immediateSuperior',
   or 'self' respectively.

4.9.2.4  ContinuationReference.searchScope

If the search scope is one of baseObject, singleLevel, or
   wholeSubtree, then it may be conveyed in the 'scope' part of the LDAP
   URL as 'base', 'one', or 'sub' respectively.  If the search scope is
   subordinateSubtree, then it may be conveyed in the <extension> form
   as documented in [LDAP-SUBORD].  If this extension is present, it
   MUST be marked critical.  This ensures that a receiver which is
   unaware of this extension uses the proper search scope, or fails to
   progress the operation.

4.9.2.5  ContinuationReference.searchedSubtrees

This field is conveyed as an extension.  The extype is
   IANA-ASSIGNED-OID.6 or the descriptor 'searchedSubtrees', and the
   exvalue is the ContinuationReference.searchedSubtree value encoded
   according to the following searchedSubtrees ABNF:

searchedSubtrees = 1*(LANGLE searchedSubtree RANGLE)
      searchedSubtree = <distinguishedName> from [RFC2253]
      LANGLE  = %x3C ; left angle bracket ("<")
      RANGLE  = %x3E ; right angle bracket (">")

Each searchedSubtree represents one RDNSequence value in the
   ContinuationReference.searchedSubtree field.  An example of a
   searchedSubtrees value containing two searched subtrees is:
   <dc=example,dc=com><cn=ralph,dc=users,dc=example,dc=com>.

4.9.2.6  ContinuationReference.failedName

This field is conveyed as an extension.  The extype is

Sermersheim              Expires August 26, 2005               [Page 29]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

IANA-ASSIGNED-OID.7 or the descriptor 'failedName', and the exvalue
   is the string DN encoding (as specified in [RFC2253]) of the
   ContinuationReference.failedName value.

4.10  Acting on a Referral or Intermediate Referral

When a protocol peer receives a referral or intermediate referral, it
   may distribute the operation either by sending a ChainedRequest, or
   by emulating the ChainedRequest.  Prior to taking these steps, the
   protocol peer effectively converts the referral or intermediate
   referral into a ContinuationReference.  Then, acting in the same
   manner as a DSA would, follows the directions in Section 4.4 if
   sending a ChainedRequest, or Section 4.5 otherwise.

4.10.1  Converting a Referral or Intermediate Referral to a
       ContinuationReference

A referral or intermediate referral may be converted (or conceptually
   converted) to a ContinuationReference type in order to follow the
   distributed operation procedures in Section 4.4, or Section 4.5.  The
   following steps may only be used to convert a referral or
   intermediate referral containing LDAP URL values.  Converting other
   types of URIs may be specified in future documents as long as the
   conversion provides the same level of service found here.

o  The ContinuationReference.referralURI is populated with all LDAP
      URL values in the referral or intermediate referral.
   o  The ContinuationReference.localReference populate with the value
      of the localReference extension value (Section 4.9.2.2) if one
      exists.  Otherwise it is omitted.
   o  The ContinuationReference.referenceType populate with the value of
      the referenceType extension value (Section 4.9.2.3) if one exists.
      Otherwise it is omitted.
   o  The ContinuationReference.remainingName is omitted.
   o  The ContinuationReference.searchScope is populated with
      subordinateSubtree if the subordScope LDAP URL extension
      [LDAP-SUBORD] is present.  If the <scope> field contains te value
      'base', 'one', 'sub', or 'subordinates', this filed is populated
      with baseObject, singleLevel, wholeSubtree, or subordinateSubtree
      respectively.  Otherwise this field is omitted.
   o  The ContinuationReference.searchedSubtrees is populated with any
      searchedSubtrees LDAP URI extension Section 4.9.2.5 value found on
      an LDAP URI in the referral or intermediate referral.  If none
      exist, this field is omitted.
   o  The ContinuationReference.failedName is populated with any
      failedName LDAP URI extension Section 4.9.2.6 value found on an
      LDAP URI in the referral or intermediate referral.  If none exist,
      this field is omitted.

Sermersheim              Expires August 26, 2005               [Page 30]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

Note that many fields are simply omitted.  This is either because
   they are conveyed within the LDAP URL values themselves, and
   subsequent instructions will check for their presence, or because
   they are not needed (they are redundant or not used in further
   instructions).

4.11  Ensuring non-existence of an entry under an nssr

{TODO: add a huge disclaimer here that says without transactional
   semantics, you can never be sure that the entry didn't get added.
   Maybe we should just punt on this and say it's a local matter} In
   order to ensure there are no entries matching the name of the entry
   to be added or renamed immediately subordinate to an nssr, these
   steps may be followed.

If the DSA is able and allowed to chain operations, it may contact
   each of the DSAs listed as access points in the nssr (in the ref
   attribute) and using a base-level search operation it will determine
   whether or not the object to be added exists.  Note that access
   control or other policies may hide the entry from the sending DSA.
   If the entry does not exist on any of the DSAs listed in the nssr,
   the operation may progress on the local DSA.

If the DSA cannot make this determination, the operation fails with
   affectsMultipleDSAs.

4.12  Mapping a referralURI to an LDAP URI

As with any URI specification which is intended to be used as a URI
   which conveys referral information, the LDAP URI specification is
   given a mapping to the elements of a referralURI as specified in.
   Section 3.1.1.1.  These mappings are given here using the ABNF
   identifiers given in [RFC2255].

referralURI to LDAP URI mapping:

Sermersheim              Expires August 26, 2005               [Page 31]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

4.13   Using the ManageDsaIT control

This control, defined in [RFC3296], allows the management of the
   distributed knowledge information held by a DSA, and thus overrides
   the determinations made during name resolution and operation
   evaluation.  When this control is attached to an operation, all
   resolved and acted upon DSEs are treated as being local to the DSA.
   This is true regardless of the phase the operation is in.  Thus
   referrals are never returned and chaining never occurs.

Sermersheim              Expires August 26, 2005               [Page 32]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

5.  Security Considerations

This document introduces a mechanism (chaining) which can be used to
   propagate directory operation requests to servers which may be
   inaccessible otherwise.  Implementers and deployers of this
   technology should be aware of this and take appropriate steps such
   that firewall mechanisms are not compromised.

This document introduces the ability to return auxiliary data when
   returning referrals.  Measures should be taken to ensure proper
   protection of his data.

Implementers must ensure that any specified time, size, and
   administrative limits are not circumvented due to the mechanisms
   introduced here.

6.  Normative References

[LDAP-SUBORD]
              Sermersheim, J., "Subordinate Subtree Search Scope for
              LDAP",
              Internet-Draft draft-sermersheim-ldap-subordinate-scope,
              July 2004.

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

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

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

[RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

[RFC3296]  Zeilenga, K., "Named Subordinate References in Lightweight
              Directory Access Protocol (LDAP) Directories", RFC 3296,
              July 2002.

Sermersheim              Expires August 26, 2005               [Page 33]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

[RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
              Protocol (v3): Technical Specification", RFC 3377,
              September 2002.

[RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
              Considerations for the Lightweight Directory Access
              Protocol (LDAP)", BCP 64, RFC 3383, September 2002.

[RFC3771]  Harrison, R. and K. Zeilenga, "The Lightweight Directory
              Access Protocol (LDAP) Intermediate Response Message",
              RFC 3771, April 2004.

[X500]     International Telephone and Telegraph Consultative
              Committee, "The Directory - overview of concepts, models
              and services", ITU-T Recommendation X.500, November 1993.

[X518]     International Telephone and Telegraph Consultative
              Committee, "The Directory - The Directory: Procedures for
              distributed operation", ITU-T Recommendation X.518,
              November 1993.

[X680]     International Telecommunications Union, "Abstract Syntax
              Notation One (ASN.1): Specification of basic notation",
              ITU-T Recommendation X.680, July 2002.

[X690]     International Telecommunications Union, "Information
              Technology - ASN.1 encoding rules: Specification of Basic
              Encoding Rules (BER), Canonical Encoding Rules (CER) and
              Distinguished Encoding Rules (DER)", ITU-T Recommendation
              X.690, July 2002.

Author's Address

Jim Sermersheim
   Novell, Inc
   1800 South Novell Place
   Provo, Utah  84606
   USA

Phone: +1 801 861-3088
   Email: jimse@novell.com

Sermersheim              Expires August 26, 2005               [Page 34]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

Appendix A.  IANA Considerations

Registration of the following values is requested [RFC3383].

A.1  LDAP Object Identifier Registrations

It is requested that IANA register upon Standards Action an LDAP
   Object Identifier in identifying the protocol elements defined in
   this technical specification.  The following registration template is
   provided:

Subject: Request for LDAP OID Registration
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments:
      Seven delegations will be made under the assigned OID:
      IANA-ASSIGNED-OID.1 ChainedRequest LDAP Extended Operation
      IANA-ASSIGNED-OID.2 Supported Feature: Can Chain Operations
      IANA-ASSIGNED-OID.3 ReturnContinuationReference LDAP Controls
      IANA-ASSIGNED-OID.4 localReference: LDAP URL Extension
      IANA-ASSIGNED-OID.6 searchedSubtree: LDAP URL Extension
      IANA-ASSIGNED-OID.7 failedName: LDAP URL Extension

A.2  LDAP Protocol Mechanism Registrations

It is requested that IANA register upon Standards Action the LDAP
   protocol mechanism described in this document.  The following
   registration templates are given:

Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: IANA-ASSIGNED-OID.1
      Description: ChainedRequest LDAP Extended Operation
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: IANA-ASSIGNED-OID.2
      Description: Can Chain Operations Supported Feature
      Person & email address to contact for further information:

Sermersheim              Expires August 26, 2005               [Page 35]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

Jim Sermersheim
         jimse@novell.com
      Usage: Feature
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: IANA-ASSIGNED-OID.3
      Description: ReturnContinuationReference LDAP Controls
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: Control
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: IANA-ASSIGNED-OID.4
      Description: localReference LDAP URL Extension
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: IANA-ASSIGNED-OID.5
      Description: referenceType LDAP URL Extension
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: IANA-ASSIGNED-OID.6
      Description: searchedSubtree LDAP URL Extension
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: Extension

Sermersheim              Expires August 26, 2005               [Page 36]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: IANA-ASSIGNED-OID.7
      Description: failedName LDAP URL Extension
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

A.3  LDAP Descriptor Registrations

It is requested that IANA register upon Standards Action the LDAP
   descriptors described in this document.  The following registration
   templates are given:

Subject: Request for LDAP Descriptor Registration
      Descriptor (short name): localReference
      Object Identifier: IANA-ASSIGNED-OID.4
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: URL Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Descriptor Registration
      Descriptor (short name): referenceType
      Object Identifier: IANA-ASSIGNED-OID.5
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: URL Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Descriptor Registration
      Descriptor (short name): searchedSubtree
      Object Identifier: IANA-ASSIGNED-OID.6
      Person & email address to contact for further information:

Sermersheim              Expires August 26, 2005               [Page 37]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

Jim Sermersheim
         jimse@novell.com
      Usage: URL Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Subject: Request for LDAP Descriptor Registration
      Descriptor (short name): failedName
      Object Identifier: IANA-ASSIGNED-OID.7
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: URL Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

A.4  LDAP Result Code Registrations

It is requested that IANA register upon Standards Action the LDAP
   result codes described in this document.  The following registration
   templates are given:

Subject: Request for LDAP Result Code Registration
      Result Code Name: invalidReference
      Person & email address to contact for further information:
         Jim Sermersheim
         jimse@novell.com
      Usage: URL Extension
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments: none

Sermersheim              Expires August 26, 2005               [Page 38]
Internet-Draft    Distributed Procedures for LDAP Operations  February 2005

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
   Internet Society.

Sermersheim              Expires August 26, 2005               [Page 39]

Back