From ldapext-bounces@ietf.org Sun Aug 1 18:00:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26334 for ; Sun, 1 Aug 2004 18:00:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrO4S-0003gk-1Y; Sun, 01 Aug 2004 17:40:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrNy2-0006ML-I0 for ldapext@megatron.ietf.org; Sun, 01 Aug 2004 17:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25223 for ; Sun, 1 Aug 2004 17:34:04 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrO0j-0001A6-VL for ldapext@ietf.org; Sun, 01 Aug 2004 17:36:56 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Sun, 01 Aug 2004 15:33:31 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Sun, 01 Aug 2004 14:33:10 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartE1C1A096.0__=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 843eb6ac205acfd69e4e238d90d959fd Subject: [ldapext] Distributed Operations Rough Draft X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartE1C1A096.0__= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit All, I just wanted to drop an update regarding the work I'm trying to do with LDAP chained operations. At Mark Ennis' suggestion, I have changed the approach I was taking in the previous chained operation I-D I posted. Instead, this draft I-D attempts a fuller explanation of distributed directory procedures. In it, I begin by discussing name resolution and operation evaluation, and end by discussing operation distribution via chaining or referral following. In the middle, I use a ContinuationReference data type to tie things together. The goal that prompted this is that I'd like to have a model where whether an operation is to be distributed via chaining versus referral following, both methods have the same class of service. You may also note that I'm proposing to do certain things slightly differently than X.518 does (namely, the targetObject is the name of the reference object causing the operation to be distributed, rather than the parent of the next naming context being resolved or operated on. I did this for two primary reasons 1) I view it as a much simpler model. Some of the baggage that came with the X.518 method causes numerous subtleties that escape the casual (and even focused) reader. 2) LDAP has already set a precedent in the way that referrals and searchContinuationReferences are returned and handled. You'll note that the later sections are sparse or just not filled in yet. I have the information in different places, I just haven't consolidated (editied) it all into this document yet. If anyone would like to meet for impromptu meetings at IETF60, drop me a note. Or if you're not in San Diego, feel free to review the document, but be aware that I'm scurrying to finish it. I do welcome any feedback regarding whether you think I'm on or off track in any areas though. Thanks, Jim --=__PartE1C1A096.0__= Content-Type: text/plain; name="draft-sermersheim-ldap-distproc.txt" Content-Disposition: attachment; filename="draft-sermersheim-ldap-distproc.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA25223 Content-Transfer-Encoding: quoted-printable Network Working Group J. Sermersheim Internet-Draft Novell, Inc Expires: December 30, 2004 July 2004 Distributed Procedures for LDAP Operations draft-sermersheim-ldap-distproc.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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides the data types and procedures used while servicing Lightweight Directory Application 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 December 30, 2004 [Page 1] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 Table of Contents 1. Distributed Operations Overview . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Distributed Operation Data Types . . . . . . . . . . . . . . 5 3.1 ContinuationReference . . . . . . . . . . . . . . . . . . 5 3.2 ChainedRequest . . . . . . . . . . . . . . . . . . . . . . 8 3.3 ChainedResponse . . . . . . . . . . . . . . . . . . . . . 10 4. Distributed Procedures . . . . . . . . . . . . . . . . . . . 12 4.1 Name resolution . . . . . . . . . . . . . . . . . . . . . 12 4.2 Operation Evaluation . . . . . . . . . . . . . . . . . . . 14 4.3 Populating the ContinuationReference . . . . . . . . . . . 16 4.4 Sending a ChainedRequest . . . . . . . . . . . . . . . . . 18 4.5 Receiving a ChainedRequest . . . . . . . . . . . . . . . . 20 4.6 Returning a ChainedResponse . . . . . . . . . . . . . . . 20 4.7 Receiving a ChainedResponse . . . . . . . . . . . . . . . 20 4.8 Returning a Referral or SearchResultReference . . . . . . 20 4.9 Acting on a Referral or SearchResultReference . . . . . . 20 4.10 Ensuring non-existence of an entry under an nssr . . . . 20 4.11 Using the ManageDsaIT control . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . 22 6. Normative References . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . 24 Sermersheim Expires December 30, 2004 [Page 2] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 ) 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 DSA interaction are defined to meet these requirements, namely "chaining", "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, the request may be decomposed into several subrequests prior to the interaction. Sermersheim Expires December 30, 2004 [Page 3] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 December 30, 2004 [Page 4] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 3. Distributed Operation Data Types The data types in this section are used by the chaining and referral distributed operation mechanisms 3.1 ContinuationReference As an operation is being processed by a DSA, it is useful to keep track of information passed to and from 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 below. In general, a ContinuationReference is used when indicating that directory information being acted on is not present locally, but that it may be present elsewhere. A ContinuationReference field consists of one or more addresses to 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 ::=3D SET { referralURI [0] SET SIZE (1..MAX) OF URI, remoteName [1] LDAPDN OPTIONAL, localReference [2] LDAPDN, remainingName [3] RelativeLDAPDN OPTIONAL, searchScope [4] SearchScope OPTIONAL, searchedSubtrees [5] SearchedSubtrees OPTIONAL, failedName [6] LDAPDN OPTIONAL, ... } )> URI ::=3D LDAPString -- limited to characters permitted in URIs SearchScope::=3D ENUMERATED { baseObject [0], singleLevel [1], wholeSubtree [2], subordinateSubtree [3], ... } Sermersheim Expires December 30, 2004 [Page 5] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 SearchedSubtrees ::=3D 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 This specifies (at minimum) the protocol and address of one or more remote DSA(s) holding the data sought after. The format is that of any valid URI which identifies the access point of a DSA. Each referralURI value must convey the information (typically protocol and address) needed to contact the identified DSE. In some cases, referralURI values will contain other data which can be used while distributing the operation. Sometimes similar data exists as fields of the ContinuationReference (an example is where the referralURI is an LDAP URL, holds a DN value, and the remoteName field is also present). In these cases, the data held on the referralURI value 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], it MUST be in the form of an LDAP URL [RFC2255] The list of referralURI values is used by the receiver to progress the operation. 3.1.2 ContinuationReference.remoteName This field may be used to hold a new base DN for the operation to use. This field may be used if the DSA allows name mappings. That is, if Sermersheim Expires December 30, 2004 [Page 6] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 an object residing on a remote DSA has a name that differs from the local name of the reference which represents that remote object, this field can be used to convey the name of the remote object. If the DSA does not allow name mapping to occur, this field will not be used for that purpose. If a target DN is present in a referralURI value, it overrides this field while that referralURI value is being operated upon. 3.1.3 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. For purposes of determining a new target object name, if the remoteName field is present, it overrides this field. 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 remainingName value of the new target object name. 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 Sermersheim Expires December 30, 2004 [Page 7] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 operations caused by the existence of a DSE of type nssr. 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 have 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. 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. 3.2 ChainedRequest The Chained Request is sent as an LDAP extended operation. The requestName is . The requestValue is the BER encoding of the following ChainedRequestValue ASN.1 definition: ChainedRequest ::=3D SEQUENCE { chainingArguments ChainingArguments, operationRequest OperationRequest } ChainingArguments ::=3D SEQUENCE { targetObject [0] LDAPDN OPTIONAL, traceInformation [1] ChainingTraceInformation, searchScope [2] SearchScope OPTIONAL, searchedSubtrees [3] SearchedSubtrees OPTIONAL} ChainingTraceInformation ::=3D SET OF LDAPURL OperationRequest ::=3D SEQUENCE { Request ::=3D CHOICE { bindRequest BindRequest, searchRequest SearchRequest, modifyRequest ModifyRequest, addRequest AddRequest, delRequest DelRequest, modDNRequest ModifyDNRequest, Sermersheim Expires December 30, 2004 [Page 8] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 ChainedRequest.chainingArguments In general, these fields assist in refining the original operation as it is to be executed on the receiving DSA. 3.2.1.1 ChainedRequest.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 ChainedRequest.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 ChainedRequest.operationRequest. 3.2.1.2 ChainedRequest.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 (54) error if it finds that any of the addresses and DNs in the listed URI's represent it's own. 3.2.1.3 ChainedRequest.chainingArguments.searchScope See Section 3.1.5 Sermersheim Expires December 30, 2004 [Page 9] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 If the receiver encounters a value of subordinateSubtree, 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.4 ChainedRequest.chainingArguments.searchedSubtrees See Section 3.1.6 3.2.2 ChainedRequest.operationRequest This holds the original LDAP operation request. This is restricted to a subset of all LDAP operation. 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. If an unbind request is unbinding a previously chained bind, the server servicing the unbind request ensures that the unbind is properly chained. 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 operationRequest is that of the incoming operationRequest. 3.3 ChainedResponse The Chained Response is sent as an LDAP extended operation. The requestName is omitted. The requestValue is the BER encoding of the following ChainedResponse ASN.1 definition. ChainedResponse ::=3D SEQUENCE { chainedResults ChainingResults, operationResponse OperationResponse } ChainingResults ::=3D SEQUENCE { searchedSubtrees [0] SearchedSubtrees OPTIONAL } OperationResponse ::=3D SEQUENCE { Response ::=3D CHOICE { Sermersheim Expires December 30, 2004 [Page 10] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 bindResponse BindResponse, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, 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] 3.3.1 ChainedResponse.chainedResults 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 ChainedResponse.chainedResults.searchedSubtrees Each value of this field indicates that a particular subtree below the target object have 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 ChainedResponse.chainedResults.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. 3.3.2 ChainedResponse.operationResponse This holds the response message tied to the ChainedRequest.operationRequest. Sermersheim Expires December 30, 2004 [Page 11] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. Name resolution is the act of locating 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 =E2=80=93 chaining, and returning referrals. Chaining is the act of forwarding an unfinished operation to another DSA for completion. In this case, the forwarding DSA sends a chained operation and a receiving DSA receives the chained operation. Alternately, the DSA may return a referral, and the client may follow 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. This document inserts a step into these distributed operation modes 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 If it is found that the target does not name a local DSE nor a DSE 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 target is non-local to the DSE, but may reside elsewhere, name resolution is said to be incomplete. In this case, the operation may be distributed by following the instructions in 4.1.1 Determining that a DSE is local to a DSA If a DSE held by a DSA meets the following criteria, it is said to Sermersheim Expires December 30, 2004 [Page 12] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 be local to that DSA: o It is or falls (hierarchically) under and administrative point. o it is a DSE of any of the types: * root * cp * entry * alias * admPoint * subentry 4.1.2 Determining that a named target does not exist A named target DN is said to to not exist if the following are met: o At least one RDN has matched a DSE during name resolution. o An RDN is encountered that names no DSE. o The last DSE resolved is local to the DSA. 4.1.3 Determining that the target is non-local If the following are met, then the DSE named by the target is said to be non-local to a DSA: o It is not found to be local to the DSA. o It is not found to not exist In this case, 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 the 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: o subr o supr o xr 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 Sermersheim Expires December 30, 2004 [Page 13] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 then be used to distribute the operation. If no examined DSEs are of any of these types, the found distributed knowledge information is mis-configured, and the error 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.10 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 target DN being modified. If either of these result in a non-local name, the name causing the operation to be distributed should be conveyed. Mechanisms for doing this are discussed in and . If during operation evaluation of a ModifyDN operation, the newSuperior names a DSE 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 . 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. This is done as specified in 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). 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 in the search scope: Sermersheim Expires December 30, 2004 [Page 14] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 o subr o nssr (see nssr note) o xr Note that due to alias dereferencing, locating any DSE of the above types in the search scope may be possible. 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. 4.2.1.1 Search operation with singleLevel scope If during operation evaluation of a search with a singleLevel scope distributed knowledge information is found, it will cause the subsequent distributed progression of the search to use a scope of baseObject. 4.2.1.2 Search operation encountering a DSE of type nssr When a search operation encounters a DSE type nssr during operation evaluation, the following instructions are followed, but only if the search requires that subordinates of the nssr DSE are to be examined. 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 subsequent distributed progression of the search is caused to use a base of the found DSE, and a scope of subordinateSubtree. This causes the receiving DSAs to only apply the search to entries below the new target object. 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. This causes the receiving DSAs to only apply the search to entries below the target object. Sermersheim Expires December 30, 2004 [Page 15] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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, or if the ManageDsaIT control is attached. 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, or if the ManageDsaIT control is attached. 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). 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 any target DN in the referralURI value(s), remoteName, 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 be populated without any target DN in the referralURI value(s), remoteName, localReference, or remainingName. remoteName is populated with the DN value of the refRemoteName attribute (if present) localReference is populated with the name of the found distributed knowledge information DSE. In the event that the root object holds Sermersheim Expires December 30, 2004 [Page 16] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 the distributed knowledge information, this field will be populated with an empty DN. 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 found distributed knowledge is not the same as the base DN of the operation, the ContinuationReference must contain either the remoteName, localReference, or DN part(s) in each referralURI value. It may also contain a value in the remainingName field. Such cases include but are not limited 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 which holds the location of a DSA to be used in progressing the operation. 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 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 resolved DSE which have been fully searched. Sermersheim Expires December 30, 2004 [Page 17] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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) . 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 client may wish to know 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 this has happened, and 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. 4.4.1 Forming a ChainedRequest The following fields are populated as instructed: 4.4.1.1 ChainedRequest.chainingArguments.targetObject Intermediate referrals must and normal referrals may convey a new target object. Each of the following fields is examined in order, and if a DN value is present in any of them, it becomes the ChainedRequest.chainingArguments.targetObject. Sermersheim Expires December 30, 2004 [Page 18] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 The DN field of the ContinuationReference.referralURI. The ContinuationReference.targetObject field. The ContinuationReference.localReference field. If there is no DN value in the ContinuationReference.referralURI, and if the ContinuationReference.targetObject and ContinuationReference.localReference fields are not present, the target object is assumed to be that of the original directory operation. Note that an empty value in the ContinuationReference.targetObject or ContinuationReference.localReference field denotes the root object. After performing the above determination as to the target object, any RDNSequence in ContinuationReference.remainingName is prepended to the determined target object. This value becomes the ChainedRequest.chainingArguments.targetObject. 4.4.1.2 ChainedRequest.chainingArguments.traceInformation 4.4.1.3 ChainedRequest.chainingArguments.searchScope This is populated with Referral.searchScope if present, and not populated otherwise. 4.4.1.4 ChainedRequest.chainingArguments.searchedSubtrees This is populated with Referral.excludeSubtree. 4.4.1.5 ChainedRequest.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 one of unavailable, or busy. Note that 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. Sermersheim Expires December 30, 2004 [Page 19] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 4.4.3 Handling Sub-operation controls and result codes 4.4.4 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. 4.5 Receiving a ChainedRequest 4.6 Returning a ChainedResponse 4.7 Receiving a ChainedResponse 4.8 Returning a Referral or SearchResultReference 4.9 Acting on a Referral or SearchResultReference 4.10 Ensuring non-existence of an entry under an nssr 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 . 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 is not able or allowed to chain, but is configured to return referrals, it will return a referral and include the . The client (after optionally contacting the DSAs in the referral to ensure the entry to be added does not exist) may then decide to force the add operation to be applied by re-sending the Add or ModifyDN request with the ManageDsaIT control. This will effectively cause the DSA to skip the check of remote DSAs and proceed with the operation. Sermersheim Expires December 30, 2004 [Page 20] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 4.11 Using the ManageDsaIT control This control 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. Sermersheim Expires December 30, 2004 [Page 21] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 5. Security Considerations 6 Normative References [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. [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [X500] International Telephone and Telegraph Consultative Committee, "The Directory - overview of concepts, models and services", ITU-T Recommendation X.500, November 1993. [X680] International International Telephone and Telegraph Consultative Committee, "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. Sermersheim Expires December 30, 2004 [Page 22] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 December 30, 2004 [Page 23] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 (2004). 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 December 30, 2004 [Page 24] =0C --=__PartE1C1A096.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartE1C1A096.0__=-- From ldapext-bounces@ietf.org Sun Aug 1 20:53:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06018 for ; Sun, 1 Aug 2004 20:53:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrQtN-0007Zl-8i; Sun, 01 Aug 2004 20:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrQmE-0003gD-HE for ldapext@megatron.ietf.org; Sun, 01 Aug 2004 20:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05097 for ; Sun, 1 Aug 2004 20:34:03 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrQox-0003hd-Cw for ldapext@ietf.org; Sun, 01 Aug 2004 20:36:57 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Sun, 01 Aug 2004 18:33:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Sun, 01 Aug 2004 17:32:55 -0600 From: "Jim Sermersheim" To: , "Jim Sermersheim" Subject: Re: [ldapext] Distributed Operations Rough Draft Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartEECEAFB7.0__=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 853c053a15e5e83137dff862c05cdaff X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartEECEAFB7.0__= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit I fixed and added more stuff. Jim >>> "Jim Sermersheim" 8/1/04 2:33:10 PM >>> All, I just wanted to drop an update regarding the work I'm trying to do with LDAP chained operations. At Mark Ennis' suggestion, I have changed the approach I was taking in the previous chained operation I-D I posted. Instead, this draft I-D attempts a fuller explanation of distributed directory procedures. In it, I begin by discussing name resolution and operation evaluation, and end by discussing operation distribution via chaining or referral following. In the middle, I use a ContinuationReference data type to tie things together. The goal that prompted this is that I'd like to have a model where whether an operation is to be distributed via chaining versus referral following, both methods have the same class of service. You may also note that I'm proposing to do certain things slightly differently than X.518 does (namely, the targetObject is the name of the reference object causing the operation to be distributed, rather than the parent of the next naming context being resolved or operated on. I did this for two primary reasons 1) I view it as a much simpler model. Some of the baggage that came with the X.518 method causes numerous subtleties that escape the casual (and even focused) reader. 2) LDAP has already set a precedent in the way that referrals and searchContinuationReferences are returned and handled. You'll note that the later sections are sparse or just not filled in yet. I have the information in different places, I just haven't consolidated (editied) it all into this document yet. If anyone would like to meet for impromptu meetings at IETF60, drop me a note. Or if you're not in San Diego, feel free to review the document, but be aware that I'm scurrying to finish it. I do welcome any feedback regarding whether you think I'm on or off track in any areas though. Thanks, Jim --=__PartEECEAFB7.0__= Content-Type: text/plain; name="draft-sermersheim-ldap-distproc.txt" Content-Disposition: attachment; filename="draft-sermersheim-ldap-distproc.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA05097 Content-Transfer-Encoding: quoted-printable Network Working Group J. Sermersheim Internet-Draft Novell, Inc Expires: December 30, 2004 July 2004 Distributed Procedures for LDAP Operations draft-sermersheim-ldap-distproc.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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides the data types and procedures used while servicing Lightweight Directory Application 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 December 30, 2004 [Page 1] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 Table of Contents 1. Distributed Operations Overview . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Distributed Operation Data Types . . . . . . . . . . . . . . 5 3.1 ContinuationReference . . . . . . . . . . . . . . . . . . 5 3.2 ChainedRequest . . . . . . . . . . . . . . . . . . . . . . 8 3.3 ChainedResponse . . . . . . . . . . . . . . . . . . . . . 10 4. Distributed Procedures . . . . . . . . . . . . . . . . . . . 12 4.1 Name resolution . . . . . . . . . . . . . . . . . . . . . 12 4.2 Operation Evaluation . . . . . . . . . . . . . . . . . . . 14 4.3 Populating the ContinuationReference . . . . . . . . . . . 16 4.4 Sending a ChainedRequest . . . . . . . . . . . . . . . . . 18 4.5 Receiving a ChainedRequest . . . . . . . . . . . . . . . . 21 4.6 Returning a ChainedResponse . . . . . . . . . . . . . . . 22 4.7 Receiving a ChainedResponse . . . . . . . . . . . . . . . 22 4.8 Returning a Referral or SearchResultReference . . . . . . 23 4.9 Acting on a Referral or SearchResultReference . . . . . . 23 4.10 Ensuring non-existence of an entry under an nssr . . . . 23 4.11 Using the ManageDsaIT control . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . 24 6. Normative References . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . 26 Sermersheim Expires December 30, 2004 [Page 2] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 ) 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 DSA interaction are defined to meet these requirements, namely "chaining", "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, the request may be decomposed into several subrequests prior to the interaction. Sermersheim Expires December 30, 2004 [Page 3] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 December 30, 2004 [Page 4] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 3. Distributed Operation Data Types The data types in this section are used by the chaining and referral distributed operation mechanisms 3.1 ContinuationReference As an operation is being processed by a DSA, it is useful to keep track of information passed to and from 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 below. In general, a ContinuationReference is used when indicating that directory information being acted on is not present locally, but that it may be present elsewhere. A ContinuationReference field consists of one or more addresses to 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 ::=3D SET { referralURI [0] SET SIZE (1..MAX) OF URI, remoteName [1] LDAPDN OPTIONAL, localReference [2] LDAPDN, remainingName [3] RelativeLDAPDN OPTIONAL, searchScope [4] SearchScope OPTIONAL, searchedSubtrees [5] SearchedSubtrees OPTIONAL, failedName [6] LDAPDN OPTIONAL, ... } )> URI ::=3D LDAPString -- limited to characters permitted in URIs SearchScope::=3D ENUMERATED { baseObject [0], singleLevel [1], wholeSubtree [2], subordinateSubtree [3], ... } Sermersheim Expires December 30, 2004 [Page 5] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 SearchedSubtrees ::=3D 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 This specifies (at minimum) the protocol and address of one or more remote DSA(s) holding the data sought after. The format is that of any valid URI which identifies the access point of a DSA. Each referralURI value must convey the information (typically protocol and address) needed to contact the identified DSE. In some cases, referralURI values will contain other data which can be used while distributing the operation. Sometimes similar data exists as fields of the ContinuationReference (an example is where the referralURI is an LDAP URL, holds a DN value, and the remoteName field is also present). In these cases, the data held on the referralURI value 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], it MUST be in the form of an LDAP URL [RFC2255] The list of referralURI values is used by the receiver to progress the operation. 3.1.2 ContinuationReference.remoteName This field may be used to hold a new base DN for the operation to use. This field may be used if the DSA allows name mappings. That is, if Sermersheim Expires December 30, 2004 [Page 6] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 an object residing on a remote DSA has a name that differs from the local name of the reference which represents that remote object, this field can be used to convey the name of the remote object. If the DSA does not allow name mapping to occur, this field will not be used for that purpose. If a target DN is present in a referralURI value, it overrides this field while that referralURI value is being operated upon. 3.1.3 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. For purposes of determining a new target object name, if the remoteName field is present, it overrides this field. 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 remainingName value of the new target object name. 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 Sermersheim Expires December 30, 2004 [Page 7] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 operations caused by the existence of a DSE of type nssr. 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 have 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. 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. 3.2 ChainedRequest The Chained Request is sent as an LDAP extended operation. The requestName is . The requestValue is the BER encoding of the following ChainedRequestValue ASN.1 definition: ChainedRequestValue ::=3D SEQUENCE { chainingArguments ChainingArguments, operationRequest OperationRequest } ChainingArguments ::=3D SEQUENCE { targetObject [0] LDAPDN OPTIONAL, traceInformation [1] ChainingTraceInformation, searchScope [2] SearchScope OPTIONAL, searchedSubtrees [3] SearchedSubtrees OPTIONAL} ChainingTraceInformation ::=3D SET OF LDAPURL OperationRequest ::=3D SEQUENCE { Request ::=3D CHOICE { bindRequest BindRequest, searchRequest SearchRequest, modifyRequest ModifyRequest, addRequest AddRequest, delRequest DelRequest, modDNRequest ModifyDNRequest, Sermersheim Expires December 30, 2004 [Page 8] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. 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.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.3 ChainedRequestValue.chainingArguments.searchScope See Section 3.1.5 Sermersheim Expires December 30, 2004 [Page 9] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 If the receiver encounters a value of subordinateSubtree, 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.4 ChainedRequestValue.chainingArguments.searchedSubtrees See Section 3.1.6 3.2.2 ChainedRequestValue.operationRequest This holds the original LDAP operation request. This is restricted to a subset of all LDAP operation. 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. If an unbind request is unbinding a previously chained bind, the server servicing the unbind request ensures that the unbind is properly chained. 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 operationRequest. 3.3 ChainedResponse The Chained Response is sent as an LDAP extended operation. The requestName is omitted. The requestValue is the BER encoding of the following ChainedResponseValue ASN.1 definition. ChainedResponseValue ::=3D SEQUENCE { chainedResults ChainingResults, operationResponse OperationResponse } ChainingResults ::=3D SEQUENCE { searchedSubtrees [0] SearchedSubtrees OPTIONAL, ... } OperationResponse ::=3D SEQUENCE { Response ::=3D CHOICE { Sermersheim Expires December 30, 2004 [Page 10] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 bindResponse BindResponse, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, 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] 3.3.1 ChainedResponseValue.chainedResults 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 ChainedResponseValue.chainedResults.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 ChainedResponseValue.chainedResults.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. 3.3.2 ChainedResponseValue.operationResponse This holds the response message tied to the ChainedRequestValue.operationRequest. Sermersheim Expires December 30, 2004 [Page 11] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. Name resolution is the act of locating 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 =E2=80=93 chaining, and returning referrals. Chaining is the act of forwarding an unfinished operation to another DSA for completion. In this case, the forwarding DSA sends a chained operation and a receiving DSA receives the chained operation. Alternately, the DSA may return a referral (or intermediate referral), and the client may follow 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' refers to a referral returned during the operation evaluation phase of an operation. These include searchResultReferences, referrals returned with an intermediateResponse , 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 into these distributed operation modes 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 If it is found that the target does not name a local DSE nor a DSE held by another DSA, it is said that the target does not exist, and the operation fails with noSuchObject (subject to local policy). Sermersheim Expires December 30, 2004 [Page 12] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 If it is found that the DSE named by target is non-local to the DSE, but may reside elsewhere, name resolution is said to be incomplete. In this case, the operation may be distributed by following the instructions in 4.1.1 Determining that a DSE is local to a DSA If a DSE held by a DSA meets the following criteria, it is said to be local to that DSA: o It is or falls (hierarchically) under and administrative point. o it is a DSE of any of the types: * root * cp * entry * alias * admPoint * subentry 4.1.2 Determining that a named target does not exist A named target DN is said to to not exist if the following are met: o At least one RDN has matched a DSE during name resolution. o An RDN is encountered that names no DSE. o The last DSE resolved is local to the DSA. 4.1.3 Determining that the target is non-local If the following are met, then the DSE named by the target is said to be non-local to a DSA: o It is not found to be local to the DSA. o It is not found to not exist In this case, 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 the 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: Sermersheim Expires December 30, 2004 [Page 13] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 o subr o supr o xr 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 found distributed knowledge information is mis-configured, and the error 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.10 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 target DN being modified. If either of these result in a non-local name, the name causing the operation to be distributed should be conveyed. Mechanisms for doing this are discussed in and . If during operation evaluation of a ModifyDN operation, the newSuperior names a DSE 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 . 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. This is done as specified in 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). Sermersheim Expires December 30, 2004 [Page 14] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 in the search scope: o subr o nssr (see nssr note) o xr Note that due to alias dereferencing, locating any DSE of the above types in the search scope may be possible. 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. 4.2.1.1 Search operation with singleLevel scope If during operation evaluation of a search with a singleLevel scope distributed knowledge information is found, it will cause the subsequent distributed progression of the search to use a scope of baseObject. 4.2.1.2 Search operation encountering a DSE of type nssr When a search operation encounters a DSE type nssr during operation evaluation, the following instructions are followed, but only if the search requires that subordinates of the nssr DSE are to be examined. 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 subsequent distributed progression of the search is caused to use a base of the found DSE, and a scope of subordinateSubtree. This causes the receiving DSAs to only apply the search to entries below the new target object. Sermersheim Expires December 30, 2004 [Page 15] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. This causes the receiving DSAs to 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, or if the ManageDsaIT control is attached. 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, or if the ManageDsaIT control is attached. 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 any target DN in the referralURI value(s), remoteName, 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 be populated without any Sermersheim Expires December 30, 2004 [Page 16] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 target DN in the referralURI value(s), remoteName, localReference, or remainingName. remoteName is populated with the DN value of the refRemoteName attribute (if present) 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. 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 found distributed knowledge is not the same as the base DN of the operation, the ContinuationReference must contain either the remoteName, localReference, or DN part(s) in each referralURI value. It may also contain a value in the remainingName field. Such cases include but are not limited 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 which holds the location of a DSA to be used in progressing the operation. 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 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. Sermersheim Expires December 30, 2004 [Page 17] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 resolved DSE 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) . 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 client may wish to know 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 this has happened, and 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 returning a value of in the supportedFeatures attribute on the root DSE. Sermersheim Expires December 30, 2004 [Page 18] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 4.4.1 Forming a ChainedRequest The following fields are populated as instructed: 4.4.1.1 ChainedRequestValue.chainingArguments.targetObject Intermediate referrals must and normal referrals may convey a new target object. Each of the following fields is examined in order, and if a DN value is present in any of them, it becomes the ChainedRequestValue.chainingArguments.targetObject. o The DN field of the ContinuationReference.referralURI. o The ContinuationReference.targetObject field. o The ContinuationReference.localReference field. If there is no DN value in the ContinuationReference.referralURI, and if the ContinuationReference.targetObject and ContinuationReference.localReference fields are not present, the target object is assumed to be that of the original directory operation. Note that an empty value in the ContinuationReference.targetObject or ContinuationReference.localReference field denotes the root object. After performing the above determination as to the target object, any RDNSequence in ContinuationReference.remainingName is prepended to the determined 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.traceInformation This is populated as specified in Section 3.2.1.2. 4.4.1.3 ChainedRequestValue.chainingArguments.searchScope This is populated with Referral.searchScope if present, and not populated otherwise. 4.4.1.4 ChainedRequestValue.chainingArguments.searchedSubtrees This is populated with Referral.excludeSubtree. 4.4.1.5 ChainedRequestValue.operationRequest This is populated with the original directory operation request. Sermersheim Expires December 30, 2004 [Page 19] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 one of unavailable, or busy. Note that 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. 4.4.3 Loop Prevention Prior to sending a ChainedRequest, the DSA may attempt to prevent looping scenarios by comparing 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.5.2). This is because the sending DSA is only aware of a single address on which the receiving DSA accepts connections. 4.4.4 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 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 Sermersheim Expires December 30, 2004 [Page 20] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 return unavailableCriticalExtension for critical controls that it cannot or will not chain. 4.4.4.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. 4.4.5 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. 4.5 Receiving a ChainedRequest A DSA which is able to receive and service a ChainedRequest may advertise this feature by returning a value of in the supportedExtension attribute of the root DSE. The ChainedRequestValue data type is the requestValue of an 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.5.1 Target Object determination Prior to checking for a loop condition, the target object must be determined. If the ChainedRequestType.targetObject field is present, its value becomes the target object. Otherwise, the base DN found in the ChainedRequestType.operationRequest becomes the target object. 4.5.2 Loop Detection The loop detection check happens when a DSA receives a chained Sermersheim Expires December 30, 2004 [Page 21] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 operation, prior to acting on the operation. The DSA compares 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.5.1 matches the DN value found in the ChainedRequestValue.traceInformation value. If a match is found the DSA returns a loopDetect result. 4.5.3 Processing the ChainedRequestValue.operationRequest In processing the operationRequest, the DSA uses the target object determined in Section 4.5.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 ChainedResponse. 4.6 Returning a ChainedResponse When returning responses to a ChainedRequest, the ChainedResponse is used. If the ChainedResponseValue.operationResponse is a searchResultDone, the ChainedResponseValue.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. 4.6.1 ChainedResponse.resultCode The resultCode for the ChainedResponse is distinct from the result code of the ChainedResponse.operationResponse. 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.6.2 Returning referrals in the ChainedResponse . 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 is not able or allowed to chain, but is configured to return referrals, it will return a referral and include the . The client (after optionally contacting the DSAs in the referral to ensure the entry to be added does not exist) may then decide to force the add operation to be applied by re-sending the Add or ModifyDN request with the ManageDsaIT control. This will effectively cause the DSA to skip the check of remote DSAs and proceed with the operation. 4.11 Using the ManageDsaIT control This control 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. Sermersheim Expires December 30, 2004 [Page 23] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 5. Security Considerations 6 Normative References [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. [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [X500] International Telephone and Telegraph Consultative Committee, "The Directory - overview of concepts, models and services", ITU-T Recommendation X.500, November 1993. [X680] International International Telephone and Telegraph Consultative Committee, "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. Sermersheim Expires December 30, 2004 [Page 24] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 December 30, 2004 [Page 25] =0C Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 (2004). 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 December 30, 2004 [Page 26] =0C --=__PartEECEAFB7.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartEECEAFB7.0__=-- From ldapext-bounces@ietf.org Mon Aug 2 20:41:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18425 for ; Mon, 2 Aug 2004 20:41:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brn9L-0006aG-40; Mon, 02 Aug 2004 20:27:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brmy8-0001tj-6I for ldapext@megatron.ietf.org; Mon, 02 Aug 2004 20:15:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16966 for ; Mon, 2 Aug 2004 20:15:50 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brn13-0007fi-RN for ldapext@ietf.org; Mon, 02 Aug 2004 20:18:56 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 02 Aug 2004 18:15:18 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 02 Aug 2004 18:14:56 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Distributed Operations Rough Draft Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartEECEAC10.0__=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3c17c30863138a166f08df9adf6d7a55 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartEECEAC10.0__= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Here's another update of this document. At this point, all the major sections are in place. I need to take a few passes at polishing it. I also think there's one more control to be added, and maybe one more data field (explained in statements). I'm only re-sending in case someone is interested in reviewing before I make the submission next week. I'll send an update if I do anything else substantial. Jim >>> Jim Sermersheim 8/1/04 4:32:55 PM >>> I fixed and added more stuff. Jim >>> "Jim Sermersheim" 8/1/04 2:33:10 PM >>> All, I just wanted to drop an update regarding the work I'm trying to do with LDAP chained operations. At Mark Ennis' suggestion, I have changed the approach I was taking in the previous chained operation I-D I posted. Instead, this draft I-D attempts a fuller explanation of distributed directory procedures. In it, I begin by discussing name resolution and operation evaluation, and end by discussing operation distribution via chaining or referral following. In the middle, I use a ContinuationReference data type to tie things together. The goal that prompted this is that I'd like to have a model where whether an operation is to be distributed via chaining versus referral following, both methods have the same class of service. You may also note that I'm proposing to do certain things slightly differently than X.518 does (namely, the targetObject is the name of the reference object causing the operation to be distributed, rather than the parent of the next naming context being resolved or operated on. I did this for two primary reasons 1) I view it as a much simpler model. Some of the baggage that came with the X.518 method causes numerous subtleties that escape the casual (and even focused) reader. 2) LDAP has already set a precedent in the way that referrals and searchContinuationReferences are returned and handled. You'll note that the later sections are sparse or just not filled in yet. I have the information in different places, I just haven't consolidated (editied) it all into this document yet. If anyone would like to meet for impromptu meetings at IETF60, drop me a note. Or if you're not in San Diego, feel free to review the document, but be aware that I'm scurrying to finish it. I do welcome any feedback regarding whether you think I'm on or off track in any areas though. Thanks, Jim --=__PartEECEAC10.0__= Content-Type: text/plain; name="draft-sermersheim-ldap-distproc.txt" Content-Disposition: attachment; filename="draft-sermersheim-ldap-distproc.txt" Content-Transfer-Encoding: 8bit Network Working Group J. Sermersheim Internet-Draft Novell, Inc Expires: December 30, 2004 July 2004 Distributed Procedures for LDAP Operations draft-sermersheim-ldap-distproc.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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides the data types and procedures used while servicing Lightweight Directory Application 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 December 30, 2004 [Page 1] Internet-Draft Distributed Procedures for LDAP Operations July 2004 Table of Contents 1. Distributed Operations Overview . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Distributed Operation Data Types . . . . . . . . . . . . . . 5 3.1 ContinuationReference . . . . . . . . . . . . . . . . . . . 5 3.2 ChainedRequest . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 ChainedResponse . . . . . . . . . . . . . . . . . . . . . . 10 4. Distributed Procedures . . . . . . . . . . . . . . . . . . . 12 4.1 Name resolution . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Operation Evaluation . . . . . . . . . . . . . . . . . . . . 14 4.3 Populating the ContinuationReference . . . . . . . . . . . . 16 4.4 Sending a ChainedRequest . . . . . . . . . . . . . . . . . . 19 4.5 Emulating the Sending of a ChainedRequest . . . . . . . . . 21 4.6 Receiving a ChainedRequest . . . . . . . . . . . . . . . . . 22 4.7 Returning a ChainedResponse . . . . . . . . . . . . . . . . 23 4.8 Receiving a ChainedResponse . . . . . . . . . . . . . . . . 23 4.9 Returning a Referral or Intermediate Referral . . . . . . . 24 4.10 Acting on a Referral or Intermediate Referral . . . . . . . 27 4.11 Ensuring non-existence of an entry under an nssr . . . . . . 27 4.12 Using the ManageDsaIT control . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . 29 6. Normative References . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . 30 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 A.1 LDAP Object Identifier Registrations . . . . . . . . . . . . 31 A.2 LDAP Protocol Mechanism Registrations . . . . . . . . . . . 31 A.3 LDAP Descriptor Registrations . . . . . . . . . . . . . . . 33 A.4 LDAP Result Code Registrations . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . 35 Sermersheim Expires December 30, 2004 [Page 2] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 ) 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 DSA interaction are defined to meet these requirements, namely "chaining", "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, the request may be decomposed into several subrequests prior to the interaction. Sermersheim Expires December 30, 2004 [Page 3] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 December 30, 2004 [Page 4] Internet-Draft Distributed Procedures for LDAP Operations July 2004 3. Distributed Operation Data Types The data types in this section are used by the chaining and referral distributed operation mechanisms 3.1 ContinuationReference As an operation is being processed by a DSA, it is useful to keep track of information passed to and from 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 below. In general, a ContinuationReference is used when indicating that directory information being acted on is not present locally, but that it may be present elsewhere. A ContinuationReference field consists of one or more addresses to 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, remoteName [1] LDAPDN OPTIONAL, localReference [2] LDAPDN, remainingName [3] RelativeLDAPDN OPTIONAL, searchScope [4] SearchScope OPTIONAL, searchedSubtrees [5] SearchedSubtrees OPTIONAL, failedName [6] LDAPDN OPTIONAL, ... } )> URI ::= LDAPString -- limited to characters permitted in URIs [RFC2396] SearchScope::= ENUMERATED { baseObject [0], singleLevel [1], wholeSubtree [2], subordinateSubtree [3], Sermersheim Expires December 30, 2004 [Page 5] Internet-Draft Distributed Procedures for LDAP Operations July 2004 ... } 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 This specifies (at minimum) the protocol and address of one or more remote DSA(s) holding the data sought after. The format is that of any valid URI which identifies the access point of a DSA. Each referralURI value must convey the information (typically protocol and address) needed to contact the identified DSE. In some cases, referralURI values will contain other data which can be used while distributing the operation. Sometimes similar data exists as fields of the ContinuationReference (an example is where the referralURI is an LDAP URL, holds a DN value, and the remoteName field is also present). In these cases, the data held on the referralURI value 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], it MUST be in the form of an LDAP URL [RFC2255] The list of referralURI values is used by the receiver to progress the operation. 3.1.2 ContinuationReference.remoteName This field may be used to hold a new base DN for the operation to use. Sermersheim Expires December 30, 2004 [Page 6] Internet-Draft Distributed Procedures for LDAP Operations July 2004 This field may be used if the DSA allows name mappings. That is, if an object residing on a remote DSA has a name that differs from the local name of the reference which represents that remote object, this field can be used to convey the name of the remote object. If the DSA does not allow name mapping to occur, this field will not be used for that purpose. If a target DN is present in a referralURI value, it overrides this field while that referralURI value is being operated upon. 3.1.3 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. For purposes of determining a new target object name, if the remoteName field is present, it overrides this field. 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 remainingName value of the new target object name. 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 Sermersheim Expires December 30, 2004 [Page 7] Internet-Draft Distributed Procedures for LDAP Operations July 2004 DN itself. This is used here when progressing distributed search operations caused by the existence of a DSE of type nssr. 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 have 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. 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. 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, traceInformation [1] ChainingTraceInformation, searchScope [2] SearchScope OPTIONAL, searchedSubtrees [3] SearchedSubtrees OPTIONAL} ChainingTraceInformation ::= SET OF LDAPURL OperationRequest ::= SEQUENCE { Request ::= CHOICE { bindRequest BindRequest, searchRequest SearchRequest, modifyRequest ModifyRequest, addRequest AddRequest, delRequest DelRequest, Sermersheim Expires December 30, 2004 [Page 8] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. 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.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.3 ChainedRequestValue.chainingArguments.searchScope See Section 3.1.5 Sermersheim Expires December 30, 2004 [Page 9] Internet-Draft Distributed Procedures for LDAP Operations July 2004 If the receiver encounters a value of subordinateSubtree 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.4 ChainedRequestValue.chainingArguments.searchedSubtrees See Section 3.1.6 3.2.2 ChainedRequestValue.operationRequest This holds the original LDAP operation request. This is restricted to a subset of all LDAP operation. 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. If an unbind request is unbinding a previously chained bind, the server servicing the unbind request ensures that the unbind is properly chained. 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 operationRequest. 3.3 ChainedResponse The Chained Response is sent as an LDAP extended operation. The requestName is omitted. The requestValue is the BER encoding of the following ChainedResponseValue ASN.1 definition. ChainedResponseValue ::= SEQUENCE { chainedResults ChainingResults, operationResponse OperationResponse } ChainingResults ::= SEQUENCE { searchedSubtrees [0] SearchedSubtrees OPTIONAL, ... } OperationResponse ::= SEQUENCE { Response ::= CHOICE { Sermersheim Expires December 30, 2004 [Page 10] Internet-Draft Distributed Procedures for LDAP Operations July 2004 bindResponse BindResponse, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, 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] 3.3.1 ChainedResponseValue.chainedResults 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 ChainedResponseValue.chainedResults.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 ChainedResponseValue.chainedResults.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. 3.3.2 ChainedResponseValue.operationResponse This holds the response message tied to the ChainedRequestValue.operationRequest. Sermersheim Expires December 30, 2004 [Page 11] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. Name resolution is the act of locating 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. In this case, the forwarding DSA sends a chained operation and a receiving DSA receives the chained operation. Alternately, the DSA may return a referral (or intermediate referral), and the client may follow 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' refers to 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 into these distributed operation modes 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 If it is found that the target does not name a local DSE nor a DSE held by another DSA, it is said that the target does not exist, and the operation fails with noSuchObject (subject to local policy). Sermersheim Expires December 30, 2004 [Page 12] Internet-Draft Distributed Procedures for LDAP Operations July 2004 If it is found that the DSE named by target is non-local to the DSE, but may reside elsewhere, name resolution is said to be incomplete. In this case, the operation may be distributed by following the instructions found in subsections of this section. 4.1.1 Determining that a DSE is local to a DSA If a DSE held by a DSA meets the following criteria, it is said to be local to that DSA: o It is or falls (hierarchically) under and administrative point. o it is a DSE of any of the types: * root * cp * entry * alias * admPoint * subentry 4.1.2 Determining that a named target does not exist A named target DN is said to to not exist if the following are met: o At least one RDN has matched a DSE during name resolution. o An RDN is encountered that names no DSE. o The last DSE resolved is local to the DSA. 4.1.3 Determining that the target is non-local If the following are met, then the DSE named by the target is said to be non-local to a DSA: o It is not found to be local to the DSA. o It is not found to not exist In this case, 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 the 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: Sermersheim Expires December 30, 2004 [Page 13] Internet-Draft Distributed Procedures for LDAP Operations July 2004 o subr o supr o xr 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 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 target 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). If during operation evaluation of a ModifyDN operation, the newSuperior names a DSE 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. 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. 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). Sermersheim Expires December 30, 2004 [Page 14] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 in the search scope: o subr o nssr (see nssr note) o xr Note that due to alias dereferencing, locating any DSE of the above types in the search scope may be possible. 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. 4.2.1.1 Search operation with singleLevel scope If during operation evaluation of a search with a singleLevel scope distributed knowledge information is found, it will cause the subsequent distributed progression of the search to use a scope of baseObject. 4.2.1.2 Search operation encountering a DSE of type nssr When a search operation encounters a DSE type nssr during operation evaluation, the following instructions are followed, but only if the search requires that subordinates of the nssr DSE are to be examined. 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 subsequent distributed progression of the search is caused to use a base of the found DSE, and a scope of subordinateSubtree. This causes the receiving DSAs to only apply the search to entries below the new target object. Sermersheim Expires December 30, 2004 [Page 15] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. This causes the receiving DSAs to 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, or if the ManageDsaIT control is attached. 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, or if the ManageDsaIT control is attached. 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 any target DN in the referralURI value(s), remoteName, 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 be populated without any Sermersheim Expires December 30, 2004 [Page 16] Internet-Draft Distributed Procedures for LDAP Operations July 2004 target DN in the referralURI value(s), remoteName, localReference, or remainingName. remoteName is populated with the DN value of the refRemoteName attribute (if present) 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. 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 found distributed knowledge is not the same as the base DN of the operation, the ContinuationReference must contain either the remoteName, localReference, or DN part(s) in each referralURI value. It may also contain a value in the remainingName field. Such cases include but are not limited 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 which holds the location of a DSA to be used in progressing the operation. 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 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 Sermersheim Expires December 30, 2004 [Page 17] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 resolved DSE 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). 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 Sermersheim Expires December 30, 2004 [Page 18] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 returning a value of IANA-ASSIGNED-OID.2; in the supportedFeatures attribute on the root DSE. 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. Each of the following fields is examined in order, and if a DN value is present in any of them, it becomes the candidate target object. o The dn field of the ContinuationReference.referralURI. o The ContinuationReference.targetObject field. o The ContinuationReference.localReference field. If there is no dn value in the ContinuationReference.referralURI, and if the ContinuationReference.targetObject and ContinuationReference.localReference fields are not present, the candidate target object is assumed to be that of the original directory operation. Note that an empty value in the ContinuationReference.targetObject or ContinuationReference.localReference field denotes the root object. After performing the above determination as to the target object, any RDNSequence in ContinuationReference.remainingName is prepended to the determined target object. This value becomes the ChainedRequestValue.chainingArguments.targetObject. If this value matches the value of the original operation, this field may be omitted. Sermersheim Expires December 30, 2004 [Page 19] Internet-Draft Distributed Procedures for LDAP Operations July 2004 4.4.1.2 ChainedRequestValue.chainingArguments.traceInformation This is populated as specified in Section 3.2.1.2. 4.4.1.3 ChainedRequestValue.chainingArguments.searchScope This is populated with the scope field of the ContinuationReference.referralURI if present, otherwise by the ContinuationReference.searchScope if present, and not populated otherwise. . 4.4.1.4 ChainedRequestValue.chainingArguments.searchedSubtrees This is populated with ContinuationReference.searchedSubtrees, as well as any previously received values of ChainedResponseValue.chainingResults.searchedSubtrees which are subordinate, relative to the target object 4.4.1.5 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 one of unavailable, or busy . Note that 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. 4.4.3 Loop Prevention Prior to sending a ChainedRequest, the DSA may attempt to prevent looping scenarios by comparing 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 Sermersheim Expires December 30, 2004 [Page 20] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 the operation. 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 for context> Sermersheim Expires December 30, 2004 [Page 21] Internet-Draft Distributed Procedures for LDAP Operations July 2004 o Other fields (such as the messageID, and non-critical controls) may also need to be updated or excluded. 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. The ChainedRequestValue data type is the requestValue of an 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.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 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 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 ChainedResponse. Sermersheim Expires December 30, 2004 [Page 22] Internet-Draft Distributed Procedures for LDAP Operations July 2004 4.7 Returning a ChainedResponse When returning responses to a ChainedRequest, the ChainedResponse is used. If the ChainedResponseValue.operationResponse is a searchResultDone, the ChainedResponseValue.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. 4.7.1 ChainedResponse.resultCode The resultCode for the ChainedResponse is distinct from the result code of the ChainedResponse.operationResponse. 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 ChainedResponse 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 Sermersheim Expires December 30, 2004 [Page 24] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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, 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. 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. 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 target object candidate. Otherwise, the target object candidate comes from the ContinuationReference.remoteName if present, and if not, then from the ContinuationReference.localReference. Once Sermersheim Expires December 30, 2004 [Page 25] Internet-Draft Distributed Procedures for LDAP Operations July 2004 the target object candidate is determined, the value of ContinuationReference.remainingName is prepended to the target object candidate. This new value becomes the target object and its string value (as specified in [RFC2253]) is placed in the 'dn' part of the LDAP URL. 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 in [RFC2253]) of the ContinuationReference.localReference value. 4.9.2.3 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. Otherwise it is conveyed as an extension. The extype is IANA-ASSIGNED-OID.5 or the descriptor 'searchScope', and the exvalue is one of 'base', 'one', 'sub', or 'subord' <. These relate respectively to the ContinuationReference.searchScope value. 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.4 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. For example: . 4.9.2.5 ContinuationReference.failedName This field is conveyed as an extension. The extype is 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. Sermersheim Expires December 30, 2004 [Page 26] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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.remoteName is omitted. o The ContinuationReference.localReference is omitted. o The ContinuationReference.remainingName is omitted. o The ContinuationReference.searchScope is is populated with any searchScope LDAP URI extension Section 4.9.2.3 value found on an LDAP URI in the referral or intermediate referral. If none exist, this field is omitted. o The ContinuationReference.searchedSubtrees is populated with any searchedSubtrees LDAP URI extension Section 4.9.2.4 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.5 value found on an LDAP URI in the referral or intermediate referral. If none exist, this field is omitted. 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 In order to ensure there are no entries matching the name of the Sermersheim Expires December 30, 2004 [Page 27] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 . 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 is not able or allowed to chain, but is configured to return referrals, it will return a referral and include the . The client (after optionally contacting the DSAs in the referral to ensure the entry to be added does not exist) may then decide to force the add operation to be applied by re-sending the Add or ModifyDN request with the ManageDsaIT control. This will effectively cause the DSA to skip the check of remote DSAs and proceed with the operation. 4.12 Using the ManageDsaIT control This control 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. Sermersheim Expires December 30, 2004 [Page 28] Internet-Draft Distributed Procedures for LDAP Operations July 2004 5. Security Considerations 6 Normative References [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. [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. [X680] International International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, July 2002. Sermersheim Expires December 30, 2004 [Page 29] Internet-Draft Distributed Procedures for LDAP Operations July 2004 [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 December 30, 2004 [Page 30] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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.5 searchScope: 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 Sermersheim Expires December 30, 2004 [Page 31] Internet-Draft Distributed Procedures for LDAP Operations July 2004 Person & email address to contact for further information: 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: searchScope 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 Sermersheim Expires December 30, 2004 [Page 32] Internet-Draft Distributed Procedures for LDAP Operations July 2004 Usage: Extension 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): searchScope 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 Sermersheim Expires December 30, 2004 [Page 33] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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): 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 December 30, 2004 [Page 34] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 (2004). 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 December 30, 2004 [Page 35] --=__PartEECEAC10.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartEECEAC10.0__=-- From ldapext-bounces@ietf.org Thu Aug 5 02:32:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27161 for ; Thu, 5 Aug 2004 02:32:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsblr-0008R3-35; Thu, 05 Aug 2004 02:30:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsbkn-00089b-GB for ldapext@megatron.ietf.org; Thu, 05 Aug 2004 02:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26888 for ; Thu, 5 Aug 2004 02:29:27 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsboC-0000ew-8b for ldapext@ietf.org; Thu, 05 Aug 2004 02:33:02 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 05 Aug 2004 00:28:54 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 05 Aug 2004 00:28:28 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Distributed Operations Rough Draft Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part77572A9C.0__=" X-Spam-Score: 0.0 (/) X-Scan-Signature: a361da22f753713baf59634ba3fe84a4 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part77572A9C.0__= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Here's one more pass before I leave the sanctuary of San Diego and venture into can't-get-anything-done land. This one is (hopefully) a little cleaner and more self-supported. Jim >>> "Jim Sermersheim" 8/2/04 5:14:56 PM >>> Here's another update of this document. At this point, all the major sections are in place. I need to take a few passes at polishing it. I also think there's one more control to be added, and maybe one more data field (explained in statements). I'm only re-sending in case someone is interested in reviewing before I make the submission next week. I'll send an update if I do anything else substantial. Jim >>> Jim Sermersheim 8/1/04 4:32:55 PM >>> I fixed and added more stuff. Jim >>> "Jim Sermersheim" 8/1/04 2:33:10 PM >>> All, I just wanted to drop an update regarding the work I'm trying to do with LDAP chained operations. At Mark Ennis' suggestion, I have changed the approach I was taking in the previous chained operation I-D I posted. Instead, this draft I-D attempts a fuller explanation of distributed directory procedures. In it, I begin by discussing name resolution and operation evaluation, and end by discussing operation distribution via chaining or referral following. In the middle, I use a ContinuationReference data type to tie things together. The goal that prompted this is that I'd like to have a model where whether an operation is to be distributed via chaining versus referral following, both methods have the same class of service. You may also note that I'm proposing to do certain things slightly differently than X.518 does (namely, the targetObject is the name of the reference object causing the operation to be distributed, rather than the parent of the next naming context being resolved or operated on. I did this for two primary reasons 1) I view it as a much simpler model. Some of the baggage that came with the X.518 method causes numerous subtleties that escape the casual (and even focused) reader. 2) LDAP has already set a precedent in the way that referrals and searchContinuationReferences are returned and handled. You'll note that the later sections are sparse or just not filled in yet. I have the information in different places, I just haven't consolidated (editied) it all into this document yet. If anyone would like to meet for impromptu meetings at IETF60, drop me a note. Or if you're not in San Diego, feel free to review the document, but be aware that I'm scurrying to finish it. I do welcome any feedback regarding whether you think I'm on or off track in any areas though. Thanks, Jim --=__Part77572A9C.0__= Content-Type: text/plain; name="draft-sermersheim-ldap-distproc.txt" Content-Disposition: attachment; filename="draft-sermersheim-ldap-distproc.txt" Content-Transfer-Encoding: 8bit Network Working Group J;. Sermersheim Internet-Draft Novell, Inc Expires: December 30, 2004 July 2004 Distributed Procedures for LDAP Operations draft-sermersheim-ldap-distproc.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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides the data types and procedures used while servicing Lightweight Directory Application 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 December 30, 2004 [Page 1] Internet-Draft Distributed Procedures for LDAP Operations July 2004 Table of Contents 1. Distributed Operations Overview . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Distributed Operation Data Types . . . . . . . . . . . . . . 5 3.1 ContinuationReference . . . . . . . . . . . . . . . . . . . 5 3.2 ChainedRequest . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 ChainedResponse . . . . . . . . . . . . . . . . . . . . . . 11 4. Distributed Procedures . . . . . . . . . . . . . . . . . . . 13 4.1 Name resolution . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Operation Evaluation . . . . . . . . . . . . . . . . . . . . 15 4.3 Populating the ContinuationReference . . . . . . . . . . . . 17 4.4 Sending a ChainedRequest . . . . . . . . . . . . . . . . . . 20 4.5 Emulating the Sending of a ChainedRequest . . . . . . . . . 22 4.6 Receiving a ChainedRequest . . . . . . . . . . . . . . . . . 23 4.7 Returning a ChainedResponse . . . . . . . . . . . . . . . . 24 4.8 Receiving a ChainedResponse . . . . . . . . . . . . . . . . 24 4.9 Returning a Referral or Intermediate Referral . . . . . . . 25 4.10 Acting on a Referral or Intermediate Referral . . . . . . . 28 4.11 Ensuring non-existence of an entry under an nssr . . . . . . 29 4.12 Using the ManageDsaIT control . . . . . . . . . . . . . . . 29 4.13 Mapping a referralURI to an LDAP URI . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . 31 6. Normative References . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . 32 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 A.1 LDAP Object Identifier Registrations . . . . . . . . . . . . 33 A.2 LDAP Protocol Mechanism Registrations . . . . . . . . . . . 33 A.3 LDAP Descriptor Registrations . . . . . . . . . . . . . . . 35 A.4 LDAP Result Code Registrations . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . 37 Sermersheim Expires December 30, 2004 [Page 2] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 ) 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 DSA interaction are defined to meet these requirements, namely "chaining", "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, the request may be decomposed into several subrequests prior to the interaction. Sermersheim Expires December 30, 2004 [Page 3] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 December 30, 2004 [Page 4] Internet-Draft Distributed Procedures for LDAP Operations July 2004 3. Distributed Operation Data Types The data types in this section are used by the chaining and referral distributed operation mechanisms. 3.1 ContinuationReference As an operation is being processed by a DSA, it is useful to keep track of information passed to and from 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 below. In general, a ContinuationReference is used when indicating that directory information being acted on is not present locally, but that it may be present elsewhere. A ContinuationReference field consists of one or more addresses to 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, remoteName [1] LDAPDN OPTIONAL, localReference [2] LDAPDN, remainingName [3] RelativeLDAPDN OPTIONAL, searchScope [4] SearchScope OPTIONAL, searchedSubtrees [5] SearchedSubtrees OPTIONAL, failedName [6] LDAPDN OPTIONAL, ... } )> URI ::= LDAPString -- limited to characters permitted in URIs [RFC2396]. SearchScope::= ENUMERATED { baseObject [0], singleLevel [1], wholeSubtree [2], subordinateSubtree [3], Sermersheim Expires December 30, 2004 [Page 5] Internet-Draft Distributed Procedures for LDAP Operations July 2004 ... } 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 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.13. 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 value, and the ContinuationReference.remoteName 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. 3.1.1.1 Elements 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. Sermersheim Expires December 30, 2004 [Page 6] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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.remoteName. 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.localReference. See Section 3.1.3. 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.remoteName This field may be used to hold a new base DN for the operation to use. This field may be used if the DSA allows name mappings. That is, if an object residing on a remote DSA has a name that differs from the local name of the reference which represents that remote object, this field can be used to convey the name of the remote object. If the DSA does not allow name mapping to occur, this field will not be used for that purpose. If a referralURI.remoteName is present, it overrides this field while that referralURI value is being operated upon. 3.1.3 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. For purposes of determining a new target object name, if the remoteName field is present, it overrides this field. Sermersheim Expires December 30, 2004 [Page 7] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 remainingName value of the new target object name. 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. 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 have 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. 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. 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: Sermersheim Expires December 30, 2004 [Page 8] Internet-Draft Distributed Procedures for LDAP Operations July 2004 ChainedRequestValue ::= SEQUENCE { chainingArguments ChainingArguments, operationRequest OperationRequest } ChainingArguments ::= SEQUENCE { targetObject [0] LDAPDN OPTIONAL, traceInformation [1] ChainingTraceInformation, searchScope [2] SearchScope OPTIONAL, searchedSubtrees [3] 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. 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 Sermersheim Expires December 30, 2004 [Page 9] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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.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.3 ChainedRequestValue.chainingArguments.searchScope See Section 3.1.5. If the receiver encounters a value of subordinateSubtree 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.4 ChainedRequestValue.chainingArguments.searchedSubtrees See Section 3.1.6. 3.2.2 ChainedRequestValue.operationRequest This holds the original LDAP operation request. This is restricted to a subset of all LDAP operation. 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. If an unbind request is unbinding a previously chained bind, the server servicing the unbind request ensures that the unbind is properly chained. Sermersheim Expires December 30, 2004 [Page 10] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 operationRequest. 3.3 ChainedResponse The Chained Response is sent as an LDAP extended operation. The requestName is omitted. The requestValue is the BER encoding of the following ChainedResponseValue ASN.1 definition. ChainedResponseValue ::= SEQUENCE { chainedResults ChainingResults, operationResponse OperationResponse } ChainingResults ::= SEQUENCE { searchedSubtrees [0] SearchedSubtrees OPTIONAL, ... } OperationResponse ::= SEQUENCE { Response ::= CHOICE { bindResponse BindResponse, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, 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]. 3.3.1 ChainedResponseValue.chainedResults In general, this is used to convey additional information that may needed in the event that the operation needs to be progressed further. Sermersheim Expires December 30, 2004 [Page 11] Internet-Draft Distributed Procedures for LDAP Operations July 2004 3.3.1.1 ChainedResponseValue.chainedResults.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 ChainedResponseValue.chainedResults.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. 3.3.2 ChainedResponseValue.operationResponse This holds the response message tied to the ChainedRequestValue.operationRequest. Sermersheim Expires December 30, 2004 [Page 12] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. Name resolution is the act of locating 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. In this case, the forwarding DSA sends a chained operation and a receiving DSA receives the chained operation. Alternately, the DSA may return a referral (or intermediate referral), and the client may follow 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' refers to 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 into these distributed operation modes 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. If it is found that the target does not name a local DSE nor a DSE held by another DSA, it is said that the target does not exist, and the operation fails with noSuchObject (subject to local policy). Sermersheim Expires December 30, 2004 [Page 13] Internet-Draft Distributed Procedures for LDAP Operations July 2004 If it is found that the DSE named by target is non-local to the DSE, but may reside elsewhere, name resolution is said to be incomplete. In this case, the operation may be distributed by following the instructions found in subsections of this section. 4.1.1 Determining that a DSE is local to a DSA If a DSE held by a DSA meets the following criteria, it is said to be local to that DSA: o It is or falls (hierarchically) under and administrative point. o it is a DSE of any of the types: * root * cp * entry * alias * admPoint * subentry 4.1.2 Determining that a named DSE does not exist A named DSE is said to to not exist if the following are met: o At least one RDN has matched a DSE during name resolution. o An RDN is encountered that names no DSE. o The last DSE resolved is local to the DSA. 4.1.3 Determining that the target is non-local If the following are met, then the DSE named by the target is said to be non-local to a DSA: o It is not found to be local to the DSA. o It is not found to not exist. In this case, 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 the 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: Sermersheim Expires December 30, 2004 [Page 14] Internet-Draft Distributed Procedures for LDAP Operations July 2004 o subr o supr o xr 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. 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). If during operation evaluation of a ModifyDN operation, the newSuperior names a DSE 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. 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. 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). Sermersheim Expires December 30, 2004 [Page 15] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 in the search scope: o subr o nssr (see nssr note) o xr Note that due to alias dereferencing, locating any DSE of the above types in the search scope may be possible. 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. 4.2.1.1 Search operation with singleLevel scope If during operation evaluation of a search with a singleLevel scope distributed knowledge information is found, it will cause the subsequent distributed progression of the search to use a scope of baseObject. 4.2.1.2 Search operation encountering a DSE of type nssr When a search operation encounters a DSE type nssr during operation evaluation, the following instructions are followed, but only if the search requires that subordinates of the nssr DSE are to be examined. 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 subsequent distributed progression of the search is caused to use a base of the found DSE, and a scope of subordinateSubtree. This causes the receiving DSAs to only apply the search to entries below the new target object. Sermersheim Expires December 30, 2004 [Page 16] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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. This causes the receiving DSAs to 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, or if the ManageDsaIT control is attached. 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, or if the ManageDsaIT control is attached. 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 referralURI.remoteName, remoteName, 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 be populated without any of Sermersheim Expires December 30, 2004 [Page 17] Internet-Draft Distributed Procedures for LDAP Operations July 2004 referralURI.remoteName value(s), remoteName, localReference, or remainingName. remoteName is populated with the DN value of the refRemoteName attribute (if present). 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. 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 found distributed knowledge is not the same as the base DN of the operation, the ContinuationReference must contain either the remoteName, localReference, or referralURI.remoteName value in each referralURI. It may also contain a value in the remainingName field. Such cases include but are not limited 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 referralURI field must contain at least one value. Each referralURI value must hold a referralURI.acessPoint. 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 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 Sermersheim Expires December 30, 2004 [Page 18] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 resolved DSE 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). 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 Sermersheim Expires December 30, 2004 [Page 19] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 returning a value of IANA-ASSIGNED-OID.2; in the supportedFeatures attribute on the root DSE. 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. Each of the following fields is examined in order, and if a DN value is present in any of them, it becomes the candidate target object. o The ContinuationReference.referralURI.remoteName field. o The ContinuationReference.remoteName field. o The ContinuationReference.localReference field. If there is no DN in ContinuationReference.referralURI.remoteName, and if the ContinuationReference.remoteName and ContinuationReference.localReference fields are not present, the candidate target object is assumed to be that of the original directory operation. Note that an empty value in the ContinuationReference.remoteName or ContinuationReference.localReference field denotes the root object. After performing the above determination as to the target object, any RDNSequence in ContinuationReference.remainingName is prepended to the determined target object. This value becomes the ChainedRequestValue.chainingArguments.targetObject. If this value matches the value of the original operation, this field may be omitted. Sermersheim Expires December 30, 2004 [Page 20] Internet-Draft Distributed Procedures for LDAP Operations July 2004 4.4.1.2 ChainedRequestValue.chainingArguments.traceInformation This is populated as specified in Section 3.2.1.2. 4.4.1.3 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.4 ChainedRequestValue.chainingArguments.searchedSubtrees This is populated with ContinuationReference.searchedSubtrees, as well as any previously received values of ChainedResponseValue.chainingResults.searchedSubtrees which are subordinate, relative to the target object. 4.4.1.5 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 one of unavailable, or busy . Note that 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. 4.4.3 Loop Prevention Prior to sending a ChainedRequest, the DSA may attempt to prevent looping scenarios by comparing 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 Sermersheim Expires December 30, 2004 [Page 21] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 the operation. 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 for context> Sermersheim Expires December 30, 2004 [Page 22] Internet-Draft Distributed Procedures for LDAP Operations July 2004 o Other fields (such as the messageID, and non-critical controls) may also need to be updated or excluded. 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. The ChainedRequestValue data type is the requestValue of an 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.remoteName 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 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 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 ChainedResponse. Sermersheim Expires December 30, 2004 [Page 23] Internet-Draft Distributed Procedures for LDAP Operations July 2004 4.7 Returning a ChainedResponse When returning responses to a ChainedRequest, the ChainedResponse is used. If the ChainedResponseValue.operationResponse is a searchResultDone, the ChainedResponseValue.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. 4.7.1 ChainedResponse.resultCode The resultCode for the ChainedResponse is distinct from the result code of the ChainedResponse.operationResponse. 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 ChainedResponse 4.8 Receiving a ChainedResponse Processing a received ChainedResponse 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. It's also useful to note that in order to determine whether the ChainedResponse represents a final response, the chaining DSA must examine the ChainedResponse.operationResponse. For example, in the case of a search operation, a SearchResultDone indicates that the sub-operation has completed. 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 Sermersheim Expires December 30, 2004 [Page 24] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 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. 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. 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. 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 Sermersheim Expires December 30, 2004 [Page 25] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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, 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. 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. 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 part of the LDAP URL is already present, it is determined to be the target object candidate. Otherwise, the target object candidate comes from the ContinuationReference.remoteName if present, Sermersheim Expires December 30, 2004 [Page 26] Internet-Draft Distributed Procedures for LDAP Operations July 2004 and if not, then from the ContinuationReference.localReference. Once the target object candidate is determined, the value of ContinuationReference.remainingName is prepended to the target object candidate. This new value becomes the target object and its string value (as specified by in [RFC2253]) is placed in the part of the LDAP URL. 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 in [RFC2253]) of the ContinuationReference.localReference value. 4.9.2.3 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. Otherwise it is conveyed as an extension. The extype is IANA-ASSIGNED-OID.5 or the descriptor 'searchScope', and the exvalue is one of 'base', 'one', 'sub', or 'subord'. These relate respectively to the ContinuationReference.searchScope value. 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.4 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 = 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 searchedSubtress value containing two searched subtrees is: . 4.9.2.5 ContinuationReference.failedName This field is conveyed as an extension. The extype is IANA-ASSIGNED-OID.7 or the descriptor 'failedName', and the exvalue Sermersheim Expires December 30, 2004 [Page 27] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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.remoteName is omitted. o The ContinuationReference.localReference is omitted. o The ContinuationReference.remainingName is omitted. o The ContinuationReference.searchScope is is populated with any searchScope LDAP URI extension Section 4.9.2.3 value found on an LDAP URI in the referral or intermediate referral. If none exist, this field is omitted. o The ContinuationReference.searchedSubtrees is populated with any searchedSubtrees LDAP URI extension Section 4.9.2.4 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.5 value found on an LDAP URI in the referral or intermediate referral. If none exist, this field is omitted. Note that many fields are simply omitted. This is either because they are conveyed within the LDAP URL values themselves, and Sermersheim Expires December 30, 2004 [Page 28] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 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 . 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 is not able or allowed to chain, but is configured to return referrals, it will return a referral and include the . The client (after optionally contacting the DSAs in the referral to ensure the entry to be added does not exist) may then decide to force the add operation to be applied by re-sending the Add or ModifyDN request with the ManageDsaIT control. This will effectively cause the DSA to skip the check of remote DSAs and proceed with the operation. 4.12 Using the ManageDsaIT control This control 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. Sermersheim Expires December 30, 2004 [Page 29] Internet-Draft Distributed Procedures for LDAP Operations July 2004 4.13 Mapping a referralURI to an LDAP URI As with any URI specification which is intended to be used as a URI which conveyes 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 | | | | | | accessPoint | | | | | | remoteName | . This must be encoded as a | | | as | | | specified in [RFC2253] | | | | | localReference | LDAP URL localReference | | | extension as specified in | | | Section 4.9.2.2 | | | | | searchScope | or LDAP URL searchScope | | | extension as specified in | | | Section 4.9.2.3 | | | | | searchedSubtrees | LDAP URL searchedSubtrees | | | extension as specified in | | | Section 4.9.2.4 | | | | | failedName | LDAP URL failedName extension | | | as specified in Section 4.9.2.5 | +---------------------------------+---------------------------------+ Table 1 Sermersheim Expires December 30, 2004 [Page 30] Internet-Draft Distributed Procedures for LDAP Operations July 2004 5. Security Considerations 6 Normative References [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. [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. [X680] International International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, July 2002. Sermersheim Expires December 30, 2004 [Page 31] Internet-Draft Distributed Procedures for LDAP Operations July 2004 [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 December 30, 2004 [Page 32] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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.5 searchScope: 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 Sermersheim Expires December 30, 2004 [Page 33] Internet-Draft Distributed Procedures for LDAP Operations July 2004 Person & email address to contact for further information: 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: searchScope 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 Sermersheim Expires December 30, 2004 [Page 34] Internet-Draft Distributed Procedures for LDAP Operations July 2004 Usage: Extension 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): searchScope 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 Sermersheim Expires December 30, 2004 [Page 35] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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): 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 December 30, 2004 [Page 36] Internet-Draft Distributed Procedures for LDAP Operations July 2004 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 (2004). 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 December 30, 2004 [Page 37] --=__Part77572A9C.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part77572A9C.0__=-- From ldapext-bounces@ietf.org Thu Aug 12 13:53:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19132 for ; Thu, 12 Aug 2004 13:53:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJVB-0001vZ-LH; Thu, 12 Aug 2004 13:36:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJQn-0007zF-OZ for ldapext@megatron.ietf.org; Thu, 12 Aug 2004 13:32:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17642 for ; Thu, 12 Aug 2004 13:32:00 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvJVn-0000Ev-Q4 for ldapext@ietf.org; Thu, 12 Aug 2004 13:37:12 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 12 Aug 2004 11:31:29 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 12 Aug 2004 11:31:12 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartEBCBBC70.0__=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartEBCBBC70.0__= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit All, I found a need for this as I was fleshing out work on the distributed op procedures I-D, but I've also had such a search scope requested a number of times in the past (and I believe other vendors have as well). Please review if you have some time (it's very short). Thanks, Jim >>> 8/11/04 1:21:56 PM >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Subordinate Subtree Search Scope for LDAP Author(s) : J. Sermersheim Filename : draft-sermersheim-ldap-subordinate-scope-00.txt Pages : 6 Date : 2004-8-11 The Lightweight Directory Application Protocol (LDAP) specification supports three scope values for the search operation -- namely: baseObject, singleLevel, and wholeSubtree. This document introduces a subordinateSubtree scope which constrains the search scope to all subordinates of the named base object. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-subordinate-scope-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sermersheim-ldap-subordinate-scope-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sermersheim-ldap-subordinate-scope-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --=__PartEBCBBC70.0__= Content-Type: application/octet-stream; name="Part.001" Content-Disposition: attachment; filename="Part.001" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNC04LTExMTUyNjM4Lkkt REBpZXRmLm9yZz4NCg0KRU5DT0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXNlcm1lcnNoZWltLWxkYXAtc3Vib3JkaW5hdGUtc2NvcGUtMDAudHh0DQo= --=__PartEBCBBC70.0__= Content-Type: text/plain; name="draft-sermersheim-ldap-subordinate-scope-00.txt" Content-Disposition: attachment; filename="draft-sermersheim-ldap-subordinate-scope-00.txt" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2004-8-11152638.I-D@ietf.org> --=__PartEBCBBC70.0__= Content-Type: application/octet-stream; name="Part.003" Content-Disposition: attachment; filename="Part.003" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= --=__PartEBCBBC70.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartEBCBBC70.0__=-- From ldapext-bounces@ietf.org Fri Aug 13 14:31:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03582 for ; Fri, 13 Aug 2004 14:31:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvgj6-0004I3-QM; Fri, 13 Aug 2004 14:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvgav-0003Jz-Mh for ldapext@megatron.ietf.org; Fri, 13 Aug 2004 14:16:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02875 for ; Fri, 13 Aug 2004 14:16:00 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvgg8-0003Od-4T for ldapext@ietf.org; Fri, 13 Aug 2004 14:21:25 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7DIFNjw576952 for ; Fri, 13 Aug 2004 14:15:23 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7DIGSrd107512 for ; Fri, 13 Aug 2004 14:16:28 -0400 In-Reply-To: Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Fri, 13 Aug 2004 13:15:20 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5.2|June 01, 2004) at 08/13/2004 01:15:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Before I go on vacation and forget this completely... I have a practical concern with defining a new search scope, as opposed to, say, a "subordinate subtree scope" control: Do existing clients validate the search scope? Or provide a search interface designed in such a way that supporting a new scope would require a new programming interface or similar changes? For example, System.out.println shows the JNDI SearchControls.xxx_SCOPE constants happen to map to the LDAP search scope enumeration, but they could just as easily been different values. >From a server/protocol perspective, I think it is cleaner to define a new scope. But if making use of this feature requires LDAP client changes (possibly from a different vendor than the server), it might be more practical to provide this feature as a control. John McMeeking ldapext-bounces@ietf.org wrote on 08/12/2004 12:31:12 PM: > All, > > I found a need for this as I was fleshing out work on the distributed > op procedures I-D, but I've also had such a search scope requested a > number of times in the past (and I believe other vendors have as well). > > Please review if you have some time (it's very short). > > Thanks, > > Jim > > >>> 8/11/04 1:21:56 PM >>> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Subordinate Subtree Search Scope for LDAP > Author(s) : J. Sermersheim > Filename : > draft-sermersheim-ldap-subordinate-scope-00.txt > Pages : 6 > Date : 2004-8-11 > > The Lightweight Directory Application Protocol (LDAP) specification > supports three scope values for the search operation -- namely: > baseObject, singleLevel, and wholeSubtree. This document > introduces > a subordinateSubtree scope which constrains the search scope to all > subordinates of the named base object. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sermersheim-ldap- > subordinate-scope-00.txt > > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-sermersheim-ldap-subordinate-scope-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-sermersheim-ldap-subordinate-scope-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation > on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > [attachment "Part.001" deleted by John McMeeking/Rochester/IBM] > [attachment "draft-sermersheim-ldap-subordinate-scope-00.txt" > deleted by John McMeeking/Rochester/IBM] [attachment "Part.003" > deleted by John McMeeking/Rochester/IBM] > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Aug 13 16:23:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15573 for ; Fri, 13 Aug 2004 16:23:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BviL6-0008Tq-N4; Fri, 13 Aug 2004 16:07:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvi4w-0007Yz-KU for ldapext@megatron.ietf.org; Fri, 13 Aug 2004 15:51:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10848 for ; Fri, 13 Aug 2004 15:51:04 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BviA9-0005SO-Db for ldapext@ietf.org; Fri, 13 Aug 2004 15:56:31 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 13 Aug 2004 13:50:33 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 13 Aug 2004 13:50:13 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit It's a valid concern. I assume different client SDKs will need to be updated to varying degrees to support a new search scope. Some may just allow an int to pass through, while others will require a new enumerated type (and thus require that the SDK be revised). Something similar may have happened (though likely to a much less degree) when the '+' all operational attributes selection string was introduced. I personally feel that allowing there to be a ripple effect on client SDKs is actually healthy. Client SDKs should be flexible enough to adapt to future extensions regardless of the form of extension. Meaning, I would prefer a world where the protocol may be extended without having to worry about the impact to current client SDK implementations. But if it turns out that there is significant concern about this, I can revise to extending by control rather than extending the search scope. Another alternative is to define the control in addition to the new scope. Jim >>> John McMeeking 8/13/04 12:15:20 PM >>> Before I go on vacation and forget this completely... I have a practical concern with defining a new search scope, as opposed to, say, a "subordinate subtree scope" control: Do existing clients validate the search scope? Or provide a search interface designed in such a way that supporting a new scope would require a new programming interface or similar changes? For example, System.out.println shows the JNDI SearchControls.xxx_SCOPE constants happen to map to the LDAP search scope enumeration, but they could just as easily been different values. >From a server/protocol perspective, I think it is cleaner to define a new scope. But if making use of this feature requires LDAP client changes (possibly from a different vendor than the server), it might be more practical to provide this feature as a control. John McMeeking ldapext-bounces@ietf.org wrote on 08/12/2004 12:31:12 PM: > All, > > I found a need for this as I was fleshing out work on the distributed > op procedures I-D, but I've also had such a search scope requested a > number of times in the past (and I believe other vendors have as well). > > Please review if you have some time (it's very short). > > Thanks, > > Jim > > >>> 8/11/04 1:21:56 PM >>> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Subordinate Subtree Search Scope for LDAP > Author(s) : J. Sermersheim > Filename : > draft-sermersheim-ldap-subordinate-scope-00.txt > Pages : 6 > Date : 2004-8-11 > > The Lightweight Directory Application Protocol (LDAP) specification > supports three scope values for the search operation -- namely: > baseObject, singleLevel, and wholeSubtree. This document > introduces > a subordinateSubtree scope which constrains the search scope to all > subordinates of the named base object. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sermersheim-ldap- > subordinate-scope-00.txt > > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-sermersheim-ldap-subordinate-scope-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-sermersheim-ldap-subordinate-scope-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation > on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > [attachment "Part.001" deleted by John McMeeking/Rochester/IBM] > [attachment "draft-sermersheim-ldap-subordinate-scope-00.txt" > deleted by John McMeeking/Rochester/IBM] [attachment "Part.003" > deleted by John McMeeking/Rochester/IBM] > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Aug 13 17:04:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18062 for ; Fri, 13 Aug 2004 17:04:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvjC1-0006j1-0S; Fri, 13 Aug 2004 17:02:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvj9H-00064J-6X for ldapext@megatron.ietf.org; Fri, 13 Aug 2004 16:59:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17858 for ; Fri, 13 Aug 2004 16:59:36 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvjEW-0007z9-5Q for ldapext@ietf.org; Fri, 13 Aug 2004 17:05:04 -0400 Received: from [127.0.0.1] (pcp04150285pcs.sanarb01.mi.comcast.net[68.41.55.52]) by comcast.net (rwcrmhc13) with ESMTP id <2004081320590701500965gke> (Authid: mcs); Fri, 13 Aug 2004 20:59:07 +0000 Message-ID: <411D2B8D.6000605@pearlcrescent.com> Date: Fri, 13 Aug 2004 16:58:53 -0400 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: jmcmeek@us.ibm.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > It's a valid concern. > > I assume different client SDKs will need to be updated to varying > degrees to support a new search scope. Some may just allow an int to > pass through, while others will require a new enumerated type (and thus > require that the SDK be revised). Something similar may have happened > (though likely to a much less degree) when the '+' all operational > attributes selection string was introduced. I suspect many SDKs will need to be updated to support the new search scope. For example, the Netscape/Mozilla SDKs validate the scope parameter and therefore won't pass a new value through. > I personally feel that allowing there to be a ripple effect on client > SDKs is actually healthy. Client SDKs should be flexible enough to adapt > to future extensions regardless of the form of extension. Meaning, I > would prefer a world where the protocol may be extended without having > to worry about the impact to current client SDK implementations. I agree, within reasonable limitations. A bigger question is: do we need a new protocol feature to be available to people who are using existing/older SDK implementations? To me, this is more of a "how quick will people adopt the feature and be able to use it" concern than a "we are going to break something" concern. But I may be overlooking something. -- Mark Smith LDAP Book Information: http://www.ldapbook.com/ What's Next: http://www.pearlcrescent.com/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Aug 15 02:38:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07762 for ; Sun, 15 Aug 2004 02:38:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwEdL-0004t7-Ow; Sun, 15 Aug 2004 02:36:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwEaY-0004T3-Lx for ldapext@megatron.ietf.org; Sun, 15 Aug 2004 02:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07579 for ; Sun, 15 Aug 2004 02:33:52 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwEg4-0001o2-Ip for ldapext@ietf.org; Sun, 15 Aug 2004 02:39:38 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7F6XgMw025356; Sun, 15 Aug 2004 06:33:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040815072541.04607068@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 15 Aug 2004 07:31:53 +0200 To: Mark Smith From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt In-Reply-To: <411D2B8D.6000605@pearlcrescent.com> References: <411D2B8D.6000605@pearlcrescent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: jmcmeek@us.ibm.com, ldapext@ietf.org, Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 10:58 PM 8/13/2004, Mark Smith wrote: >A bigger question is: do we need a new protocol feature to be available to people who are using existing/older SDK implementations? As long as only those wanting to make use of the new feature need a newer SDK, I have absolutely no problem with protocol extensions which require changes to existing SDKs. Certainly an old client should choke if they were provided an LDAP URL with a subordinate scope (through user input or from the server)... but an old client should also choke in face of an LDAP URL with a critical subordinate control. And, I note, both likely might require SDK enhancements (most SDKs handle LDAP URLs returned by the server directly). To me, the implication is that servers should only return such URLs when the clients specifically request that they be returned. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Aug 16 09:24:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03311 for ; Mon, 16 Aug 2004 09:24:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwhQo-0005Cv-EV; Mon, 16 Aug 2004 09:21:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwhN3-0004ut-Jg for ldapext@megatron.ietf.org; Mon, 16 Aug 2004 09:17:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02978 for ; Mon, 16 Aug 2004 09:17:50 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwhSp-0001BS-Aj for ldapext@ietf.org; Mon, 16 Aug 2004 09:23:52 -0400 Received: from [127.0.0.1] (pcp04150285pcs.sanarb01.mi.comcast.net[68.41.55.52]) by comcast.net (sccrmhc11) with ESMTP id <20040816131719011004kdg2e> (Authid: mcs); Mon, 16 Aug 2004 13:17:20 +0000 Message-ID: <4120B3D5.7080109@pearlcrescent.com> Date: Mon, 16 Aug 2004 09:17:09 -0400 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt References: <411D2B8D.6000605@pearlcrescent.com> <6.1.2.0.0.20040815072541.04607068@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040815072541.04607068@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: jmcmeek@us.ibm.com, ldapext@ietf.org, Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > As long as only those wanting to make use of the new feature > need a newer SDK, I have absolutely no problem with protocol > extensions which require changes to existing SDKs. > > Certainly an old client should choke if they were provided > an LDAP URL with a subordinate scope (through user input > or from the server)... but an old client should also choke > in face of an LDAP URL with a critical subordinate control. > > And, I note, both likely might require SDK enhancements > (most SDKs handle LDAP URLs returned by the server directly). > > To me, the implication is that servers should only return > such URLs when the clients specifically request that they > be returned. I agree of course. In my mind the last sentence above goes without saying. But it does not hurt to say it ;-) -- Mark Smith LDAP Book Information: http://www.ldapbook.com/ What's Next: http://www.pearlcrescent.com/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Aug 17 13:57:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03643 for ; Tue, 17 Aug 2004 13:57:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx8B7-00015p-Go; Tue, 17 Aug 2004 13:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx85p-0000KV-Bx for ldapext@megatron.ietf.org; Tue, 17 Aug 2004 13:49:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03071 for ; Tue, 17 Aug 2004 13:49:51 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx8Bp-0000m4-Er for ldapext@ietf.org; Tue, 17 Aug 2004 13:56:08 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 17 Aug 2004 11:49:18 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 17 Aug 2004 11:49:00 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: jmcmeek@us.ibm.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable So you two are both saying that I need to add a solicitation mechanism = (like a control) so that clients can ask for URIs containing the new = scope? I'd rather not... If a referral is to be returned, the only URIs = available are LDAP URLs that contain the subord scope, the client did not = solicit URIs containing that scope, then the server is stuck * it can't = return a referral. Furthermore, today's server implementations likely don't check stored LDAP = URLs (in 'ref' attributes), for critical extensions and exclude them when = not solicited * thus it seems some precedent exists where unsolicited LDAP = URLs may be sent to clients that cannot be handled. Let me know if you disagree, or if I'm misunderstanding the wording below. Jim >>> Mark Smith 8/16/04 7:17:09 AM >>> Kurt D. Zeilenga wrote: > As long as only those wanting to make use of the new feature > need a newer SDK, I have absolutely no problem with protocol > extensions which require changes to existing SDKs. >=20 > Certainly an old client should choke if they were provided > an LDAP URL with a subordinate scope (through user input > or from the server)... but an old client should also choke > in face of an LDAP URL with a critical subordinate control. >=20 > And, I note, both likely might require SDK enhancements > (most SDKs handle LDAP URLs returned by the server directly). >=20 > To me, the implication is that servers should only return > such URLs when the clients specifically request that they > be returned. I agree of course. In my mind the last sentence above goes without=20 saying. But it does not hurt to say it ;-) --=20 Mark Smith LDAP Book Information: http://www.ldapbook.com/=20 What's Next: http://www.pearlcrescent.com/=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Aug 17 15:06:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08301 for ; Tue, 17 Aug 2004 15:06:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx9Fh-0000Va-72; Tue, 17 Aug 2004 15:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx99N-0003NF-UM for ldapext@megatron.ietf.org; Tue, 17 Aug 2004 14:57:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07242 for ; Tue, 17 Aug 2004 14:57:35 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx9FQ-00024k-Dt for ldapext@ietf.org; Tue, 17 Aug 2004 15:03:53 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 17 Aug 2004 12:57:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 17 Aug 2004 12:56:43 -0600 From: "Jim Sermersheim" To: "Jim Sermersheim" , , Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: jmcmeek@us.ibm.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Maybe the correct thing to do is to add a mechanism which allows clients to solicit the new part, but allow the part to be returned unsolicited. Jim >>> "Jim Sermersheim" 8/17/04 11:49:00 AM >>> So you two are both saying that I need to add a solicitation mechanism (like a control) so that clients can ask for URIs containing the new scope? I'd rather not... If a referral is to be returned, the only URIs available are LDAP URLs that contain the subord scope, the client did not solicit URIs containing that scope, then the server is stuck * it can't return a referral. Furthermore, today's server implementations likely don't check stored LDAP URLs (in 'ref' attributes), for critical extensions and exclude them when not solicited * thus it seems some precedent exists where unsolicited LDAP URLs may be sent to clients that cannot be handled. Let me know if you disagree, or if I'm misunderstanding the wording below. Jim >>> Mark Smith 8/16/04 7:17:09 AM >>> Kurt D. Zeilenga wrote: > As long as only those wanting to make use of the new feature > need a newer SDK, I have absolutely no problem with protocol > extensions which require changes to existing SDKs. > > Certainly an old client should choke if they were provided > an LDAP URL with a subordinate scope (through user input > or from the server)... but an old client should also choke > in face of an LDAP URL with a critical subordinate control. > > And, I note, both likely might require SDK enhancements > (most SDKs handle LDAP URLs returned by the server directly). > > To me, the implication is that servers should only return > such URLs when the clients specifically request that they > be returned. I agree of course. In my mind the last sentence above goes without saying. But it does not hurt to say it ;-) -- Mark Smith LDAP Book Information: http://www.ldapbook.com/ What's Next: http://www.pearlcrescent.com/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Aug 19 16:55:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08341 for ; Thu, 19 Aug 2004 16:55:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxsez-0002PY-OD; Thu, 19 Aug 2004 15:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxsbm-0000sD-JD for ldapext@megatron.ietf.org; Thu, 19 Aug 2004 15:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27731 for ; Thu, 19 Aug 2004 15:29:55 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxsiC-0002xy-FQ for ldapext@ietf.org; Thu, 19 Aug 2004 15:36:39 -0400 Received: from [127.0.0.1] (pcp04150285pcs.sanarb01.mi.comcast.net[68.41.55.52]) by comcast.net (rwcrmhc13) with ESMTP id <2004081919292201500n6dkde> (Authid: mcs); Thu, 19 Aug 2004 19:29:22 +0000 Message-ID: <4124FF8A.10308@pearlcrescent.com> Date: Thu, 19 Aug 2004 15:29:14 -0400 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, jmcmeek@us.ibm.com, Kurt@OpenLDAP.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I am not 100% sure what the right thing to do is, but it seems like it should be OK to return LDAP URLs with new extensions to any client. I would definitely recommend that URLs that contain the new be only returned to clients that ask for them. -Mark Jim Sermersheim wrote: > Maybe the correct thing to do is to add a mechanism which allows clients > to solicit the new part, but allow the part to be > returned unsolicited. > > Jim > > >>>>"Jim Sermersheim" 8/17/04 11:49:00 AM >>> > > So you two are both saying that I need to add a solicitation mechanism > (like a control) so that clients can ask for URIs containing the new > scope? I'd rather not... If a referral is to be returned, the only URIs > available are LDAP URLs that contain the subord scope, the client did > not solicit URIs containing that scope, then the server is stuck * it > can't return a referral. > > Furthermore, today's server implementations likely don't check stored > LDAP URLs (in 'ref' attributes), for critical extensions and exclude > them when not solicited * thus it seems some precedent exists where > unsolicited LDAP URLs may be sent to clients that cannot be handled. > > Let me know if you disagree, or if I'm misunderstanding the wording > below. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Aug 24 04:47:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15163 for ; Tue, 24 Aug 2004 04:47:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzWag-0000RW-Dp; Tue, 24 Aug 2004 04:23:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzWTC-0006eg-IQ for ldapext@megatron.ietf.org; Tue, 24 Aug 2004 04:15:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13340 for ; Tue, 24 Aug 2004 04:15:42 -0400 (EDT) Received: from du-006-006.access.de.clara.net ([212.82.229.6] helo=nb2.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzWT3-0002wU-Iq for ldapext@ietf.org; Tue, 24 Aug 2004 04:16:14 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 6DB97A371F for ; Tue, 24 Aug 2004 09:33:13 +0200 (CEST) Message-ID: <412AEF38.1090302@stroeder.com> Date: Tue, 24 Aug 2004 09:33:12 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ldapext@ietf.org Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt References: <411D2B8D.6000605@pearlcrescent.com> <6.1.2.0.0.20040815072541.04607068@127.0.0.1> In-Reply-To: <6.1.2.0.0.20040815072541.04607068@127.0.0.1> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > > To me, the implication is that servers should only return > such URLs when the clients specifically request that they > be returned. And how should the client specifically request that they are returned? Doesn't this make things more complicated at the client side? IMO it should be subject to server configuration whether to return a new search scope or not. While planning a LDAP service deployment you already have to consider whether all the LDAP clients used behave nicely with this server (configuration). Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Aug 24 07:11:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25376 for ; Tue, 24 Aug 2004 07:11:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzYj9-0006MB-1u; Tue, 24 Aug 2004 06:40:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzYXa-00030z-3Y for ldapext@megatron.ietf.org; Tue, 24 Aug 2004 06:28:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21512 for ; Tue, 24 Aug 2004 06:28:21 -0400 (EDT) Received: from [62.80.45.182] (helo=nb2.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzYXt-0005FF-EP for ldapext@ietf.org; Tue, 24 Aug 2004 06:28:55 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 1B41E92CAB for ; Tue, 24 Aug 2004 12:23:54 +0200 (CEST) Message-ID: <412B1739.7050701@stroeder.com> Date: Tue, 24 Aug 2004 12:23:53 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ldapext@ietf.org Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt References: <411D2B8D.6000605@pearlcrescent.com> In-Reply-To: <411D2B8D.6000605@pearlcrescent.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Mark Smith wrote: > > I suspect many SDKs will need to be updated to support the new search > scope. For example, the Netscape/Mozilla SDKs validate the scope > parameter and therefore won't pass a new value through. That's not an issue since the LDAP client application is more relevant here. If the application does not support the new search scope value it's not an issue that the SDK does not accept the new search scope value. If the application does support it the application programmer simply has to program on top of the updated SDK. > A bigger question is: do we > need a new protocol feature to be available to people who are using > existing/older SDK implementations? IMO no. > To me, this is more of a "how quick > will people adopt the feature and be able to use it" concern than a "we > are going to break something" concern. Looking at my logs many LDAP clients are solely using 'wholeSubtree' as search scope value. Therefore I don't understand this issue. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Aug 24 07:48:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27566 for ; Tue, 24 Aug 2004 07:48:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzZHJ-0003U6-K7; Tue, 24 Aug 2004 07:15:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzZ6D-0000iQ-HZ for ldapext@megatron.ietf.org; Tue, 24 Aug 2004 07:04:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24992 for ; Tue, 24 Aug 2004 07:04:13 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzZ6c-0005sq-KX for ldapext@ietf.org; Tue, 24 Aug 2004 07:04:48 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7OB48Mw095717; Tue, 24 Aug 2004 11:04:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040824130054.04bb6110@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 24 Aug 2004 13:04:49 +0200 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt In-Reply-To: <412AEF38.1090302@stroeder.com> References: <411D2B8D.6000605@pearlcrescent.com> <6.1.2.0.0.20040815072541.04607068@127.0.0.1> <412AEF38.1090302@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 09:33 AM 8/24/2004, Michael Str=F6der wrote: >Kurt D. Zeilenga wrote: >>To me, the implication is that servers should only return >>such URLs when the clients specifically request that they >>be returned. > >And how should the client specifically request that they are returned?=20 I'd use a control... or bind using version=3D4. >Doesn't this make things more complicated at the client side? I rather 'complicate' new clients than break old clients. >IMO it should be subject to server configuration whether to return a new= search scope or not. While planning a LDAP service deployment you already= have to consider whether all the LDAP clients used behave nicely with this= server (configuration). Remember that we (the IETF) design protocols for the Internet, not some local deployment where a single administrator has control of all clients and servers. Kurt=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Aug 26 20:40:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27908 for ; Thu, 26 Aug 2004 20:40:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0UjI-0006fK-Ep; Thu, 26 Aug 2004 20:36:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Uin-0006UQ-5z for ldapext@megatron.ietf.org; Thu, 26 Aug 2004 20:36:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27707 for ; Thu, 26 Aug 2004 20:35:59 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0Ujo-0003em-Ji for ldapext@ietf.org; Thu, 26 Aug 2004 20:37:06 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 26 Aug 2004 18:35:23 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 26 Aug 2004 18:35:06 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Dale Olds , Steve McLain , Tom Doman Subject: [ldapext] DistProc: Kill Name Mapping X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit All, In http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-distproc-00.txt, the notion of "name mapping" is brought out of the woodwork and exposed as a very obvious feature of distributed LDAP directories (via the ContinuationReference.remoteName field). Now that this has happened, I'm receiving pressure to not only make it non-obvious, but to specifically prohibit the ability. Here's the history: RFC2251 referrals (and searchResultReferences) allow for a DN field to convey a name to be used in progressing the operation. This is primarily used when aliases are dereferenced, and for the new base DN for a search sub operation. It also states that the LDAP URL format is used for referrals pointing to LDAP servers, and the LDAP URL specification allows for a DN field. RFC3296 allows for the storage of referral data, and also states that the LDAP URL form is to be used for referrals which identify LDAP servers. Furthermore RFC3296 states that the DN field SHOULD be populated when LDAP URLs are stored as referral information. Neither of these specifications disallow the DN field of a referral from naming a DSE which is different from the reference object that holds the referral. And the problem: Allowing this seems somewhat useful at first (one can glue different namespaces together), but it gets really ugly really fast. For example (view diagrams below in a fixed-pitch font): When DSA1 chains a search request to DSA2, should it transform DN values coming from the chained-to DSA to names that can be later resolved on DSA1? If not, the resulting names are useless to the DUA receiving them from DSA1. Also, look at the case where the OU=Z,OU=Y,O=X group is returned, not only would the entry name need to be transformed (to OU=Z,DC=B,DC=A), but the member value would need to be transformed. But transformed to what? DSA1 holds no reference to any parent of the member value. DSA1 O DC=A / (glue) / O DC=B (referral) ref=ldap://dsa2/OU=Y,O=X DSA2 O O=X / \ / \ O O OU=Q / OU=Y \ / \ O OU=Z O OU=R (group) member=OU=R,OU=Q,OU=X As one attempts to solve these problems (with name mapping tables, auto-insertion of cross references, etc), even more problems arise until it feels like trying to unwind a problem that is fractal in nature. Usually when this happens, one can't help feeling like it was a bad idea to begin with. Thus, there is a request to: a) Remove ContinuationReference.remoteName. b) State that the DN values stored in a referral URI must also name the reference object on which they are held. Otherwise the DN value is ignored for purposes of distributing the operation. What do you all think of these two proposals? Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sat Aug 28 21:00:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22594 for ; Sat, 28 Aug 2004 21:00:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1E0K-0000BE-8I; Sat, 28 Aug 2004 20:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1Dyd-0008Tr-Ck for ldapext@megatron.ietf.org; Sat, 28 Aug 2004 20:55:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22385 for ; Sat, 28 Aug 2004 20:55:21 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1E04-0005Df-Hb for ldapext@ietf.org; Sat, 28 Aug 2004 20:56:54 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i7T0tEMw031330; Sun, 29 Aug 2004 00:55:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040828173534.043d3578@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 28 Aug 2004 17:55:47 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] DistProc: Kill Name Mapping In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Steve McLain , Dale Olds , ldapext@ietf.org, Tom Doman X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 05:35 PM 8/26/2004, Jim Sermersheim wrote: >In >http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-distproc-00.txt, >the notion of "name mapping" is brought out of the woodwork and exposed >as a very obvious feature of distributed LDAP directories (via the >ContinuationReference.remoteName field). Now that this has happened, I'm >receiving pressure to not only make it non-obvious, but to specifically >prohibit the ability. I would concur that the I-D should not discuss "name mapping" as you describe it below. Rewriting of the entry, if a desirable capability, is beyond the scope of distributed directories. This I-D (and associated I-Ds detailing model elements) should avoid discussion of "virtual directory" issues such as how to do "name mapping". I have no problem discussing how to handle various forms of knowledge information described in X.500(93), including cross references. I note that in X.500 handling of such references demands (nor likely allows) "name mapping". Kurt >Here's the history: > >RFC2251 referrals (and searchResultReferences) allow for a DN field to >convey a name to be used in progressing the operation. This is primarily >used when aliases are dereferenced, and for the new base DN for a search >sub operation. It also states that the LDAP URL format is used for >referrals pointing to LDAP servers, and the LDAP URL specification >allows for a DN field. RFC3296 allows for the storage of referral data, >and also states that the LDAP URL form is to be used for referrals which >identify LDAP servers. Furthermore RFC3296 states that the DN field >SHOULD be populated when LDAP URLs are stored as referral information. > >Neither of these specifications disallow the DN field of a referral >from naming a DSE which is different from the reference object that >holds the referral. > >And the problem: > >Allowing this seems somewhat useful at first (one can glue different >namespaces together), but it gets really ugly really fast. For example >(view diagrams below in a fixed-pitch font): When DSA1 chains a search >request to DSA2, should it transform DN values coming from the >chained-to DSA to names that can be later resolved on DSA1? If not, the >resulting names are useless to the DUA receiving them from DSA1. Also, >look at the case where the OU=Z,OU=Y,O=X group is returned, not only >would the entry name need to be transformed (to OU=Z,DC=B,DC=A), but the >member value would need to be transformed. But transformed to what? DSA1 >holds no reference to any parent of the member value. > > DSA1 > O DC=A > / (glue) > / > O DC=B > (referral) > ref=ldap://dsa2/OU=Y,O=X > > DSA2 > O O=X > / \ > / \ > O O OU=Q > / OU=Y \ > / \ >O OU=Z O OU=R > (group) > member=OU=R,OU=Q,OU=X > >As one attempts to solve these problems (with name mapping tables, >auto-insertion of cross references, etc), even more problems arise until >it feels like trying to unwind a problem that is fractal in nature. >Usually when this happens, one can't help feeling like it was a bad idea >to begin with. Thus, there is a request to: > >a) Remove ContinuationReference.remoteName. >b) State that the DN values stored in a referral URI must also name the >reference object on which they are held. Otherwise the DN value is >ignored for purposes of distributing the operation. > >What do you all think of these two proposals? > >Jim > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Aug 30 13:20:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10179 for ; Mon, 30 Aug 2004 13:20:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1phH-0001bX-VV; Mon, 30 Aug 2004 13:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1pYj-0008Sh-Qf for ldapext@megatron.ietf.org; Mon, 30 Aug 2004 13:03:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08773 for ; Mon, 30 Aug 2004 13:03:06 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1paT-0000Cx-FC for ldapext@ietf.org; Mon, 30 Aug 2004 13:05:02 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 30 Aug 2004 11:02:32 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 30 Aug 2004 11:02:02 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] DistProc: Kill Name Mapping Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: Steve McLain , Dale Olds , ldapext@ietf.org, Tom Doman X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Sounds good. I'll remove the ContinuationReference.remoteName doohickey to start with. Then for any DN values appearing in a referralURI, I'll either ignore the possibility of it being used for name mapping, or I'll make warning noises about what might happen if it's used for that purpose (I should note that at least one off-line comment was made which asked that it not be expressly forbidden). Jim >>> "Kurt D. Zeilenga" 8/28/04 6:55:47 PM >>> At 05:35 PM 8/26/2004, Jim Sermersheim wrote: >In >http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-distproc-00.txt, >the notion of "name mapping" is brought out of the woodwork and exposed >as a very obvious feature of distributed LDAP directories (via the >ContinuationReference.remoteName field). Now that this has happened, I'm >receiving pressure to not only make it non-obvious, but to specifically >prohibit the ability. I would concur that the I-D should not discuss "name mapping" as you describe it below. Rewriting of the entry, if a desirable capability, is beyond the scope of distributed directories. This I-D (and associated I-Ds detailing model elements) should avoid discussion of "virtual directory" issues such as how to do "name mapping". I have no problem discussing how to handle various forms of knowledge information described in X.500(93), including cross references. I note that in X.500 handling of such references demands (nor likely allows) "name mapping". Kurt >Here's the history: > >RFC2251 referrals (and searchResultReferences) allow for a DN field to >convey a name to be used in progressing the operation. This is primarily >used when aliases are dereferenced, and for the new base DN for a search >sub operation. It also states that the LDAP URL format is used for >referrals pointing to LDAP servers, and the LDAP URL specification >allows for a DN field. RFC3296 allows for the storage of referral data, >and also states that the LDAP URL form is to be used for referrals which >identify LDAP servers. Furthermore RFC3296 states that the DN field >SHOULD be populated when LDAP URLs are stored as referral information. > >Neither of these specifications disallow the DN field of a referral >from naming a DSE which is different from the reference object that >holds the referral. > >And the problem: > >Allowing this seems somewhat useful at first (one can glue different >namespaces together), but it gets really ugly really fast. For example >(view diagrams below in a fixed-pitch font): When DSA1 chains a search >request to DSA2, should it transform DN values coming from the >chained-to DSA to names that can be later resolved on DSA1? If not, the >resulting names are useless to the DUA receiving them from DSA1. Also, >look at the case where the OU=Z,OU=Y,O=X group is returned, not only >would the entry name need to be transformed (to OU=Z,DC=B,DC=A), but the >member value would need to be transformed. But transformed to what? DSA1 >holds no reference to any parent of the member value. > > DSA1 > O DC=A > / (glue) > / > O DC=B > (referral) > ref=ldap://dsa2/OU=Y,O=X > > DSA2 > O O=X > / \ > / \ > O O OU=Q > / OU=Y \ > / \ >O OU=Z O OU=R > (group) > member=OU=R,OU=Q,OU=X > >As one attempts to solve these problems (with name mapping tables, >auto-insertion of cross references, etc), even more problems arise until >it feels like trying to unwind a problem that is fractal in nature. >Usually when this happens, one can't help feeling like it was a bad idea >to begin with. Thus, there is a request to: > >a) Remove ContinuationReference.remoteName. >b) State that the DN values stored in a referral URI must also name the >reference object on which they are held. Otherwise the DN value is >ignored for purposes of distributing the operation. > >What do you all think of these two proposals? > >Jim > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext