]> git.sur5r.net Git - openldap/blob - doc/drafts/draft-sermersheim-ldap-distproc-xx.txt
Merge remote-tracking branch 'origin/mdb.master' into OPENLDAP_REL_ENG_2_4
[openldap] / doc / drafts / draft-sermersheim-ldap-distproc-xx.txt
1
2 Network Working Group                                     J. Sermersheim
3 Internet-Draft                                               Novell, Inc
4 Expires: August 26, 2005                               February 22, 2005
5
6
7
8                Distributed Procedures for LDAP Operations
9                  draft-sermersheim-ldap-distproc-02.txt
10
11
12 Status of this Memo
13
14
15    This document is an Internet-Draft and is subject to all provisions
16    of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
17    author represents that any applicable patent or other IPR claims of
18    which he or she is aware have been or will be disclosed, and any of
19    which he or she become aware will be disclosed, in accordance with
20    RFC 3668.
21
22
23    Internet-Drafts are working documents of the Internet Engineering
24    Task Force (IETF), its areas, and its working groups.  Note that
25    other groups may also distribute working documents as
26    Internet-Drafts.
27
28
29    Internet-Drafts are draft documents valid for a maximum of six months
30    and may be updated, replaced, or obsoleted by other documents at any
31    time.  It is inappropriate to use Internet-Drafts as reference
32    material or to cite them other than as "work in progress."
33
34
35    The list of current Internet-Drafts can be accessed at
36    http://www.ietf.org/ietf/1id-abstracts.txt.
37
38
39    The list of Internet-Draft Shadow Directories can be accessed at
40    http://www.ietf.org/shadow.html.
41
42
43    This Internet-Draft will expire on August 26, 2005.
44
45
46 Copyright Notice
47
48
49    Copyright (C) The Internet Society (2005).
50
51
52 Abstract
53
54
55    This document provides the data types and procedures used while
56    servicing Lightweight Directory Access Protocol (LDAP) user
57    operations in order to participate in a distributed directory.  In
58    particular, it describes the way in which an LDAP user operation in a
59    distributed directory environment finds its way to the proper DSA(s)
60    for servicing.
61
62
63
64
65
66 Sermersheim              Expires August 26, 2005                [Page 1]
67 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
68
69
70
71 Discussion Forum
72
73
74    Technical discussion of this document will take place on the IETF
75    LDAP Extensions mailing list <ldapext@ietf.org>.  Please send
76    editorial comments directly to the author.
77
78
79 Table of Contents
80
81
82    1.   Distributed Operations Overview  . . . . . . . . . . . . . .   3
83    2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   4
84    3.   Distributed Operation Data Types . . . . . . . . . . . . . .   5
85    3.1  ContinuationReference  . . . . . . . . . . . . . . . . . . .   5
86    3.2  ChainedRequest . . . . . . . . . . . . . . . . . . . . . . .   9
87    3.3  Chained Response . . . . . . . . . . . . . . . . . . . . . .  11
88    4.   Distributed Procedures . . . . . . . . . . . . . . . . . . .  14
89    4.1  Name resolution  . . . . . . . . . . . . . . . . . . . . . .  14
90    4.2  Operation Evaluation . . . . . . . . . . . . . . . . . . . .  16
91    4.3  Populating the ContinuationReference . . . . . . . . . . . .  19
92    4.4  Sending a ChainedRequest . . . . . . . . . . . . . . . . . .  21
93    4.5  Emulating the Sending of a ChainedRequest  . . . . . . . . .  23
94    4.6  Receiving a ChainedRequest . . . . . . . . . . . . . . . . .  24
95    4.7  Returning a Chained Response . . . . . . . . . . . . . . . .  25
96    4.8  Receiving a Chained Response . . . . . . . . . . . . . . . .  26
97    4.9  Returning a Referral or Intermediate Referral  . . . . . . .  27
98    4.10 Acting on a Referral or Intermediate Referral  . . . . . . .  30
99    4.11 Ensuring non-existence of an entry under an nssr . . . . . .  31
100    4.12 Mapping a referralURI to an LDAP URI . . . . . . . . . . . .  31
101    4.13 Using the ManageDsaIT control  . . . . . . . . . . . . . . .  32
102    5.   Security Considerations  . . . . . . . . . . . . . . . . . .  33
103    6.   Normative References . . . . . . . . . . . . . . . . . . . .  33
104         Author's Address . . . . . . . . . . . . . . . . . . . . . .  34
105    A.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  35
106    A.1  LDAP Object Identifier Registrations . . . . . . . . . . . .  35
107    A.2  LDAP Protocol Mechanism Registrations  . . . . . . . . . . .  35
108    A.3  LDAP Descriptor Registrations  . . . . . . . . . . . . . . .  37
109    A.4  LDAP Result Code Registrations . . . . . . . . . . . . . . .  38
110         Intellectual Property and Copyright Statements . . . . . . .  39
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126 Sermersheim              Expires August 26, 2005                [Page 2]
127 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
128
129
130
131 1.  Distributed Operations Overview
132
133
134    One characteristic of X.500-based directory systems [X500] is that,
135    given a distributed Directory Information Tree (DIT), a user should
136    potentially be able to have any service request satisfied (subject to
137    security, access control, and administrative policies) irrespective
138    of the Directory Service Agent (DSA) to which the request was sent.
139    To accommodate this requirement, it is necessary that any DSA
140    involved in satisfying a particular service request have some
141    knowledge (as specified in {TODO: Link to future Distributed Data
142    Model doc}) of where the requested information is located and either
143    return this knowledge to the requester or attempt to satisfy the
144    request satisfied on the behalf of the requester (the requester may
145    either be a Directory User Agent (DUA) or another DSA).
146
147
148    Two modes of operation distribution are defined to meet these
149    requirements, namely "chaining" and "returning referrals".
150    "Chaining" refers to the attempt by a DSA to satisfy a request by
151    sending one or more chained operations to other DSAs.  "Returning
152    referrals", is the act of returning distributed knowledge information
153    to the requester, which may then itself interact with the DSA(s)
154    identified by the distributed knowledge information.  It is a goal of
155    this document to provide the same level of service whether the
156    chaining or referral mechanism is used to distribute an operation.
157
158
159    The processing of an operation is talked about in two major phases,
160    namely "name resolution", and "operation evaluation".  Name
161    resolution is the act of locating a local DSE held on a DSA given a
162    distinguished name (DN).  Operation evaluation is the act of
163    performing the operation after the name resolution phase is complete.
164
165
166    While distributing an operation, a request operation may be
167    decomposed into several sub-operations.
168
169
170    The distributed directory operation procedures described in this
171    document assume the absense of the ManageDsaIT control defined in
172    [RFC3296] and described in Section 4.13.
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188 Sermersheim              Expires August 26, 2005                [Page 3]
189 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
190
191
192
193 2.  Conventions
194
195
196    Imperative keywords defined in [RFC2119] are used in this document,
197    and carry the meanings described there.
198
199
200    All Basic Encoding Rules (BER) [X690] encodings follow the
201    conventions found in Section 5.1 of [RFC2251].
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247 Sermersheim              Expires August 26, 2005                [Page 4]
248 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
249
250
251
252 3.  Distributed Operation Data Types
253
254
255    The data types in this section are used by the chaining and referral
256    distributed operation mechanisms described in Section 4
257
258
259 3.1  ContinuationReference
260
261
262    As an operation is being processed by a DSA, it is useful to group
263    the information passed between various procedures as a collection of
264    data.  The ContinuationReference data type is introduced for this
265    purpose.  This data type is populated and consumed by various
266    procedures discussed in various sections of this document.  In
267    general, a ContinuationReference is used when indicating that
268    directory information being acted on is not present locally, but may
269    be present elsewhere.
270
271
272    A ContinuationReference consists of one or more addresses which
273    identify remote DSAs along with other information pertaining both to
274    the distributed knowledge information held on the local DSA as well
275    as information relevant to the operation.  This data type is
276    expressed here in Abstract Syntax Notation One (ASN.1) [X680].
277
278
279       ContinuationReference ::= SET {
280          referralURI      [0] SET SIZE (1..MAX) OF URI,
281          localReference   [2] LDAPDN,
282          referenceType    [3] ReferenceType,
283          remainingName    [4] RelativeLDAPDN OPTIONAL,
284          searchScope      [5] SearchScope OPTIONAL,
285          searchedSubtrees [6] SearchedSubtrees OPTIONAL,
286          failedName       [7] LDAPDN OPTIONAL,
287          ...  }
288
289
290    <Editor's Note: Planned for addition is a searchCriteria field which
291    is used both for assuring that the remote object is in fact the
292    object originally pointed to (this mechanism provides a security
293    measure), and also to allow moved or renamed remote entries to be
294    found.  Typically the search criteria would have a filter value of
295    (entryUUID=<something>)>
296
297
298    URI ::= LDAPString     -- limited to characters permitted in URIs
299    [RFC2396].
300
301
302       ReferenceType ::= ENUMERATED {
303          superior               (0),
304          subordinate            (1),
305          cross                  (2),
306          nonSpecificSubordinate (3),
307
308
309
310
311
312 Sermersheim              Expires August 26, 2005                [Page 5]
313 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
314
315
316
317          suplier                (4),
318          master                 (5),
319          immediateSuperior      (6),
320          self                   (7),
321          ...  }
322       SearchScope ::= ENUMERATED {
323          baseObject         (0),
324          singleLevel        (1),
325          wholeSubtree       (2),
326          subordinateSubtree (3),
327          ...  }
328
329
330    SearchedSubtrees ::= SET OF RelativeLDAPDN
331
332
333    LDAPDN, RelativeLDAPDN, and LDAPString, are defined in [RFC2251].
334
335
336    The following subsections introduce the fields of the
337    ContinuationReference data type, but do not provide in-depth
338    semantics or instructions on the population and consumption of the
339    fields.  These topics are discussed as part of the procedural
340    instructions.
341
342
343 3.1.1  ContinuationReference.referralURI
344
345
346    The list of referralURI values is used by the receiver to progress
347    the operation.  Each value specifies (at minimum) the protocol and
348    address of one or more remote DSA(s) holding the data sought after.
349    URI values which are placed in ContinuationReference.referralURI must
350    allow for certain elements of data to be conveyed.  Section 3.1.1.1
351    describes these data elements.  Furthermore, a mapping must exist
352    which relates the parts of a specified URI to these data elements.
353    This document provides such a mapping for the LDAP URL [RFC2255] in
354    Section 4.12.
355
356
357    In some cases, a referralURI will contain data which has a
358    counterpart in the fields of the ContinuationReference (an example is
359    where the referralURI is an LDAP URL, holds a <scope> value, and the
360    ContinuationReference.searchScope field is also present).  In these
361    cases, the data held on the referralURI overrides the field in the
362    ContinuationReference.  Specific examples of this are highlighted in
363    other sections.  Providing a means for these values to exist as
364    fields of the ContinuationReference allows one value to be applied to
365    all values of referralURI (as opposed to populating duplicate data on
366    all referralURI values).
367
368
369    If a referralURI value identifies an LDAP-enabled DSA [RFC3377], the
370    LDAP URL form is used.
371
372
373
374
375
376 Sermersheim              Expires August 26, 2005                [Page 6]
377 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
378
379
380
381 3.1.1.1  Elements of referralURI Values
382
383
384    The following data elements must be allowed and identified for a
385    specified URI type to be used to convey referral information.  Each
386    element is given a name which begins with 'referralURI.' for clarity
387    when referencing the elements conceptually in other parts of this
388    document.
389
390
391    o  referralURI.protocolIdentifier.  There must be an indication of
392       the protocol to be used to contact the DSA identified by the URI.
393    o  referralURI.accessPoint.  The URI must identify a DSA in a manner
394       that can be used to contact it using the protocol specified in
395       protocolIdentifier.
396    o  referralURI.targetObject.  Holds the name to be used as the base
397       DN of the operation being progressed.  This field must be allowed
398       by the URI specification, but may be omitted in URI instances for
399       various reasons.
400    o  referralURI.localReference.  See Section 3.1.2.  This field must
401       be allowed by the URI specification, but may be omitted in URI
402       instances for various reasons.
403    o  referralURI.searchScope.  See Section 3.1.5.  This field must be
404       allowed by the URI specification, but may be omitted in URI
405       instances for various reasons.
406    o  referralURI.searchedSubtrees.  See Section 3.1.6.  This field must
407       be allowed by the URI specification, but may be omitted in URI
408       instances for various reasons.
409    o  referralURI.failedName.  See Section 3.1.7.  This field must be
410       allowed by the URI specification, but may be omitted in URI
411       instances for various reasons.
412
413
414 3.1.2  ContinuationReference.localReference
415
416
417    This names the DSE which was found to hold distributed knowledge
418    information, and thus which caused the ContinuationReference to be
419    formed.  This field is primarily used to help convey the new target
420    object name, but may also be used for purposes referential integrity
421    (not discussed here).  In the event that the root object holds the
422    distributed knowledge information, this field is present and is
423    populated with an empty DN.
424
425
426 3.1.3  ContinuationReference.referenceType
427
428
429    Indicates the DSE Type of the ContinuationReference.localReference.
430    This field may be used to determine how to progress an operations
431    (i.e.  if the value is nonSpecificSubordinate, a search continuation
432    will exclude the ContinuationReference.referenceType).
433
434
435
436
437
438
439 Sermersheim              Expires August 26, 2005                [Page 7]
440 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
441
442
443
444 3.1.4  ContinuationReference.remainingName
445
446
447    In certain scenarios, the localReference does not completely name the
448    DSE to be used as the new target object name.  In these cases,
449    remainingName is populated with the RDNSequence relative to the
450    localReference of the target object name being resolved.  Some
451    examples of these scenarios include (but are not restricted to):
452
453
454    o  During name resolution, the name is not fully resolved, but a DSE
455       holding distributed knowledge information is found, causing a
456       ContinuationReference to be generated.
457    o  While searching, an alias is dereferenced.  The aliasedObjectName
458       points to a DSE of type glue which is subordinate to a DSE holding
459       distributed knowledge information.
460
461
462 3.1.5  ContinuationReference.searchScope
463
464
465    Under certain circumstances, when progressing a search operation, a
466    search scope different than that of the original search request must
467    be used.  This field facilitates the conveyance of the proper search
468    scope to be used when progressing the distributed operation.
469
470
471    The scope of subordinateSubtree has been added to the values allowed
472    by the LDAP SearchRequest.scope field.  This scope includes the
473    subtree of entries below the base DN, but does not include the base
474    DN itself.  This is used here when progressing distributed search
475    operations caused by the existence of a DSE of type nssr.
476
477
478    If a referralURI.searchScope is present, it overrides this field
479    while that referralURI is being operated upon.
480
481
482 3.1.6  ContinuationReference.searchedSubtrees
483
484
485    For ContinuationReferences generated while processing a search
486    operation with a scope of wholeSubtree, each value of this field
487    indicates that a particular subtree below the target object has
488    already been searched.  Consumers of this data use it to cause the
489    progression of the search operation to exclude these subtrees as a
490    mechanism to avoid receiving duplicate entries.
491
492
493    If a referralURI.searchedSubtrees is present, it overrides this field
494    while that referralURI is being operated upon.
495
496
497 3.1.7  ContinuationReference.failedName
498
499
500    When an operation requires that multiple names be resolved (as is the
501    case with the ModifyDN operation), this field is used to specify
502    which name was found to be non-local.
503
504
505
506
507 Sermersheim              Expires August 26, 2005                [Page 8]
508 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
509
510
511
512    If a referralURI.failedName is present, it overrides this field while
513    that referralURI is being operated upon.
514
515
516 3.2  ChainedRequest
517
518
519    The Chained Request is sent as an LDAP extended operation.  The
520    requestName is IANA-ASSIGNED-OID.1.  The requestValue is the BER
521    encoding of the following ChainedRequestValue ASN.1 definition:
522
523
524       ChainedRequestValue ::= SEQUENCE {
525
526
527          chainingArguments ChainingArguments,
528          operationRequest  OperationRequest }
529
530
531       ChainingArguments ::= SEQUENCE {
532
533
534          targetObject     [0] LDAPDN OPTIONAL,
535          referenceType    [1] ReferenceType,
536          traceInformation [2] ChainingTraceInformation,
537          searchScope      [3] SearchScope OPTIONAL,
538          searchedSubtrees [4] SearchedSubtrees OPTIONAL}
539
540
541       ChainingTraceInformation ::= SET OF LDAPURL
542
543
544       OperationRequest ::= SEQUENCE {
545
546
547          Request ::= CHOICE {
548
549
550             bindRequest    BindRequest,
551             searchRequest  SearchRequest,
552             modifyRequest  ModifyRequest,
553             addRequest     AddRequest,
554             delRequest     DelRequest,
555             modDNRequest   ModifyDNRequest,
556             compareRequest CompareRequest,
557             extendedReq    ExtendedRequest,
558             ...  },
559          controls       [0] Controls COPTIONAL }
560
561
562    BindRequest, SearchRequest, ModifyRequest, AddRequest, DelRequest,
563    ModifyDNRequest, CompareRequest, ExtendedRequest and Controls are
564    defined in [RFC2251].
565
566
567 3.2.1  ChainedRequestValue.chainingArguments
568
569
570    In general, these fields assist in refining the original operation as
571    it is to be executed on the receiving DSA.
572
573
574
575
576
577 Sermersheim              Expires August 26, 2005                [Page 9]
578 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
579
580
581
582 3.2.1.1  ChainedRequestValue.chainingArguments.targetObject
583
584
585    This field contains the new target (or base) DN for the operation.
586
587
588    The sending DSA populates this under different scenarios including
589    the case where an alias has been dereferenced while resolving the DN,
590    and also the case where a referral carries a target name different
591    from the reference object that caused the referral.
592
593
594    This field can be omitted only if it would be the the same value as
595    the object or base object parameter in the
596    ChainedRequestValue.operationRequest, in which case its implied value
597    is that value.
598
599
600    The receiving DSA examines this field and (if present) uses it rather
601    than the base DN held in the ChainedRequestValue.operationRequest.
602
603
604 3.2.1.2  ChainedRequestValue.chainingArguments.referenceType
605
606
607    See Section 3.1.3.
608
609
610    If the receiver encounters a value of nonSpecificSubordinate in this
611    field, it indicates that the operation is being chained due to DSE of
612    type nssr.  In this case, the receiver allows (and expects) the base
613    DN to name the immediate superior of a context prefix.
614
615
616 3.2.1.3  ChainedRequestValue.chainingArguments.traceInformation
617
618
619    This contains a set of URIs.  Each value represents the address of a
620    DSA and DN that has already been contacted while attempting to
621    service the operation.  This field is used to detect looping while
622    servicing a distributed operation.
623
624
625    The sending DSA populates this with its own URI, and also the URIs of
626    any DSAs that have already been chained to.  The receiving DSA
627    examines this list of URIs and returns a loopDetect error if it finds
628    that any of the addresses and DNs in the listed URI's represent it's
629    own.
630
631
632 3.2.1.4  ChainedRequestValue.chainingArguments.searchScope
633
634
635    See Section 3.1.5.
636
637
638 3.2.1.5  ChainedRequestValue.chainingArguments.searchedSubtrees
639
640
641    See Section 3.1.6.
642
643
644
645
646
647
648 Sermersheim              Expires August 26, 2005               [Page 10]
649 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
650
651
652
653 3.2.2  ChainedRequestValue.operationRequest
654
655
656    This holds the original LDAP operation request.  This is restricted
657    to a subset of all LDAP operations.  Namely, the following LDAP
658    operation types are not allowed:
659
660
661    o  Abandon/Cancel operations.  When an abandon or cancel operation
662       needs to be chained, it is sent to the remote DSA as-is.  This is
663       because there is no need to track it for loop detection or pass on
664       any other information normally found in ChainingArguments.
665    o  Unbind.  Again, there is no need to send chaining-related
666       information to a DSA to perform an unbind.  DSAs which chain
667       operations maintain connections as they see fit.
668    o  Chained Operation.  When a DSA receives a chained operation, and
669       must again chain that operation to a remote DSA, it sends a
670       ChainedRequest where the ChainedRequestValue.operationRequest is
671       that of the incoming ChainedRequestValue.operationRequest.
672
673
674 3.3  Chained Response
675
676
677    The Chained Response is sent as an LDAP IntermediateResponse
678    [RFC3771], or LDAP ExtendedResponse [RFC2251], depending on whether
679    the operation is complete or not.  In either case, the responseName
680    is omitted.  For intermediate responses, the
681    IntermediateResponse.responseValue is the BER encoding of the
682    ChainedIntermediateResponseValue ASN.1 definition.  For completed
683    operations, the ExtendedResponse.value is the BER encoding of the
684    ChainedFinalResponseValue ASN.1 definition.
685
686
687       ChainedIntermediateResponseValue ::= SEQUENCE {
688
689
690          chainedResults    ChainingResults,
691          operationResponse IntermediateResponse }
692
693
694       ChainedFinalResponseValue ::= SEQUENCE {
695
696
697          chainedResults    ChainingResults,
698          operationResponse FinalResponse }
699
700
701       ChainingResults ::= SEQUENCE {
702
703
704          searchedSubtrees [0] SearchedSubtrees OPTIONAL,
705          ...  }
706
707
708       IntermediateResponse ::= SEQUENCE {
709
710
711          Response ::= CHOICE {
712
713
714
715
716
717 Sermersheim              Expires August 26, 2005               [Page 11]
718 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
719
720
721
722
723             searchResEntry       SearchResultEntry,
724             searchResRef         SearchResultReference,
725             intermediateResponse IntermediateResponse
726             ...  },
727          controls [0] Controls COPTIONAL }
728
729
730       FinalResponse ::= SEQUENCE {
731
732
733          Response ::= CHOICE {
734
735
736             bindResponse    BindResponse,
737             searchResDone   SearchResultDone,
738             modifyResponse  ModifyResponse,
739             addResponse     AddResponse,
740             delResponse     DelResponse,
741             modDNResponse   ModifyDNResponse,
742             compareResponse CompareResponse,
743             extendedResp    ExtendedResponse,
744             ...  },
745          controls [0] Controls COPTIONAL }
746
747
748    BindResponse, SearchResultEntry, SearchResultDone,
749    SearchResultReference, ModifyResponse, AddResponse, DelResponse,
750    ModifyDNResponse, CompareResponse, ExtendedResponse, and Controls are
751    defined in [RFC2251].  IntermediateResponse is defined in [RFC3771].
752
753
754 3.3.1  ChainingResults
755
756
757    In general, this is used to convey additional information that may
758    needed in the event that the operation needs to be progressed
759    further.
760
761
762 3.3.1.1  ChainingResults.searchedSubtrees
763
764
765    Each value of this field indicates that a particular subtree below
766    the target object has already been searched.  This is particularly
767    useful while chaining search operations during operation evaluation
768    caused by the presence of a DSA of type nssr.  Each DSA referenced by
769    the nssr holds one or more naming contexts subordinate to the nssr
770    DSE.  The ChainingResults.searchedSubtrees field allows the DSA being
771    chained to, to inform the sending DSA which subordinate naming
772    contexts have been searched.  This information may be passed to
773    further DSAs listed on the nssr in order to reduce the possibility of
774    duplicate entries being returned.
775
776
777
778
779
780
781
782 Sermersheim              Expires August 26, 2005               [Page 12]
783 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
784
785
786
787 3.3.2  ChainedIntermediateResponseValue.intermediateResponse and
788       ChainedFinalResponseValue.finalResponse
789
790
791    This holds the directory operation response message tied to the
792    ChainedRequestValue.operationRequest.
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840 Sermersheim              Expires August 26, 2005               [Page 13]
841 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
842
843
844
845 4.  Distributed Procedures
846
847
848    For the purposes of describing a distributed operation, operations
849    are said to consist of two major phases -- name resolution and
850    operation evaluation.  These terms are adopted from [X518].  Name
851    resolution is the act of locating a DSE said to be held locally by a
852    DSA given a distinguished name (DN).  Operation evaluation is the act
853    of performing the operation after the name resolution phase is
854    complete.
855
856
857    Furthermore, there are two modes of distributing an operation --
858    chaining, and returning referrals.  Chaining is the act of forwarding
859    an unfinished operation to another DSA for completion (this may
860    happen during name resolution or operation evaluation).  In this
861    case, the forwarding DSA sends a chained operation to a receiving
862    DSA, which attempts to complete the operation.  Alternately, the DSA
863    may return a referral (or intermediate referral), and the client may
864    use that referral in order to forward the unfinished operation to
865    another DSA.  Whether the operation is distributed via chaining or
866    referrals is a decision left to the DSA and or DUA.
867
868
869    The term 'intermediate referral' describes a referral returned during
870    the operation evaluation phase of an operation.  These include
871    searchResultReferences, referrals returned with an
872    intermediateResponse [RFC3771], or future referrals which indicate
873    that they are intermediate referrals.
874
875
876    An operation which is distributed while in the operation evaluation
877    phase is termed a 'sub-operation'.
878
879
880    This document inserts a step between the two distributed operation
881    phases in order to commonize the data and processes followed prior to
882    chaining an operation or returning a referral.  This step consists of
883    populating a ContinuationReference data type.
884
885
886 4.1  Name resolution
887
888
889    Before evaluating (enacting) most directory operations, the DSE named
890    by the target (often called the base DN) of the operation must be
891    located .  This is done by evaluating the RDNs of the target DN one
892    at a time, starting at the rootmost RDN.  Each RDN is compared to the
893    DSEs held by the DSA until the set of RDNs is exhausted, or an RDN
894    cannot be found.
895
896
897    If the DSE named by the target is found to be local, the name
898    resolution phase of the operation completes and the operation
899    evaluation phase begins.
900
901
902
903
904
905 Sermersheim              Expires August 26, 2005               [Page 14]
906 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
907
908
909
910    If it is found that the target does not name a local DSE nor a DSE
911    that may held by another DSA, it is said that the target does not
912    exist, and the operation fails with noSuchObject (subject to local
913    policy).
914
915
916    If it is found that the DSE named by the target is non-local to the
917    DSA, but may reside elsewhere, name resolution is said to be
918    incomplete.  In this case, the operation may be distributed by
919    creating a ContinuationReference (Section 4.3) and either chaining
920    the operation (Section 4.4 and Section 4.5)or returning a referral
921    (Section 4.9).
922
923
924 4.1.1  Determining that a named DSE is local to a DSA
925
926
927    If a DSE held by a DSA falls within a naming context held by the DSA,
928    or is the root DSE on a first-level DSA, it is said to be local to
929    that DSA
930
931
932 4.1.2  Determining that a named DSE does not exist
933
934
935    A named DSE is said to not exist if, during name resolution the DSE
936    is not found, but if found it would fall within a naming context held
937    by the DSA.
938
939
940 4.1.3  Determining that a named DSE is non-local
941
942
943    If a named DSE is niether found to be local to the DSA, nor found to
944    not exist, it is said to be non-local to a DSA.  In this case, it is
945    indeterminate whether the named DSE exists.
946
947
948    When a named DSE is found to be non-local, there should be
949    distributed knowledge information available to be used to either
950    return a referral or chain the operation.
951
952
953 4.1.3.1  Locating distributed knowledge information for a non-local
954         target
955
956
957    If it has been determined that a target names a non-local DSE,
958    distributed knowledge information may be found by first examining the
959    DSE named by the target, and subsequently all superior DSEs beginning
960    with the immediate superior and ending with the root, until an
961    examined DSE is one of types:
962
963
964    {TODO: should DSE types be all caps? It would be easier to read.}
965    o  subr
966    o  supr
967    o  immsupr
968
969
970
971
972
973 Sermersheim              Expires August 26, 2005               [Page 15]
974 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
975
976
977
978    o  xr
979    o  nssr
980
981
982    The examined DSE which is of one of these types holds the distributed
983    knowledge information for the non-local named target.  This DSE is
984    said to be the found distributed knowledge information of the
985    non-local target.  This found distributed knowledge information may
986    then be used to distribute the operation.
987
988
989    If no examined DSEs are of any of these types, the distributed
990    knowledge information is mis-configured, and the error
991    invalidReference is returned.
992
993
994 4.1.4  Special case for the Add operation
995
996
997    During the name resolution phase of the Add operation, the immediate
998    parent of the base DN is resolved.
999
1000
1001    If the immediate parent of the entry to be added is a DSE of type
1002    nssr, then further interrogation is needed to ensure that the entry
1003    to be added does not exist.  Methods for doing this are found in
1004    Section 4.11.  {TODO: don't make this mandatory.  Also, it doesn't
1005    work without transaction semantics.  Same prob in the mod dn below.}.
1006
1007
1008 4.1.5  Special case for the ModifyDN operation
1009
1010
1011    When the modifyDN operation includes a newSuperior name, it must be
1012    resolved as well as the base DN being modified.  If either of these
1013    result in a non-local name, the name causing the operation to be
1014    distributed should be conveyed (Section 4.3.5).  {TODO: also mention
1015    access control problems, and mention (impl detail) that
1016    affectsmultidsa can be used.}
1017
1018
1019    If during operation evaluation of a ModifyDN operation, the
1020    newSuperior names a DSE type of nssr, then further interrogation is
1021    needed to ensure that the entry to be added does not exist.  Methods
1022    for doing this are found in Section 4.11.
1023
1024
1025 4.2  Operation Evaluation
1026
1027
1028    Once name resolution has completed.  The DSE named in the target has
1029    been found to be local to a DSA.  At this point the operation can be
1030    carried out.  During operation evaluation distributed knowledge
1031    information may be found that may cause the DSA to distribute the
1032    operation.  When this happens, the operation may be distributed by
1033    creating a ContinuationReference (Section 4.3) and either chaining
1034    the operation (Section 4.4 and Section 4.5)or returning a referral
1035    (Section 4.9).
1036
1037
1038
1039
1040 Sermersheim              Expires August 26, 2005               [Page 16]
1041 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1042
1043
1044
1045    If, during the location of the distributed knowledge information, the
1046    distributed knowledge information is found to be mis-configured,
1047    operation semantics are followed (some operations may call for an
1048    error to be returned, while others call for the error to be ignored).
1049    {TODO: either make this more specific, or less specific, or just toss
1050    it out.}
1051
1052
1053 4.2.1  Search operation
1054
1055
1056    During operation evaluation of a search operation, the DSA must
1057    determine whether there is distributed knowledge information in the
1058    scope of the search.  Any DSE in the search scope which is of the
1059    following types is considered to be 'found distributed knowledge
1060    information' {TODO: use a better term than found distributed
1061    knowledge information} in the search scope:
1062
1063
1064    o  subr
1065    o  nssr (see nssr note)
1066    o  xr {TODO: I think xr only qualifies when an alias is dereferenced
1067       to an xr.  Otherwisw, there should always be a subr above the xr
1068       if it falls in the search scope.}
1069
1070
1071    Note that due to alias dereferencing, the search scope may expand to
1072    include entries outside of the scope originally specified in the
1073    search operation.  {TODO: note that an aliased object may be glue
1074    which needs to result in any subr or xr above it to be found}
1075
1076
1077    Nssr Note: A DSE of type nssr is only considered to be found
1078    distributed knowledge information when the scope of the search
1079    includes entries below it.  For example, when the search scope is
1080    wholeSubtree or subordinateSubtree and a DSE of type nssr is found in
1081    the scope, or if the search scope is singleLevel and the target
1082    object names a DSE of type nsssr.
1083
1084
1085    {TODO: The following sections are talking about how the continuation
1086    reference is to be populated.  Move to next secion.  Can probably
1087    just say that whole subtree or subordinare subtree encountering nssr,
1088    and single level rooted at nssr result in a continuation reference.
1089    base at, and single level above do not result in a continuation
1090    reference.}
1091
1092
1093 4.2.1.1  Search operation with singleLevel scope
1094
1095
1096    If distributed knowledge information is found during operation
1097    evaluation of a search with a singleLevel scope, it will cause the
1098    resulting ContinuationReference.searchScope to be set to baseObject.
1099
1100
1101
1102
1103
1104
1105 Sermersheim              Expires August 26, 2005               [Page 17]
1106 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1107
1108
1109
1110 4.2.1.2  Search operation encountering nssr knowledge reference
1111
1112
1113    When a search operation encounters distributed knowledge information
1114    which is a DSE type of nssr during operation evaluation, the
1115    following instructions are followed:
1116
1117
1118    Note that when a search operation is being progressed due to nssr
1119    knowledge information, the subsequent distributed progression of the
1120    search is caused to be applied to each DSA listed as non-specific
1121    knowledge information (This is talked about in Section 4.3.2).  In
1122    the event that multiple DSAs listed in the knowledge information hold
1123    copies of the same directory entries, the 'already searched' and
1124    'duplicate elimination' mechanisms SHOULD be used to prevent
1125    duplicate search result entries from ultimately being returned.
1126
1127
1128 4.2.1.2.1  wholeSubtree search scope
1129
1130
1131    When the search scope is wholeSubtree, the
1132    ContinuationReference.searchScope is set to subordinateSubtree.
1133    Because the ContinuationReference.referrenceType is set to
1134    nonSpecificSubordinate, the receiving protocol peer allows (and
1135    expects) name resolution to stop at an immsupr DSE type which is
1136    treated as a local DSE.  The subordinateSubtree scope instructs the
1137    receiving protocol peer to exclude the target object from the
1138    sub-search.
1139
1140
1141 4.2.1.2.2  singleLevel search scope
1142
1143
1144    When the search scope is singleLevel, and the base DN is resolved to
1145    a DSE of type nssr, subsequent distributed progressions of the search
1146    are caused to use the same base DN, and a scope of singleLevel.
1147    Receiving protocol peers will only apply the search to entries below
1148    the target object.
1149
1150
1151    When the search scope is singleLevel and an evaluated DSE is of type
1152    nssr, no special handling is required.  The search is applied to that
1153    DSE if it is of type entry.
1154
1155
1156 4.2.1.2.3  baseObject search scope
1157
1158
1159    No special handling is needed when the search scope is baseObject and
1160    the base DN is an nssr DSEType.  The search is applied to that DSE if
1161    it is of type entry.
1162
1163
1164 4.2.1.3  Search operation rooted at an nssr DSE type
1165
1166
1167    (TODO: a subordinateSubtree scope needs to change to wholeSubtree if
1168    references are found.)
1169
1170
1171
1172
1173 Sermersheim              Expires August 26, 2005               [Page 18]
1174 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1175
1176
1177
1178 4.3  Populating the ContinuationReference
1179
1180
1181    When an entry is found to be non-local to a DSA (whether during name
1182    resolution or operation evaluation), the DSA prepares for operation
1183    distribution by generating a ContinuationReference.  This is a
1184    conceptual step, given to help explain the interactions that occur
1185    between discovering that an operation must be distributing, and
1186    actually invoking the operation distribution mechanism.
1187    Implementations are not required to perform this step, but will
1188    effectively work with the same information.
1189
1190
1191    After the ContinuationReference has been created, the DSA may choose
1192    to chain the operation or return a referral (or intermediate
1193    referral(s)).
1194
1195
1196    the ContinuationReference is made up of data held on the found
1197    distributed knowledge information, as well as state information
1198    gained during name resolution or operation evaluation.
1199
1200
1201 4.3.1  Conveying the Target Object
1202
1203
1204    The consumer of the ContinuationReference will examine various fields
1205    in order to determine the target object name of the operation being
1206    progressed.  The fields examined are the localReference and
1207    remainingName.
1208
1209
1210    If name resolution did not complete, and the found distributed
1211    knowledge information names the same DSE as the base DN of the
1212    operation, the ContinuationReference MAY omit the localReference
1213    and/or remainingName fields.
1214
1215
1216    localReference is populated with the name of the found distributed
1217    knowledge information DSE.  In the event that the root object holds
1218    the distributed knowledge information, this field will be populated
1219    with an empty DN.  Contrast this with the omission of this field.
1220
1221
1222    referenceType is populated with a value reflecting the reference type
1223    of the localReference DSE.
1224
1225
1226    remainingName is populated with the RDNSequence which has not yet
1227    been resolved.  This is the difference between the localReference
1228    value and the name of the DSE to be resolved.
1229
1230
1231    In cases where the DSE named by the {TODO, use a dash or different
1232    term to make 'found distributed knowledge' more like a single term}
1233    found distributed knowledge is not the same as the base DN of the
1234    operation, the ContinuationReference must contain the localReference
1235    and/or remainingName fields.  Such cases include but are not limited
1236
1237
1238
1239
1240 Sermersheim              Expires August 26, 2005               [Page 19]
1241 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1242
1243
1244
1245    to:
1246
1247
1248    o  Distributed knowledge information is found during operation
1249       evaluation.
1250    o  Aliases were dereferenced during name resolution.
1251    o  Name resolution did not complete and there were remaining RDNs to
1252       be resolved.
1253
1254
1255 4.3.2  Conveying the Remote DSA
1256
1257
1258    The referralURI field must contain at least one value.  Each
1259    referralURI value must hold a referralURI.accessPoint.  Other
1260    requirements on this field as noted may also apply.
1261
1262
1263    Note for nssr DSE types: During operation evaluation, if a DSE of
1264    type nssr causes the operation to be distributed (the scenarios in
1265    Section 4.2.1.2 are an example), then an intermediate referral {TODO:
1266    this is talking about referral/intermediate referral, but this
1267    section is only dealing with populating continuation reference} is
1268    returned for each value of the ref attribute, where each intermediate
1269    referral only holds a single referralURI value.
1270
1271
1272 4.3.3  Conveying new search scope
1273
1274
1275    During the evaluation of the search operation, the instructions in
1276    Section 4.2.1.2.1 and Section 4.2.1.2.2 are followed and the
1277    searchScope field is updated with the new search scope.
1278
1279
1280 4.3.4  Preventing duplicates
1281
1282
1283    In order to prevent duplicate entries from being evaluated while
1284    progressing a search operation, the searchedSubtrees field is
1285    populated with any naming context below the
1286    ContinuationReference.targetObject which have been fully searched.
1287
1288
1289    During the evaluation of the search operation, if the scope is
1290    wholeSubtree, it is possible that the DSA may search the contents of
1291    a naming context which is subordinate to another naming context which
1292    is subordinate to the search base (See figure).
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306 Sermersheim              Expires August 26, 2005               [Page 20]
1307 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1308
1309
1310
1311                         O X
1312                        / \
1313                       /   \
1314                      /     \
1315                     /       \
1316                     \_______O Y
1317                            /|\
1318                           / | \
1319                          /  |  \
1320                         /   |   \
1321                        A    B    O C
1322                                 / \
1323                                /   \
1324                               /     \
1325                              /       \
1326                              \_______/
1327
1328
1329    In this figure, the DSA holds the naming context X and C,Y,X, but not
1330    Y,X.  If the search base was X, an intermediate referral would be
1331    returned for Y,X.  The DSA holding Y,X may also hold a copy of C,Y,X.
1332    In this case, the receiver of the ContinuationReference benefits by
1333    knowing that the DSA already searched C,Y,X so that it can prevent
1334    other DSAs from returning those entries again.
1335
1336
1337    Data already searched is in the form of an RDNSequence, consisting of
1338    the RDNs relative to the target object.
1339
1340
1341 4.3.5  Conveying the Failed Name
1342
1343
1344    At least one DS operation (modifyDN) requires that multiple DNs be
1345    resolved (the entry being modified and the newSuperior entry).  In
1346    this case, the failedName field will be populated with the DN being
1347    resolved which failed name resolution.  This may aid in the
1348    determination of how the operation is to be progressed.  If both
1349    names are found to be non-local, this field is omitted.
1350
1351
1352 4.4  Sending a ChainedRequest
1353
1354
1355    When an entry is found to be non-local to a DSA (whether during name
1356    resolution or operation evaluation), the DSA may progress the
1357    operation by sending a chained operation to another DSA (or DSAs).
1358    The instructions in this section assume that a ContinuationReference
1359    has been generated which will be used to form the ChainedRequest.  It
1360    is also assumed that it can be determined whether the operation is
1361    being progressed due to name resolution or due to operation
1362    evaluation.
1363
1364
1365    A DSA which is able to chain operations may advertise this by
1366
1367
1368
1369
1370 Sermersheim              Expires August 26, 2005               [Page 21]
1371 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1372
1373
1374
1375    returning a value of IANA-ASSIGNED-OID.2; in the supportedFeatures
1376    attribute on the root DSE.  {TODO: does this and discovery of the
1377    extended op belong in a new 'discovery mechanisms' sections.}
1378
1379
1380 4.4.1  Forming a ChainedRequest
1381
1382
1383    The following fields are populated as instructed:
1384
1385
1386 4.4.1.1  ChainedRequestValue.chainingArguments.targetObject
1387
1388
1389    The ContinuationReference may convey a new target object.  If
1390    present, the ContinuationReference.localReference field becomes the
1391    candidate target object.  Otherwise the candidate target object is
1392    assumed to be that of the original directory operation.  Note that an
1393    empty value in the ContinuationReference.localReference field denotes
1394    the root object.
1395
1396
1397    After performing the above determination as to the candidate target
1398    object, any RDNSequence in ContinuationReference.remainingName is
1399    prepended to the determined candidate target object.  This value
1400    becomes the ChainedRequestValue.chainingArguments.targetObject.  If
1401    this value matches the value of the original operation, this field
1402    may be omitted.
1403
1404
1405 4.4.1.2  ChainedRequestValue.chainingArguments.referenceType
1406
1407
1408    This is populated with the
1409    ContinuationReference.referralURI.referenceType.
1410
1411
1412 4.4.1.3  ChainedRequestValue.chainingArguments.traceInformation
1413
1414
1415    This is populated as specified in Section 3.2.1.3.
1416
1417
1418 4.4.1.4  ChainedRequestValue.chainingArguments.searchScope
1419
1420
1421    This is populated with the
1422    ContinuationReference.referralURI.searchScope if present, otherwise
1423    by the ContinuationReference.searchScope if present, and not
1424    populated otherwise.
1425
1426
1427 4.4.1.5  ChainedRequestValue.chainingArguments.searchedSubtrees
1428
1429
1430    This is populated with ContinuationReference.searchedSubtrees, as
1431    well as any previously received values of
1432    ChainedFinalResponseValue.chainingResults.searchedSubtrees or
1433    ChainedIntermediateResponseValue.chainingResults.searchedSubtrees
1434    which are subordinate, relative to the target object.  (If thsi is
1435    relative to the target object, it can't contain non-relative
1436
1437
1438
1439
1440 Sermersheim              Expires August 26, 2005               [Page 22]
1441 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1442
1443
1444
1445    subtrees)
1446
1447
1448 4.4.1.6  ChainedRequestValue.operationRequest
1449
1450
1451    This is populated with the original directory operation request.
1452
1453
1454 4.4.2  Attempting Each Referral URI
1455
1456
1457    A ContinuationReference consists of one or more referralURIs which
1458    represent(s a) remote DSA(s).  The chaining DSA attempts to chain to
1459    each of these DSAs until one succeeds in completing the operation.
1460    An operation is considered to be completed if it reaches the remote
1461    DSA and a response is sent back that indicates that the operation was
1462    executed.  Operations which are sent to the remote DSA, but don't
1463    complete are indicated by a result code of unavailable or busy.  A
1464    result code of protocolError may indicate that the DSA does not
1465    support the chained operation, and in this case, it is also treated
1466    as an uncompleted operation.  Other errors may in the future specify
1467    that they also indicate non-completion.  Note that the response may
1468    itself contain referral(s), these are still considered completed
1469    operations and thus would subsequently be handled and chained.
1470    {TODO: could use soft/hard, or transient/permanent
1471    referral/non-referral error terms here.}
1472
1473
1474 4.4.3  Loop Prevention
1475
1476
1477    Prior to sending a ChainedRequest, the DSA may attempt to prevent
1478    looping scenarios by comparing {TODO: what matching rule is used?
1479    Suggest we don't convert dns names to ip addresses due to NATs} the
1480    address of the remote DSA and target object to the values of
1481    ChainedRequestValue.chainingArguments.traceInformation.  If a match
1482    is found, the DSA returns a loopDetect error.  Note that while this
1483    type of loop prevention aids in detecting loops prior to sending data
1484    to a remote DSA, it is not a substitute for loop detection (Section
1485    Section 4.6.2).  This is because the sending DSA is only aware of a
1486    single address on which the receiving DSA accepts connections.
1487
1488
1489 4.5  Emulating the Sending of a ChainedRequest
1490
1491
1492    When it is determined that the operation cannot be distributed by
1493    means of the ChainedRequest, the chaining DSA may instead emulate the
1494    steps involved in chaining the operation.  These steps consist of
1495    performing loop prevention, forming a new directory operation request
1496    from the original request and possibly updating the base DN, search
1497    scope, and search filter(in order to emulate searchedSubtrees), and,
1498    similar to the steps in Section 4.4.2, attempting to send the
1499    operation request to each DSA listed in the
1500    ContinuationReference.referralURI until one succeeds in completing
1501
1502
1503
1504
1505 Sermersheim              Expires August 26, 2005               [Page 23]
1506 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1507
1508
1509
1510    the operation.
1511
1512
1513    {TODO: We need a way (control) to tell the receiver to allow name
1514    resolution to end on the parent of a cp (typically an immsupr).  This
1515    would be sent when the ContinuationReference.referenceType is
1516    nonSpecificSubordinate}
1517
1518
1519 4.5.1  Emulated Loop Detection
1520
1521
1522    For this step, the loop prevention instructions in Section 4.4.3 are
1523    followed.  Note that this method of loop detection may actually allow
1524    some looping to occur before the loop is detected.
1525
1526
1527 4.5.2  Forming the New Request
1528
1529
1530    The new directory operation request is formed from the fields of the
1531    original request, and the following fields may be updated:
1532
1533
1534    o  The base DN is formed from the new target object as determined by
1535       following the instructions in Section 4.4.1.1 and using the value
1536       which would have been placed in
1537       ChainedRequestValue.chainingArguments.targetObject.
1538    o  For the search operation, the scope is populated with
1539       ContinuationReference.searchScope if present, otherwise the scope
1540       of the original operation request is used.
1541    o  For the search operation, if the
1542       ContinuationReference.searchedSubtrees field is present, causes
1543       the search filter to be augmented by adding a filter item of the
1544       'and' CHOICE.  The filter consists of {TODO: weasel Kurt into
1545       finishing his entryDN draft and reference the appropriate section
1546       there.  See
1547       <http://www.openldap.org/lists/ietf-ldapext/200407/msg00000.html>
1548       for context}
1549    o  Other fields (such as the messageID, and non-critical controls)
1550       may also need to be updated or excluded.
1551
1552
1553    If the service being chained to does not support directory
1554    operations, other operations may be used as long as they provide the
1555    same level as service as those provided by the analogous directory
1556    operation.
1557
1558
1559 4.6  Receiving a ChainedRequest
1560
1561
1562    A DSA which is able to receive and service a ChainedRequest may
1563    advertise this feature by returning a value of IANA-ASSIGNED-OID.1 in
1564    the supportedExtension attribute of the root DSE.  {TODO: move?}
1565
1566
1567    The ChainedRequestValue data type is the requestValue of an
1568
1569
1570
1571
1572 Sermersheim              Expires August 26, 2005               [Page 24]
1573 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1574
1575
1576
1577    extendedRequest.
1578
1579
1580    In general, receiving and servicing a ChainedRequest consists of
1581    performing loop detection and, using components of the
1582    ChainedRequestType.chainingArguments along with the
1583    ChainedRequestType.operationRequest, service the request.
1584
1585
1586 4.6.1  Target Object determination
1587
1588
1589    Prior to checking for a loop condition, the target object must be
1590    determined.  If the ChainedRequestType.chainingArguments.targetObject
1591    field is present, its value becomes the target object.  Otherwise,
1592    the base DN found in the ChainedRequestType.operationRequest becomes
1593    the target object.
1594
1595
1596 4.6.2  Loop Detection
1597
1598
1599    The loop detection check happens when a DSA receives a chained
1600    operation, prior to acting on the operation.  The DSA compares {TODO:
1601    matching rule? DNS expansion?} each value of
1602    ChainedRequestValue.traceInformation to the list of addresses at
1603    which it accepts directory communications.  A value of
1604    ChainedRequestValue.traceInformation matches when the DSA accepts
1605    directory communications on the address found in the
1606    ChainedRequestValue.traceInformation value, and the target object (as
1607    determined in Section 4.6.1 matches the DN {TODO: using DN matching?}
1608    value found in the ChainedRequestValue.traceInformation value.  If a
1609    match is found the DSA returns a loopDetect result.
1610
1611
1612 4.6.3  Processing the ChainedRequestValue.operationRequest
1613
1614
1615    In processing the operationRequest, the DSA uses the target object
1616    determined in Section 4.6.1.  For search operations, it uses the
1617    scope found in ChainedRequestValue.chainingArguments.searchScope, and
1618    excludes any subtrees relative to the target object indicated in
1619    ChainedRequestValue.chainingArguments.searchedSubtrees.
1620
1621
1622    Responses are returned in the form of a Chained Response.
1623
1624
1625 4.7  Returning a Chained Response
1626
1627
1628    When returning responses to a ChainedRequest, the Chained Response as
1629    documented in Section 3.3 is used.  If the
1630    ChainedFinalResponseValue.operationResponse is a searchResultDone,
1631    the ChainedFinalResponseValue.chainingResults.searchedSubtrees field
1632    is populated with values consisting of the RDNSequence relative to
1633    the target object of naming contexts that the DSA searched.  See
1634    Section 3.3.1.1 for details on why this is done.
1635
1636
1637
1638
1639 Sermersheim              Expires August 26, 2005               [Page 25]
1640 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1641
1642
1643
1644 4.7.1  Chained Response resultCode
1645
1646
1647    The resultCode for the Chained Response is distinct from the result
1648    code of the ChainedIntermediateResponseValue.intermediateResponse or
1649    ChainedFinalResponseValue.finalResponse.  If the act of chaining the
1650    operation completed, then this value will be success.  Other result
1651    codes refer to the chained operation itself, and not the result of
1652    the embedded operation.
1653
1654
1655 4.7.2  Returning referrals in the Chained Response
1656
1657
1658    {TODO: it would be less complicated if rather than using the simple
1659    LDAP URL, we used the ContinuationReference type to return referrals
1660    and intermediate referrals.} {TODO: We need an example of why we
1661    should allow referrals on a chained response.  Why not just use the
1662    referral field in the operation?}
1663
1664
1665 4.8  Receiving a Chained Response
1666
1667
1668    Processing a received Chained Response is generally straight forward
1669    -- typically the response is simply extracted and returned, but there
1670    are some extra steps to be taken when chaining sub-operations.
1671
1672
1673 4.8.1  Handling Sub-operation controls and result codes
1674
1675
1676    When sub-operations are chained, there is the possibility that
1677    different result codes will be encountered.  Similarly, if controls
1678    which elicit response controls were attached to the operation, it's
1679    possible that multiple response controls will be encountered.  Both
1680    of these possibilities require that the chaining DSA take appropriate
1681    steps to ensure that the response being returned is correct.
1682
1683
1684    In general, when a result code indicating an error is received, the
1685    operation will terminate and the error will be returned.  In cases
1686    where multiple sub-operations are being concurrently serviced, the
1687    operation will terminate and the most relevant, or first received
1688    result code is returned -- determining the result code to be returned
1689    in this case is a local matter.
1690
1691
1692    A DSA which chains an operation having a control (or controls)
1693    attached must ensure that a properly formed response is returned.
1694    This requires that the DSA understand and know how to aggrigate the
1695    results of all controls which it allows to remain attached to an
1696    operation being chained.  If the DSA does not understand or support a
1697    control which is marked non-critical, it removes the control prior to
1698    chaining the operation.  The DSA may return
1699    unavailableCriticalExtension for critical controls that it cannot or
1700    will not chain.  {TODO: give SSS as an example?}
1701
1702
1703
1704
1705 Sermersheim              Expires August 26, 2005               [Page 26]
1706 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1707
1708
1709
1710 4.8.1.1  Handling referrals during sub-operations
1711
1712
1713    If a referral is returned in response to a sub-operation, the sending
1714    DSA may attempt to further chain the operation.  In the event that
1715    the DSA does not further chain the sub-operation, it will use the
1716    referral to construct an intermediate referral, and return it
1717    appropriately.  When using a referral to construct an intermediate
1718    referral, certain transformations may have to happen.  For example,
1719    when using a referral to construct a searchResultReference, it must
1720    be assured that the <dn> field is present, and that the <scope> field
1721    is properly updated.
1722
1723
1724 4.8.2  Duplicate Elimination
1725
1726
1727    When search result references cause the DSA to chain a search, it is
1728    possible that duplicate objects will be returned by different remote
1729    DSAs.  These duplicate objects must be sensed and not returned.
1730
1731
1732    {TODO: Even though there are costs associated with returning
1733    duplicates, is it a worthy exercise to build in an allowance for them
1734    to be returned? In other words, do we want to add a way for a client
1735    (or administrator) to say "it's ok, return the duplicates, let the
1736    client deal with them"? Allowing is seen as a cost benefit to the
1737    DSA.}
1738
1739
1740 4.9  Returning a Referral or Intermediate Referral
1741
1742
1743    There are two ways in which the fields of the ContinuationReference
1744    may be conveyed in a response containing or consisting of referral or
1745    intermediate referral.  A paired control is introduced for the
1746    purpose of soliciting and returning a ContinuationReference.  In
1747    absence of this control, a referral or intermediate referral may be
1748    returned which conveys the information present in the
1749    ContinuationReference.  A method of converting a
1750    ContinuationReference to an LDAP URL is provided for referrals and
1751    intermediate referrals which identify LDAP-enabled DSAs.  Methods for
1752    converting a ContinuationReference to URIs which identify non-LDAP
1753    servers is not provided here, but may be specified in future
1754    documents, as long as they can represent the data needed to provide
1755    the same level of service.
1756
1757
1758 4.9.1  ReturnContinuationReference controls
1759
1760
1761    This control is sent when a client wishes to receive a
1762    ContinuationReference in the event that a referral or intermediate
1763    referral is being returned.  If returned, the ContinuationReference
1764    will hold all data but the referralURI field.  the referralURI values
1765    will be held in the referral or intermediate referral (Referral,
1766
1767
1768
1769
1770 Sermersheim              Expires August 26, 2005               [Page 27]
1771 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1772
1773
1774
1775    SearchResultReference, etc.).
1776
1777
1778 4.9.1.1  ReturnContinuationReference request control
1779
1780
1781    Solicits the return of a ReturnContinuationReference response control
1782    on messages consisting of (or carrying) a referral or intermediate
1783    referral.  The controlType is IANA-ASSIGNED-OID.3, the criticality is
1784    set at the sender's discretion, the controlValue is omitted.
1785
1786
1787 4.9.1.2  ReturnContinuationReference response control
1788
1789
1790    In response to the ReturnContinuationReference request control, this
1791    holds a ContinuationReference for messages consisting of (or
1792    carrying) a referral or intermediate referral.  The controlType is
1793    IANA-ASSIGNED-OID.3, the controlValue is the BER-encoding of a
1794    ContinuationReference.  Note that the referralURI field is optionally
1795    omitted when the ContinuationReference is sent in this control value.
1796    In this event, the URI(s) found in the referral or intermediate
1797    referral (Referral, SearchContinuationReference, etc.) are to be used
1798    in its stead.  {TODO: is returining the referralURI outside an
1799    unneeded complication?}
1800
1801
1802 4.9.2  Converting a ContinuationReference to an LDAP URL
1803
1804
1805    This section details the way in which an LDAP URL (from the referral
1806    or intermediate referral) is used to convey the fields of a
1807    ContinuationReference.  Where existing LDAP URL fields are
1808    insufficient, extensions are introduced.  Note that further
1809    extensions to the ContinuationReference type require further
1810    specifications here.  {TODO: explain that each ldap url in the
1811    continuation refrerence is examined and converted}
1812
1813
1814    These instructions must be applied to each LDAP URL value within the
1815    referral or intermediate referral.
1816
1817
1818 4.9.2.1  Conveying the target name
1819
1820
1821    If the <dn> part of the LDAP URL is already present, it is determined
1822    to be the candidate target object.  Otherwise, the candidate target
1823    object comes from the ContinuationReference.localReference.  Once the
1824    candidate target object is determined, the value of
1825    ContinuationReference.remainingName is prepended to the candidate
1826    target object.  This new value becomes the target object and its
1827    string value (as specified by <distinguishedName> in [RFC2253]) is
1828    placed in the <dn> part of the LDAP URL.
1829
1830
1831
1832
1833
1834
1835
1836 Sermersheim              Expires August 26, 2005               [Page 28]
1837 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1838
1839
1840
1841 4.9.2.2  ContinuationReference.localReference
1842
1843
1844    This is conveyed as an extension.  The extype is IANA-ASSIGNED-OID.4
1845    or the descriptor 'localReference', and the exvalue is the string DN
1846    encoding (as specified by <distinguishedName> in [RFC2253]) of the
1847    ContinuationReference.localReference value.
1848
1849
1850 4.9.2.3  ContinuationReference.referenceType
1851
1852
1853    This is conveyed as an extension.  The extype is IANA-ASSIGNED-OID.5
1854    or the descriptor 'referenceType'.  If the
1855    ContinuationReference.referenceType is one of superior, subordinate,
1856    cross, nonSpecificSubordinate, suplier, master, immediateSuperior, or
1857    self, the exvalue 'superior', 'subordinate', 'cross',
1858    'nonSpecificSubordinate', 'suplier', 'master', 'immediateSuperior',
1859    or 'self' respectively.
1860
1861
1862 4.9.2.4  ContinuationReference.searchScope
1863
1864
1865    If the search scope is one of baseObject, singleLevel, or
1866    wholeSubtree, then it may be conveyed in the 'scope' part of the LDAP
1867    URL as 'base', 'one', or 'sub' respectively.  If the search scope is
1868    subordinateSubtree, then it may be conveyed in the <extension> form
1869    as documented in [LDAP-SUBORD].  If this extension is present, it
1870    MUST be marked critical.  This ensures that a receiver which is
1871    unaware of this extension uses the proper search scope, or fails to
1872    progress the operation.
1873
1874
1875 4.9.2.5  ContinuationReference.searchedSubtrees
1876
1877
1878    This field is conveyed as an extension.  The extype is
1879    IANA-ASSIGNED-OID.6 or the descriptor 'searchedSubtrees', and the
1880    exvalue is the ContinuationReference.searchedSubtree value encoded
1881    according to the following searchedSubtrees ABNF:
1882
1883
1884       searchedSubtrees = 1*(LANGLE searchedSubtree RANGLE)
1885       searchedSubtree = <distinguishedName> from [RFC2253]
1886       LANGLE  = %x3C ; left angle bracket ("<")
1887       RANGLE  = %x3E ; right angle bracket (">")
1888
1889
1890    Each searchedSubtree represents one RDNSequence value in the
1891    ContinuationReference.searchedSubtree field.  An example of a
1892    searchedSubtrees value containing two searched subtrees is:
1893    <dc=example,dc=com><cn=ralph,dc=users,dc=example,dc=com>.
1894
1895
1896 4.9.2.6  ContinuationReference.failedName
1897
1898
1899    This field is conveyed as an extension.  The extype is
1900
1901
1902
1903
1904 Sermersheim              Expires August 26, 2005               [Page 29]
1905 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1906
1907
1908
1909    IANA-ASSIGNED-OID.7 or the descriptor 'failedName', and the exvalue
1910    is the string DN encoding (as specified in [RFC2253]) of the
1911    ContinuationReference.failedName value.
1912
1913
1914 4.10  Acting on a Referral or Intermediate Referral
1915
1916
1917    When a protocol peer receives a referral or intermediate referral, it
1918    may distribute the operation either by sending a ChainedRequest, or
1919    by emulating the ChainedRequest.  Prior to taking these steps, the
1920    protocol peer effectively converts the referral or intermediate
1921    referral into a ContinuationReference.  Then, acting in the same
1922    manner as a DSA would, follows the directions in Section 4.4 if
1923    sending a ChainedRequest, or Section 4.5 otherwise.
1924
1925
1926 4.10.1  Converting a Referral or Intermediate Referral to a
1927        ContinuationReference
1928
1929
1930    A referral or intermediate referral may be converted (or conceptually
1931    converted) to a ContinuationReference type in order to follow the
1932    distributed operation procedures in Section 4.4, or Section 4.5.  The
1933    following steps may only be used to convert a referral or
1934    intermediate referral containing LDAP URL values.  Converting other
1935    types of URIs may be specified in future documents as long as the
1936    conversion provides the same level of service found here.
1937
1938
1939    o  The ContinuationReference.referralURI is populated with all LDAP
1940       URL values in the referral or intermediate referral.
1941    o  The ContinuationReference.localReference populate with the value
1942       of the localReference extension value (Section 4.9.2.2) if one
1943       exists.  Otherwise it is omitted.
1944    o  The ContinuationReference.referenceType populate with the value of
1945       the referenceType extension value (Section 4.9.2.3) if one exists.
1946       Otherwise it is omitted.
1947    o  The ContinuationReference.remainingName is omitted.
1948    o  The ContinuationReference.searchScope is populated with
1949       subordinateSubtree if the subordScope LDAP URL extension
1950       [LDAP-SUBORD] is present.  If the <scope> field contains te value
1951       'base', 'one', 'sub', or 'subordinates', this filed is populated
1952       with baseObject, singleLevel, wholeSubtree, or subordinateSubtree
1953       respectively.  Otherwise this field is omitted.
1954    o  The ContinuationReference.searchedSubtrees is populated with any
1955       searchedSubtrees LDAP URI extension Section 4.9.2.5 value found on
1956       an LDAP URI in the referral or intermediate referral.  If none
1957       exist, this field is omitted.
1958    o  The ContinuationReference.failedName is populated with any
1959       failedName LDAP URI extension Section 4.9.2.6 value found on an
1960       LDAP URI in the referral or intermediate referral.  If none exist,
1961       this field is omitted.
1962
1963
1964
1965
1966 Sermersheim              Expires August 26, 2005               [Page 30]
1967 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
1968
1969
1970
1971    Note that many fields are simply omitted.  This is either because
1972    they are conveyed within the LDAP URL values themselves, and
1973    subsequent instructions will check for their presence, or because
1974    they are not needed (they are redundant or not used in further
1975    instructions).
1976
1977
1978 4.11  Ensuring non-existence of an entry under an nssr
1979
1980
1981    {TODO: add a huge disclaimer here that says without transactional
1982    semantics, you can never be sure that the entry didn't get added.
1983    Maybe we should just punt on this and say it's a local matter} In
1984    order to ensure there are no entries matching the name of the entry
1985    to be added or renamed immediately subordinate to an nssr, these
1986    steps may be followed.
1987
1988
1989    If the DSA is able and allowed to chain operations, it may contact
1990    each of the DSAs listed as access points in the nssr (in the ref
1991    attribute) and using a base-level search operation it will determine
1992    whether or not the object to be added exists.  Note that access
1993    control or other policies may hide the entry from the sending DSA.
1994    If the entry does not exist on any of the DSAs listed in the nssr,
1995    the operation may progress on the local DSA.
1996
1997
1998    If the DSA cannot make this determination, the operation fails with
1999    affectsMultipleDSAs.
2000
2001
2002 4.12  Mapping a referralURI to an LDAP URI
2003
2004
2005    As with any URI specification which is intended to be used as a URI
2006    which conveys referral information, the LDAP URI specification is
2007    given a mapping to the elements of a referralURI as specified in.
2008    Section 3.1.1.1.  These mappings are given here using the ABNF
2009    identifiers given in [RFC2255].
2010
2011
2012    referralURI to LDAP URI mapping:
2013
2014
2015    +---------------------------------+---------------------------------+
2016    | referralURI element             | LDAP URL element                |
2017    +---------------------------------+---------------------------------+
2018    | protocolIdentifier              | <scheme>                        |
2019    |                                 |                                 |
2020    | accessPoint                     | <hostport>                      |
2021    |                                 |                                 |
2022    | targetObject                    | <dn>. This must be encoded as a |
2023    |                                 | <distinguishedName> as          |
2024    |                                 | specified in [RFC2253]          |
2025    |                                 |                                 |
2026    | localReference                  | LDAP URL localReference         |
2027
2028
2029
2030
2031 Sermersheim              Expires August 26, 2005               [Page 31]
2032 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
2033
2034
2035
2036    |                                 | extension as specified in       |
2037    |                                 | Section 4.9.2.2                 |
2038    |                                 |                                 |
2039    | referenceType                   | LDAP URL referenceType          |
2040    |                                 | extension as specified in       |
2041    |                                 | Section 4.9.2.3                 |
2042    |                                 |                                 |
2043    | searchScope                     | <scope> or LDAP URL subordScope |
2044    |                                 | extension as specified in       |
2045    |                                 | Section 4.9.2.4                 |
2046    |                                 |                                 |
2047    | searchedSubtrees                | LDAP URL searchedSubtrees       |
2048    |                                 | extension as specified in       |
2049    |                                 | Section 4.9.2.5                 |
2050    |                                 |                                 |
2051    | failedName                      | LDAP URL failedName extension   |
2052    |                                 | as specified in Section 4.9.2.6 |
2053    +---------------------------------+---------------------------------+
2054
2055
2056
2057  4.13   Using the ManageDsaIT control
2058
2059
2060    This control, defined in [RFC3296], allows the management of the
2061    distributed knowledge information held by a DSA, and thus overrides
2062    the determinations made during name resolution and operation
2063    evaluation.  When this control is attached to an operation, all
2064    resolved and acted upon DSEs are treated as being local to the DSA.
2065    This is true regardless of the phase the operation is in.  Thus
2066    referrals are never returned and chaining never occurs.
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090 Sermersheim              Expires August 26, 2005               [Page 32]
2091 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
2092
2093
2094
2095 5.  Security Considerations
2096
2097
2098    This document introduces a mechanism (chaining) which can be used to
2099    propagate directory operation requests to servers which may be
2100    inaccessible otherwise.  Implementers and deployers of this
2101    technology should be aware of this and take appropriate steps such
2102    that firewall mechanisms are not compromised.
2103
2104
2105    This document introduces the ability to return auxiliary data when
2106    returning referrals.  Measures should be taken to ensure proper
2107    protection of his data.
2108
2109
2110    Implementers must ensure that any specified time, size, and
2111    administrative limits are not circumvented due to the mechanisms
2112    introduced here.
2113
2114
2115 6.  Normative References
2116
2117
2118    [LDAP-SUBORD]
2119               Sermersheim, J., "Subordinate Subtree Search Scope for
2120               LDAP",
2121               Internet-Draft draft-sermersheim-ldap-subordinate-scope,
2122               July 2004.
2123
2124
2125    [RFC2079]  Smith, M., "Definition of an X.500 Attribute Type and an
2126               Object Class to Hold Uniform Resource Identifiers (URIs)",
2127               RFC 2079, January 1997.
2128
2129
2130    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2131               Requirement Levels", BCP 14, RFC 2119, March 1997.
2132
2133
2134    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
2135               Access Protocol (v3)", RFC 2251, December 1997.
2136
2137
2138    [RFC2253]  Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
2139               Access Protocol (v3): UTF-8 String Representation of
2140               Distinguished Names", RFC 2253, December 1997.
2141
2142
2143    [RFC2255]  Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
2144               December 1997.
2145
2146
2147    [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
2148               Resource Identifiers (URI): Generic Syntax", RFC 2396,
2149               August 1998.
2150
2151
2152    [RFC3296]  Zeilenga, K., "Named Subordinate References in Lightweight
2153               Directory Access Protocol (LDAP) Directories", RFC 3296,
2154               July 2002.
2155
2156
2157
2158
2159 Sermersheim              Expires August 26, 2005               [Page 33]
2160 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
2161
2162
2163
2164    [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
2165               Protocol (v3): Technical Specification", RFC 3377,
2166               September 2002.
2167
2168
2169    [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
2170               Considerations for the Lightweight Directory Access
2171               Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
2172
2173
2174    [RFC3771]  Harrison, R. and K. Zeilenga, "The Lightweight Directory
2175               Access Protocol (LDAP) Intermediate Response Message",
2176               RFC 3771, April 2004.
2177
2178
2179    [X500]     International Telephone and Telegraph Consultative
2180               Committee, "The Directory - overview of concepts, models
2181               and services", ITU-T Recommendation X.500, November 1993.
2182
2183
2184    [X518]     International Telephone and Telegraph Consultative
2185               Committee, "The Directory - The Directory: Procedures for
2186               distributed operation", ITU-T Recommendation X.518,
2187               November 1993.
2188
2189
2190    [X680]     International Telecommunications Union, "Abstract Syntax
2191               Notation One (ASN.1): Specification of basic notation",
2192               ITU-T Recommendation X.680, July 2002.
2193
2194
2195    [X690]     International Telecommunications Union, "Information
2196               Technology - ASN.1 encoding rules: Specification of Basic
2197               Encoding Rules (BER), Canonical Encoding Rules (CER) and
2198               Distinguished Encoding Rules (DER)", ITU-T Recommendation
2199               X.690, July 2002.
2200
2201
2202
2203 Author's Address
2204
2205
2206    Jim Sermersheim
2207    Novell, Inc
2208    1800 South Novell Place
2209    Provo, Utah  84606
2210    USA
2211
2212
2213    Phone: +1 801 861-3088
2214    Email: jimse@novell.com
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225 Sermersheim              Expires August 26, 2005               [Page 34]
2226 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
2227
2228
2229
2230 Appendix A.  IANA Considerations
2231
2232
2233    Registration of the following values is requested [RFC3383].
2234
2235
2236 A.1  LDAP Object Identifier Registrations
2237
2238
2239    It is requested that IANA register upon Standards Action an LDAP
2240    Object Identifier in identifying the protocol elements defined in
2241    this technical specification.  The following registration template is
2242    provided:
2243
2244
2245       Subject: Request for LDAP OID Registration
2246       Person & email address to contact for further information:
2247          Jim Sermersheim
2248          jimse@novell.com
2249       Specification: RFCXXXX
2250       Author/Change Controller: IESG
2251       Comments:
2252       Seven delegations will be made under the assigned OID:
2253       IANA-ASSIGNED-OID.1 ChainedRequest LDAP Extended Operation
2254       IANA-ASSIGNED-OID.2 Supported Feature: Can Chain Operations
2255       IANA-ASSIGNED-OID.3 ReturnContinuationReference LDAP Controls
2256       IANA-ASSIGNED-OID.4 localReference: LDAP URL Extension
2257       IANA-ASSIGNED-OID.6 searchedSubtree: LDAP URL Extension
2258       IANA-ASSIGNED-OID.7 failedName: LDAP URL Extension
2259
2260
2261 A.2  LDAP Protocol Mechanism Registrations
2262
2263
2264    It is requested that IANA register upon Standards Action the LDAP
2265    protocol mechanism described in this document.  The following
2266    registration templates are given:
2267
2268
2269       Subject: Request for LDAP Protocol Mechanism Registration
2270       Object Identifier: IANA-ASSIGNED-OID.1
2271       Description: ChainedRequest LDAP Extended Operation
2272       Person & email address to contact for further information:
2273          Jim Sermersheim
2274          jimse@novell.com
2275       Usage: Extension
2276       Specification: RFCXXXX
2277       Author/Change Controller: IESG
2278       Comments: none
2279
2280
2281       Subject: Request for LDAP Protocol Mechanism Registration
2282       Object Identifier: IANA-ASSIGNED-OID.2
2283       Description: Can Chain Operations Supported Feature
2284       Person & email address to contact for further information:
2285
2286
2287
2288
2289
2290 Sermersheim              Expires August 26, 2005               [Page 35]
2291 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
2292
2293
2294
2295          Jim Sermersheim
2296          jimse@novell.com
2297       Usage: Feature
2298       Specification: RFCXXXX
2299       Author/Change Controller: IESG
2300       Comments: none
2301
2302
2303       Subject: Request for LDAP Protocol Mechanism Registration
2304       Object Identifier: IANA-ASSIGNED-OID.3
2305       Description: ReturnContinuationReference LDAP Controls
2306       Person & email address to contact for further information:
2307          Jim Sermersheim
2308          jimse@novell.com
2309       Usage: Control
2310       Specification: RFCXXXX
2311       Author/Change Controller: IESG
2312       Comments: none
2313
2314
2315       Subject: Request for LDAP Protocol Mechanism Registration
2316       Object Identifier: IANA-ASSIGNED-OID.4
2317       Description: localReference LDAP URL Extension
2318       Person & email address to contact for further information:
2319          Jim Sermersheim
2320          jimse@novell.com
2321       Usage: Extension
2322       Specification: RFCXXXX
2323       Author/Change Controller: IESG
2324       Comments: none
2325
2326
2327       Subject: Request for LDAP Protocol Mechanism Registration
2328       Object Identifier: IANA-ASSIGNED-OID.5
2329       Description: referenceType LDAP URL Extension
2330       Person & email address to contact for further information:
2331          Jim Sermersheim
2332          jimse@novell.com
2333       Usage: Extension
2334       Specification: RFCXXXX
2335       Author/Change Controller: IESG
2336       Comments: none
2337
2338
2339       Subject: Request for LDAP Protocol Mechanism Registration
2340       Object Identifier: IANA-ASSIGNED-OID.6
2341       Description: searchedSubtree LDAP URL Extension
2342       Person & email address to contact for further information:
2343          Jim Sermersheim
2344          jimse@novell.com
2345       Usage: Extension
2346
2347
2348
2349
2350
2351 Sermersheim              Expires August 26, 2005               [Page 36]
2352 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
2353
2354
2355
2356       Specification: RFCXXXX
2357       Author/Change Controller: IESG
2358       Comments: none
2359
2360
2361       Subject: Request for LDAP Protocol Mechanism Registration
2362       Object Identifier: IANA-ASSIGNED-OID.7
2363       Description: failedName LDAP URL Extension
2364       Person & email address to contact for further information:
2365          Jim Sermersheim
2366          jimse@novell.com
2367       Usage: Extension
2368       Specification: RFCXXXX
2369       Author/Change Controller: IESG
2370       Comments: none
2371
2372
2373 A.3  LDAP Descriptor Registrations
2374
2375
2376    It is requested that IANA register upon Standards Action the LDAP
2377    descriptors described in this document.  The following registration
2378    templates are given:
2379
2380
2381       Subject: Request for LDAP Descriptor Registration
2382       Descriptor (short name): localReference
2383       Object Identifier: IANA-ASSIGNED-OID.4
2384       Person & email address to contact for further information:
2385          Jim Sermersheim
2386          jimse@novell.com
2387       Usage: URL Extension
2388       Specification: RFCXXXX
2389       Author/Change Controller: IESG
2390       Comments: none
2391
2392
2393       Subject: Request for LDAP Descriptor Registration
2394       Descriptor (short name): referenceType
2395       Object Identifier: IANA-ASSIGNED-OID.5
2396       Person & email address to contact for further information:
2397          Jim Sermersheim
2398          jimse@novell.com
2399       Usage: URL Extension
2400       Specification: RFCXXXX
2401       Author/Change Controller: IESG
2402       Comments: none
2403
2404
2405       Subject: Request for LDAP Descriptor Registration
2406       Descriptor (short name): searchedSubtree
2407       Object Identifier: IANA-ASSIGNED-OID.6
2408       Person & email address to contact for further information:
2409
2410
2411
2412
2413
2414 Sermersheim              Expires August 26, 2005               [Page 37]
2415 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
2416
2417
2418
2419          Jim Sermersheim
2420          jimse@novell.com
2421       Usage: URL Extension
2422       Specification: RFCXXXX
2423       Author/Change Controller: IESG
2424       Comments: none
2425
2426
2427       Subject: Request for LDAP Descriptor Registration
2428       Descriptor (short name): failedName
2429       Object Identifier: IANA-ASSIGNED-OID.7
2430       Person & email address to contact for further information:
2431          Jim Sermersheim
2432          jimse@novell.com
2433       Usage: URL Extension
2434       Specification: RFCXXXX
2435       Author/Change Controller: IESG
2436       Comments: none
2437
2438
2439 A.4  LDAP Result Code Registrations
2440
2441
2442    It is requested that IANA register upon Standards Action the LDAP
2443    result codes described in this document.  The following registration
2444    templates are given:
2445
2446
2447       Subject: Request for LDAP Result Code Registration
2448       Result Code Name: invalidReference
2449       Person & email address to contact for further information:
2450          Jim Sermersheim
2451          jimse@novell.com
2452       Usage: URL Extension
2453       Specification: RFCXXXX
2454       Author/Change Controller: IESG
2455       Comments: none
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475 Sermersheim              Expires August 26, 2005               [Page 38]
2476 Internet-Draft    Distributed Procedures for LDAP Operations  February 2005
2477
2478
2479
2480 Intellectual Property Statement
2481
2482
2483    The IETF takes no position regarding the validity or scope of any
2484    Intellectual Property Rights or other rights that might be claimed to
2485    pertain to the implementation or use of the technology described in
2486    this document or the extent to which any license under such rights
2487    might or might not be available; nor does it represent that it has
2488    made any independent effort to identify any such rights.  Information
2489    on the procedures with respect to rights in RFC documents can be
2490    found in BCP 78 and BCP 79.
2491
2492
2493    Copies of IPR disclosures made to the IETF Secretariat and any
2494    assurances of licenses to be made available, or the result of an
2495    attempt made to obtain a general license or permission for the use of
2496    such proprietary rights by implementers or users of this
2497    specification can be obtained from the IETF on-line IPR repository at
2498    http://www.ietf.org/ipr.
2499
2500
2501    The IETF invites any interested party to bring to its attention any
2502    copyrights, patents or patent applications, or other proprietary
2503    rights that may cover technology that may be required to implement
2504    this standard.  Please address the information to the IETF at
2505    ietf-ipr@ietf.org.
2506
2507
2508
2509 Disclaimer of Validity
2510
2511
2512    This document and the information contained herein are provided on an
2513    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2514    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2515    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2516    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2517    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2518    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2519
2520
2521
2522 Copyright Statement
2523
2524
2525    Copyright (C) The Internet Society (2005).  This document is subject
2526    to the rights, licenses and restrictions contained in BCP 78, and
2527    except as set forth therein, the authors retain all their rights.
2528
2529
2530
2531 Acknowledgment
2532
2533
2534    Funding for the RFC Editor function is currently provided by the
2535    Internet Society.
2536
2537
2538
2539
2540
2541 Sermersheim              Expires August 26, 2005               [Page 39]