1 2Network Working Group J. Sermersheim 3Internet-Draft Novell, Inc 4Expires: August 26, 2005 February 22, 2005 5 6 7 8 Distributed Procedures for LDAP Operations 9 draft-sermersheim-ldap-distproc-02.txt 10 11 12Status 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 46Copyright Notice 47 48 49 Copyright (C) The Internet Society (2005). 50 51 52Abstract 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 66Sermersheim Expires August 26, 2005 [Page 1] 67Internet-Draft Distributed Procedures for LDAP Operations February 2005 68 69 70 71Discussion 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 79Table 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 126Sermersheim Expires August 26, 2005 [Page 2] 127Internet-Draft Distributed Procedures for LDAP Operations February 2005 128 129 130 1311. 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 188Sermersheim Expires August 26, 2005 [Page 3] 189Internet-Draft Distributed Procedures for LDAP Operations February 2005 190 191 192 1932. 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 247Sermersheim Expires August 26, 2005 [Page 4] 248Internet-Draft Distributed Procedures for LDAP Operations February 2005 249 250 251 2523. 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 2593.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 312Sermersheim Expires August 26, 2005 [Page 5] 313Internet-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 3433.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 376Sermersheim Expires August 26, 2005 [Page 6] 377Internet-Draft Distributed Procedures for LDAP Operations February 2005 378 379 380 3813.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 4143.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 4263.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 439Sermersheim Expires August 26, 2005 [Page 7] 440Internet-Draft Distributed Procedures for LDAP Operations February 2005 441 442 443 4443.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 4623.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 4823.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 4973.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 507Sermersheim Expires August 26, 2005 [Page 8] 508Internet-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 5163.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 5673.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 577Sermersheim Expires August 26, 2005 [Page 9] 578Internet-Draft Distributed Procedures for LDAP Operations February 2005 579 580 581 5823.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 6043.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 6163.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 6323.2.1.4 ChainedRequestValue.chainingArguments.searchScope 633 634 635 See Section 3.1.5. 636 637 6383.2.1.5 ChainedRequestValue.chainingArguments.searchedSubtrees 639 640 641 See Section 3.1.6. 642 643 644 645 646 647 648Sermersheim Expires August 26, 2005 [Page 10] 649Internet-Draft Distributed Procedures for LDAP Operations February 2005 650 651 652 6533.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 6743.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 717Sermersheim Expires August 26, 2005 [Page 11] 718Internet-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 7543.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 7623.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 782Sermersheim Expires August 26, 2005 [Page 12] 783Internet-Draft Distributed Procedures for LDAP Operations February 2005 784 785 786 7873.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 840Sermersheim Expires August 26, 2005 [Page 13] 841Internet-Draft Distributed Procedures for LDAP Operations February 2005 842 843 844 8454. 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 8864.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 905Sermersheim Expires August 26, 2005 [Page 14] 906Internet-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 9244.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 9324.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 9404.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 9534.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 973Sermersheim Expires August 26, 2005 [Page 15] 974Internet-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 9944.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 10084.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 10254.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 1040Sermersheim Expires August 26, 2005 [Page 16] 1041Internet-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 10534.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 10934.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 1105Sermersheim Expires August 26, 2005 [Page 17] 1106Internet-Draft Distributed Procedures for LDAP Operations February 2005 1107 1108 1109 11104.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 11284.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 11414.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 11564.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 11644.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 1173Sermersheim Expires August 26, 2005 [Page 18] 1174Internet-Draft Distributed Procedures for LDAP Operations February 2005 1175 1176 1177 11784.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 12014.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 1240Sermersheim Expires August 26, 2005 [Page 19] 1241Internet-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 12554.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 12724.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 12804.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 1306Sermersheim Expires August 26, 2005 [Page 20] 1307Internet-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 13414.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 13524.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 1370Sermersheim Expires August 26, 2005 [Page 21] 1371Internet-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 13804.4.1 Forming a ChainedRequest 1381 1382 1383 The following fields are populated as instructed: 1384 1385 13864.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 14054.4.1.2 ChainedRequestValue.chainingArguments.referenceType 1406 1407 1408 This is populated with the 1409 ContinuationReference.referralURI.referenceType. 1410 1411 14124.4.1.3 ChainedRequestValue.chainingArguments.traceInformation 1413 1414 1415 This is populated as specified in Section 3.2.1.3. 1416 1417 14184.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 14274.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 1440Sermersheim Expires August 26, 2005 [Page 22] 1441Internet-Draft Distributed Procedures for LDAP Operations February 2005 1442 1443 1444 1445 subtrees) 1446 1447 14484.4.1.6 ChainedRequestValue.operationRequest 1449 1450 1451 This is populated with the original directory operation request. 1452 1453 14544.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 14744.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 14894.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 1505Sermersheim Expires August 26, 2005 [Page 23] 1506Internet-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 15194.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 15274.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 15594.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 1572Sermersheim Expires August 26, 2005 [Page 24] 1573Internet-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 15864.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 15964.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 16124.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 16254.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 1639Sermersheim Expires August 26, 2005 [Page 25] 1640Internet-Draft Distributed Procedures for LDAP Operations February 2005 1641 1642 1643 16444.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 16554.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 16654.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 16734.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 1705Sermersheim Expires August 26, 2005 [Page 26] 1706Internet-Draft Distributed Procedures for LDAP Operations February 2005 1707 1708 1709 17104.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 17244.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 17404.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 17584.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 1770Sermersheim Expires August 26, 2005 [Page 27] 1771Internet-Draft Distributed Procedures for LDAP Operations February 2005 1772 1773 1774 1775 SearchResultReference, etc.). 1776 1777 17784.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 17874.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 18024.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 18184.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 1836Sermersheim Expires August 26, 2005 [Page 28] 1837Internet-Draft Distributed Procedures for LDAP Operations February 2005 1838 1839 1840 18414.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 18504.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 18624.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 18754.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 18964.9.2.6 ContinuationReference.failedName 1897 1898 1899 This field is conveyed as an extension. The extype is 1900 1901 1902 1903 1904Sermersheim Expires August 26, 2005 [Page 29] 1905Internet-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 19144.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 19264.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 1966Sermersheim Expires August 26, 2005 [Page 30] 1967Internet-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 19784.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 20024.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 2031Sermersheim Expires August 26, 2005 [Page 31] 2032Internet-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 2090Sermersheim Expires August 26, 2005 [Page 32] 2091Internet-Draft Distributed Procedures for LDAP Operations February 2005 2092 2093 2094 20955. 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 21156. 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 2159Sermersheim Expires August 26, 2005 [Page 33] 2160Internet-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 2203Author'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 2225Sermersheim Expires August 26, 2005 [Page 34] 2226Internet-Draft Distributed Procedures for LDAP Operations February 2005 2227 2228 2229 2230Appendix A. IANA Considerations 2231 2232 2233 Registration of the following values is requested [RFC3383]. 2234 2235 2236A.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 2261A.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 2290Sermersheim Expires August 26, 2005 [Page 35] 2291Internet-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 2351Sermersheim Expires August 26, 2005 [Page 36] 2352Internet-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 2373A.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 2414Sermersheim Expires August 26, 2005 [Page 37] 2415Internet-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 2439A.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 2475Sermersheim Expires August 26, 2005 [Page 38] 2476Internet-Draft Distributed Procedures for LDAP Operations February 2005 2477 2478 2479 2480Intellectual 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 2509Disclaimer 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 2522Copyright 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 2531Acknowledgment 2532 2533 2534 Funding for the RFC Editor function is currently provided by the 2535 Internet Society. 2536 2537 2538 2539 2540 2541Sermersheim Expires August 26, 2005 [Page 39]