D7net
Home
Console
Upload
information
Create File
Create Folder
About
Tools
:
/
usr
/
share
/
doc
/
openldap-devel
/
drafts
/
Filename :
draft-sermersheim-ldap-distproc-xx.txt
back
Copy
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]