idnits 2.17.1 draft-zeilenga-ldap-grouping-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC2251], [RFC2252]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 642 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (3 May 2003) is 7661 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'APPLICATION 23' is mentioned on line 92, but not defined -- Looks like a reference, but probably isn't: '0' on line 288 -- Looks like a reference, but probably isn't: '1' on line 289 == Missing Reference: 'APPLICATION 24' is mentioned on line 97, but not defined -- Looks like a reference, but probably isn't: '10' on line 99 -- Looks like a reference, but probably isn't: '11' on line 100 == Missing Reference: 'CANCEL' is mentioned on line 458, but not defined == Missing Reference: 'RFC2930' is mentioned on line 468, but not defined == Unused Reference: 'RFC2830' is defined on line 611, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2829 (Obsoleted by RFC 4510, RFC 4513) ** Obsolete normative reference: RFC 2830 (Obsoleted by RFC 4510, RFC 4511, RFC 4513) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 3 May 2003 6 LDAP: Grouping of Related Operations 7 9 Status of Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is intended to be, after appropriate review and 15 revision, submitted to the RFC Editor as a Standard Track document. 16 Distribution of this memo is unlimited. Technical discussion of this 17 document will take place on the IETF LDAP Extension Working Group 18 mailing list . Please send editorial comments 19 directly to the author . 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 . The list of 31 Internet-Draft Shadow Directories can be accessed at 32 . 34 Copyright 2003, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Abstract 41 This document provides a general mechanism for grouping related 42 Lightweight Directory Access Protocol (LDAP) operations. Grouping of 43 operations can be used to support replication, proxies, and 44 transactions. 46 Conventions 48 Schema definitions are provided using LDAP description formats 49 [RFC2252]. Definitions provided here are formatted (line wrapped) for 50 readability. 52 Protocol elements are described using ASN.1 [X.680]. The term 53 "BER-encoded" means the element is to be encoded using the Basic 54 Encoding Rules [X.690] under the restrictions detailed in Section 5.1 55 of [RFC2251]. 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in BCP 14 [RFC2119]. 61 1. Introduction 63 This document provides a general mechanism for grouping related 64 Lightweight Directory Access Protocol (LDAP) [RFC3377] operations. 65 Grouping of operations can be used to support replication, proxies, 66 and high level operations such as transactions [TXNGRP]. 68 This document describes a set of LDAP extended operations [RFC2251] 69 and other protocol and schema elements to support grouping of related 70 operations. Uses of this grouping mechanism will be detailed in 71 separate documents. 73 A group of operations is defined as a set of operations within a 74 common session identified by a unique cookie. All requests which are 75 initiated with the same cookie belong to the same grouping. The 76 cookie is obtained using the create group operation and is normally 77 valid until the end group operation is completed. A group can end 78 prematurely as described below. 80 Operations can be intermixed regardless of their grouping (or lack of 81 grouping). Groups can be nested. 83 Each group is of a particular type specified when the group is 84 created. This type defines the semantics of the group. 86 2. Protocol Elements 88 This document describes three extended operations, two unsolicited 89 notification, and one control. Extended operations and controls are 90 described by LDAP [RFC2251] and provide here for convenience: 92 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 93 requestName [0] LDAPOID, 94 requestValue [1] OCTET STRING OPTIONAL 95 } 97 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 98 COMPONENTS of LDAPResult, 99 responseName [10] LDAPOID OPTIONAL, 100 response [11] OCTET STRING OPTIONAL 101 } 103 Control ::= SEQUENCE { 104 controlType LDAPOID, 105 criticality BOOLEAN DEFAULT FALSE, 106 controlValue OCTET STRING OPTIONAL 107 } 109 2.1 Common Protocol Elements 111 groupCookie ::= OCTET STRING 113 A groupCookie is an octet string used to uniquely identify a grouping 114 of related operations within the session. A groupCookie is a 115 notational convenience. 117 2.2 Create Grouping Operation 119 The Create Grouping extended operation is used to create or start a 120 grouping of related operations. The operation consists of the 121 createGroupingRequest and the createGroupingResponse. The object 122 identifier createGroupingOID identifies this operation and SHOULD be 123 listed as a value of supportedExtension in the root DSE of servers 124 which support this operation. 126 createGroupingOID ::= "IANA-ASSIGNED-OID.1" 128 2.2.1 createGroupingRequest 130 The client initiates this operation by sending a 131 createGroupingRequest. This request is an ExtendedRequest where the 132 requestName is the object identifier createGroupOID and requestValue 133 is BER-encoded createGroupingRequestValue: 135 createGroupingRequestValue ::= SEQUENCE { 136 createGroupType [0] LDAPOID, 137 createGroupValue [1] OCTET STRING OPTIONAL 138 } 140 where createGroupType is an object identifier that describes the 141 specific type of grouping and createGroupValue contains a type 142 specific payload. 144 2.2.2 createGroupingResponse 146 The createGroupingResponse is sent in response to a 147 createGroupingRequest. This response is an ExtendedResponse where the 148 responseName MUST be the value of the requestName provided in the 149 request and the response is a BER-encoded createGroupingResponseValue: 151 createGroupingResponseValue ::= SEQUENCE { 152 createGroupCookie [0] groupCookie OPTIONAL, 153 createGroupValue [1] OCTET STRING OPTIONAL 154 } 156 where createGroupCookie, if present, is a cookie uniquely identifying 157 the new grouping and createGroupValue is a type specific payload. The 158 createGroupCookie only when the operation results in the creation of a 159 group. Otherwise, it is absent. 161 2.3 End Grouping Operation 163 The End Grouping extended operation is used to end or stop a grouping 164 of related operations. The operation consists of the 165 endGroupingRequest and the endGroupingResponse. The object identifier 166 endGroupingOID identifies this operation and SHOULD be listed as a 167 value of supportedExtension in the root DSE of servers which support 168 this operation. 170 endGroupingOID ::= "IANA-ASSIGNED-OID.2" 172 2.3.1 endGroupingRequest 174 The client initiates this operation by sending an endGroupingRequest. 175 This request is an ExtendedRequest where the requestName is the object 176 identifier endGroupOID and requestValue is BER-encoded 177 endGroupingRequestValue: 179 endGroupingRequestValue ::= SEQUENCE { 180 endGroupCookie [0] groupCookie, 181 endGroupValue [1] OCTET STRING OPTIONAL 183 } 185 where endGroupCookie is a cookie identifying the grouping and 186 endGroupValue contains a type specific payload. 188 2.3.2 endGroupingResponse 190 The endGroupingResponse is sent in response to a endGroupingRequest. 191 This response is an ExtendedResponse where the responseName MUST be 192 the value of the requestName provided in request and the response is a 193 BER-encoded endGroupingResponseValue: 195 endGroupingResponseValue ::= SEQUENCE { 196 endGroupValue [1] OCTET STRING OPTIONAL 197 } 199 where endGroupValue is a type specific payload. 201 2.4 endGroupingNotice 203 The endGroupingNotice is an LDAP unsolicited notification. The 204 notification may be sent to the client to end a grouping which the 205 server is unable or unwilling to continue to process. The notice is 206 an extendedResponse where the responseName is the object identifier 207 endGroupingNoticeOID and the response is a BER-encoded 208 endGroupingNoticeValue: 210 endGroupingNoticeOID ::= "IANA-ASSIGNED-OID.3" 212 endGroupingNoticeValue ::= SEQUENCE { 213 endGroupingCookie [0] groupCookie, 214 endGroupValue [1] OCTET STRING OPTIONAL 215 } 217 where endGroupingCookie is a cookie uniquely identifying the grouping 218 and endGroupValue contains a type specific payload. 220 2.5 Action Grouping Operation 222 The Action Grouping extended operation is used to take an action 223 affecting a grouping of related operations. The operation consists of 224 the actionGroupingRequest and the actionGroupingResponse. The object 225 identifier actionGroupingOID identifies this operation and SHOULD be 226 listed as a value of supportedExtension in the root DSE of servers 227 which support this operation. 229 actionGroupingOID ::= "IANA-ASSIGNED-OID.4" 231 2.5.1 actionGroupingRequest 233 The client initiates this operation by sending an 234 actionGroupingRequest. This request is an ExtendedRequest where the 235 requestName is the object identifier actionGroupOID and requestValue 236 is BER-encoded actionGroupingRequestValue: 238 actionGroupingRequestValue ::= SEQUENCE { 239 actionGroupCookie [0] groupCookie, 240 actionGroupValue [1] OCTET STRING OPTIONAL 241 } 243 where actionGroupCookie is a cookie identifying the grouping and 244 actionGroupValue contains a type specific payload. 246 2.5.2 actionGroupingResponse 248 The actionGroupingResponse is sent in response to a 249 actionGroupingRequest. This response is an ExtendedResponse where the 250 responseName MUST be the value of the requestName provided in request 251 and the response is a BER-encoded actionGroupingResponseValue: 253 actionGroupingResponseValue ::= SEQUENCE { 254 actionGroupValue [1] OCTET STRING OPTIONAL 255 } 257 where actionGroupValue is a type specific payload. 259 2.6 infoGroupingNotice 261 The infoGroupingNotice is an LDAP unsolicited notification. The 262 notice may be sent to the client to provide additional grouping type 263 specific information. The notice is an extendedResponse where the 264 responseName is the object identifier infoGroupingNoticeOID and the 265 response is a BER-encoded infoGroupingNoticeValue: 267 infoGroupingNoticeOID ::= "IANA-ASSIGNED-OID.5" 269 infoGroupingNoticeValue ::= SEQUENCE { 270 infoGroupingCookie [0] groupCookie, 271 infoGroupValue [1] OCTET STRING OPTIONAL 272 } 274 where infoGroupingCookie is a cookie uniquely identifying the grouping 275 and infoGroupValue contains a type specific payload. 277 2.7 groupingControl 279 The groupingControl is used to identify requests and responses as 280 belonging to a grouping of operations. The groupingControl is a 281 Control where the controlType is the object identifier 282 groupingControlOID, the criticality is TRUE, and the controlValue is a 283 BER-encoded groupingControlValue: 285 groupingControlOID ::= "IANA-ASSIGNED-OID.6" 287 groupingControlValue ::= SEQUENCE { 288 groupingCookie [0] groupCookie, 289 groupValue [1] OCTET STRING OPTIONAL 290 } 292 where groupingCookie is a cookie uniquely identifying the grouping and 293 groupingValue contains a type specific payload. 295 The value groupingControlOID SHOULD be listed as a value of 296 supportedControl in the root DSE by servers which support this 297 control. 299 The control SHALL NOT appear multiple times in the same LDAP PDU. If 300 multiple occurrences of the control are detected, the PDU SHALL be 301 treated as a protocol error. 303 3. Schema Elements 305 The document describes one attribute type. 307 3.1. supportedGroupingTypes 309 Servers SHOULD publish grouping types they support listing group type 310 object identifiers as values of the supportedGroupingTypes attribute 311 type in the root DSE. The supportedGroupingTypes attribute type is 312 defined as: 314 ( IANA-ASSIGNED-OID.7 NAME 'supportedGroupingTypes' 315 DESC 'supported types of groupings of operations' 316 EQUALITY objectIdentifierMatch 317 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) 319 The objectIdentifierMatch and OBJECT IDENTIFIER 320 (1.3.6.1.4.1.1466.115.121.1.38) are defined in [RFC2252]. 322 Servers MUST be capable of recognizing this attribute type by the name 323 'supportedGroupingTypes'. Servers MAY recognize the attribute type by 324 other names. 326 4. Operational Semantics 328 This section details the common semantics of groups of related 329 operations. Additional semantics may be associated with each 330 grouping type as described by other documents. 332 4.1 Grouping Semantics 334 This subsection details semantics of the protocol elements introduced 335 in Section 2. 337 4.1.1 Create Grouping 339 To group related operations, the client MUST request a groupCookie 340 from the server by sending a createGroupingRequest as described in 341 Section 2.2.1. The client SHALL provide type specific payload in 342 createGroupValue if so required by the grouping type. 344 The server SHALL respond with a createGroupingResponse as described in 345 Section 2.2.2. If the server is willing and able to create the 346 grouping as requested (and per type requirements), it SHALL respond 347 with success, provide a session-unique groupCookie and, if 348 appropriate, a type specific payload. Otherwise the server SHALL 349 respond with a non-successful response containing no groupCookie, but 350 MAY, if appropriate, provide a type specific payload. 352 4.1.2 End Grouping 354 When the client wishes to end the grouping, the client SHALL send a 355 endGroupingRequest as described in Section 2.3.1. The client SHALL 356 provide the groupCookie of the grouping to end and MAY provided a type 357 specific payload. If the grouping to end contains active nested 358 groupings, these are implicitly ended as well without notice. The 359 server SHALL respond with an endGroupingResponse as described in 360 Section 2.3.2. 362 4.1.3 End Group Notice 364 The server MAY end a group without solicitation for any reason. The 365 server SHALL notify the client of this action by sending a endGrouping 366 Notice, as described in Section 2.4. The server SHALL provide the 367 groupCookie of the group it terminated and MAY provide a type specific 368 payload. The notice SHALL have a non-success resultCode. 370 If the group contains nested groups, the nested groups are implicitly 371 ended as well without additional notice. 373 4.1.4 Action Grouping 375 To perform an action within a group of related operations, the client 376 sends to the server actionGroupingRequest as described in Section 377 2.5.1. The client SHALL provide the groupCookie of the group the 378 operation is requested upon and, if required by the grouping type, a 379 type specific payload. 381 The server SHALL respond with a actionGroupingResponse as described in 382 Section 2.5.2. The server SHALL, if required by the grouping type, 383 provide type specific payload. 385 4.1.5 Info Grouping Notice 387 As allowed by the grouping type, the server MAY provide to the client 388 a notice regarding the grouping of related operations in an 389 infoGroupingNotice as described in Section 2.6. The server SHALL, if 390 required by the grouping type, provide type specific payload. 392 4.2 Nested groupings 394 Groups of the same or different types MAY be nested. A nested group 395 is instantiated by providing a groupingControl containing the parent 396 group's cookie with the createGroupingRequest. 398 Group type specifications MAY restrict the types of groupings which 399 may be nested. Servers MAY also place additional restrictions upon 400 nesting. Clients SHOULD NOT assume support for arbitrary nesting. 402 4.3 Intermixing of unrelated operations 404 LDAP is designed to allow clients to perform unrelated tasks 405 concurrently. In keeping with this design, operations which unrelated 406 to the grouping are generally allowed be intermixed with grouped 407 operations. (See Section 4.5 for specific exceptions to this general 408 rule.) It is noted that undue restrictions often unrelated operation 409 cause unnecessary serialization of independent tasks, place 410 unnecessary burden upon implementors, and can limit extensibility. 412 Group type specifications SHOULD NOT disallow unrelated operations 413 from being intermixed with grouped operations. 415 Note: a grouping which disallows unrelated operatoins from being 416 intermixed with grouped operations can be viewed as providing 417 "framing" semantics. 419 4.4 Grouped operations 421 Interrogation (compare, search) and update (add, delete, modify, 422 rename) MAY be grouped. Certain extended operations MAY also be 423 grouped, but those which affect the session as a whole, such as Start 424 TLS, MUST NOT be grouped. 426 Requests and Responses associated with grouped operations contain a 427 groupingControl control as described in Section 2.7. 429 Group type specifications MAY restrict the kind and/or number of 430 operations which may be related. Servers MAY place additional 431 restrictions upon groupings. Clients SHOULD NOT assume support for 432 arbitrary grouping. 434 4.5 Other Operations 436 Upon issuing any grouping operation, the semantics of following 437 operations listed is modified as described below. 439 4.5.1 abandon 441 The abandon operation SHOULD NOT be used to cancel grouped operations. 442 The Cancel operation is to be used instead (as discussed in 4.5.3). 444 4.5.2 bind 446 The client SHOULD end all outstanding groupings before issuing a bind 447 request. The server SHALL, in addition to the behavior described in 448 [RFC2251] and [RFC2829], abandon all outstanding groups. No 449 endGroupingNotice notification is sent upon such abandonment. 451 A Bind operation cannot be related to other operations using this 452 grouping mechanism. The bind messages SHOULD NOT contain 453 groupingControl controls and, if present, SHALL be treated as a a 454 protocol error. 456 4.5.3 cancel 458 The cancel operation [CANCEL] MAY be used to cancel grouped operations 459 but SHOULD NOT contain a groupingControl control unless the group type 460 calls for a type specific payload to be provided. The groupingCookie 461 in the provided groupingControl control MUST be the same associated 462 with the operation to be canceled, otherwise the cancel request SHALL 463 be treated as an error. 465 4.5.4 Start TLS 467 The client SHOULD end all outstanding groupings before issuing a Start 468 TLS [RFC2930] request. If there are any outstanding groupings, the 469 server MUST return operationsError in response to a StartTLS request. 470 Start TLS operation cannot be related to other operations using this 471 grouping mechanism and the Start TLS request and response PDUs SHALL 472 NOT contain a groupingControl control. 474 4.5.5 unbind 476 The server SHALL, in addition to the behavior described in [RFC2251], 477 abandon all outstanding groups. No endGroupingNotice is sent upon 478 such abandonment. An unbind operation cannot be related to other 479 operations using this grouping mechanism. The unbind request SHOULD 480 NOT contain a groupingControl control and, if present, SHALL be 481 ignored. 483 5. Profiling Requirements 485 Documents detailing extensions using the grouping mechanism MUST 486 provide a profile of its use of the mechanism. 488 The profile SHALL specify the object identifier to be used to uniquely 489 identify each grouping type it defines. Object identifiers used to 490 identity group types, like other protocol elements, SHALL be delegated 491 in accordance with BCP 64 [RFC3383] and registered as LDAP Protocol 492 Mechanisms [RFC3383] as detailed in Section 7.1 of this document. 494 The profile SHALL state which protocol elements of the mechanism it 495 uses. 497 Each of the grouping protocol elements defined in this document allow 498 transfer of type specific payloads. For each protocol element used, 499 the profile SHALL state whether the element is to carry a type 500 specific payload or not and SHALL fully describe the syntax and 501 semantics associated with each type specific payload. 503 The profile MAY define grouping type specific semantics which place 504 further restrictions upon the grouping related operations. 506 6. Security Considerations 508 This mechanism can be used to support complex groupings of related 509 operations. With such complexity comes inherit risk. Specifications 510 of uses of this mechanism should take special care to address security 511 issues. In particular, denial of service and authentication, 512 authorization, and access-control issues should be addressed in 513 documents detailing uses of this grouping mechanism. 515 7. IANA Considerations 517 7.1. Future Registration of Grouping Types 519 Future specifications which detail LDAP grouping types are to register 520 each grouping type as a LDAP Protocol Mechanism per guidance given in 521 BCP 64 [RFC3383]. A usage of "Grouping Type" in a Protocol Mechanism 522 registration template indicates that the value to be registered is 523 associated with an LDAP Grouping Type. 525 7.2. Object Identifier Registration 527 It is requested that IANA register upon Standards Action an LDAP 528 Object Identifier to identify protocol elements defined in this 529 technical specification. The following registration template is 530 suggested: 532 Subject: Request for LDAP OID Registration 533 Person & email address to contact for further information: 534 Kurt Zeilenga 535 Specification: RFCXXXX 536 Author/Change Controller: IESG 537 Comments: 538 Identifies elements of the LDAP Grouping Operation 540 7.3. LDAP Protocol Mechanism 542 It is requested that IANA register upon Standards Action the LDAP 543 protocol mechanism described in this document. The following 544 registration template is suggested: 546 Subject: Request for LDAP Protocol Mechansism Registration 547 Object Identifier: IANA-ASSIGNED-OID 548 Description: See comments 549 Person & email address to contact for further information: 550 Kurt Zeilenga 551 Usage: Extended Operation 552 Specification: RFCXXXX 553 Author/Change Controller: IESG 554 Comments: none 556 Object Identifier Type Description 557 ------------------- ---- ------------------------- 558 IANA-ASSIGNED-OID.1 E Create Grouping Operation 559 IANA-ASSIGNED-OID.2 E End Grouping Operation 560 IANA-ASSIGNED-OID.4 E Action Grouping Operation 562 in 2 564 7.4. supportedGroupingTypes Registration 566 It is requested that IANA register upon Standards Action the LDAP 567 'supportedGroupingTypes' descriptor. The following registration 568 template is suggested: 570 Subject: Request for LDAP Descriptor Registration 571 Descriptor (short name): supportedGroupingTypes 572 Object Identifier: IANA-ASSIGNED-OID.7 573 Person & email address to contact for further information: 574 Kurt Zeilenga 575 Usage: Attribute Type 576 Specification: RFCXXXX 577 Author/Change Controller: IESG 579 8. Acknowledgments 581 The author gratefully acknowledges the contributions of the IETF 582 LDAPext and LDUP working groups. In particular, Roger Harrison 583 provided many useful suggestions. Also, the author notes that this 584 document builds upon the early works "Extended Operations for Framing 585 LDAP Operations" by Ellen Stokes, Roger Harrison, and Gordon Good and 586 "Profile for Framing LDAPv3 Operations" by Roger Harrison. 588 9. Author's Address 590 Kurt D. Zeilenga 591 OpenLDAP Foundation 592 594 10. References 596 10.1 Normative References 598 [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate 599 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 601 [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 602 Protocol (v3)", RFC 2251, December 1997. 604 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 605 Directory Access Protocol (v3): Attribute Syntax 606 Definitions", RFC 2252, December 1997. 608 [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, 609 "Authentication Methods for LDAP", RFC 2829, May 2000. 611 [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory 612 Access Protocol (v3): Extension for Transport Layer 613 Security", RFC 2830, May 2000. 615 [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access 616 Protocol (v3): Technical Specification", RFC 3377, 617 September 2002. 619 [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also 620 RFC 3383), September 2002. 622 [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - 623 Specification of Basic Notation", X.680, 1994. 625 [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, 626 Canonical, and Distinguished Encoding Rules", X.690, 1994. 628 10.2. Informative References 630 [TXNGRP] K. Zeilenga, "LDAP Transactions" (a work in progress), 632 Copyright 2003, The Internet Society. All Rights Reserved. 634 This document and translations of it may be copied and furnished to 635 others, and derivative works that comment on or otherwise explain it 636 or assist in its implementation may be prepared, copied, published and 637 distributed, in whole or in part, without restriction of any kind, 638 provided that the above copyright notice and this paragraph are 639 included on all such copies and derivative works. However, this 640 document itself may not be modified in any way, such as by removing 641 the copyright notice or references to the Internet Society or other 642 Internet organizations, except as needed for the purpose of 643 developing Internet standards in which case the procedures for 644 copyrights defined in the Internet Standards process must be followed, 645 or as required to translate it into languages other than English. 647 The limited permissions granted above are perpetual and will not be 648 revoked by the Internet Society or its successors or assigns. 650 This document and the information contained herein is provided on an 651 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 652 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 653 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 654 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 655 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.