From: Kurt Zeilenga <kurt@openldap.org>
Date: Sat, 12 Feb 2005 16:25:02 +0000 (+0000)
Subject: rev 01
X-Git-Tag: OPENLDAP_REL_ENG_2_3_BP~179
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=d4daf91ef4934d1d05a47a0fb367299495c17275;p=openldap

rev 01
---

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