From 622b3711406f2ca2d28bbebcbebebd3577df1f8c Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Wed, 11 Jan 2006 22:03:19 +0000 Subject: [PATCH] trim. to be redesigned. --- .../draft-zeilenga-ldap-grouping-xx.txt | 843 ------------------ doc/drafts/draft-zeilenga-ldap-txn-xx.txt | 395 -------- 2 files changed, 1238 deletions(-) delete mode 100644 doc/drafts/draft-zeilenga-ldap-grouping-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-txn-xx.txt diff --git a/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt b/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt deleted file mode 100644 index 76717f42c6..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 3 May 2003 - - - - LDAP: Grouping of Related Operations - - - -Status of Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial comments - directly to the author . - - Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2003, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - This document provides a general mechanism for grouping related - Lightweight Directory Access Protocol (LDAP) operations. Grouping of - operations can be used to support replication, proxies, and - transactions. - - - - -Zeilenga LDAP Grouping [Page 1] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - -Conventions - - Schema definitions are provided using LDAP description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) for - readability. - - Protocol elements are described using ASN.1 [X.680]. The term - "BER-encoded" means the element is to be encoded using the Basic - Encoding Rules [X.690] under the restrictions detailed in Section 5.1 - of [RFC2251]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - -1. Introduction - - This document provides a general mechanism for grouping related - Lightweight Directory Access Protocol (LDAP) [RFC3377] operations. - Grouping of operations can be used to support replication, proxies, - and high level operations such as transactions [TXNGRP]. - - This document describes a set of LDAP extended operations [RFC2251] - and other protocol and schema elements to support grouping of related - operations. Uses of this grouping mechanism will be detailed in - separate documents. - - A group of operations is defined as a set of operations within a - common session identified by a unique cookie. All requests which are - initiated with the same cookie belong to the same grouping. The - cookie is obtained using the create group operation and is normally - valid until the end group operation is completed. A group can end - prematurely as described below. - - Operations can be intermixed regardless of their grouping (or lack of - grouping). Groups can be nested. - - Each group is of a particular type specified when the group is - created. This type defines the semantics of the group. - - -2. Protocol Elements - - This document describes three extended operations, two unsolicited - notification, and one control. Extended operations and controls are - described by LDAP [RFC2251] and provide here for convenience: - - - - -Zeilenga LDAP Grouping [Page 2] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - ExtendedRequest ::= [APPLICATION 23] SEQUENCE { - requestName [0] LDAPOID, - requestValue [1] OCTET STRING OPTIONAL - } - - ExtendedResponse ::= [APPLICATION 24] SEQUENCE { - COMPONENTS of LDAPResult, - responseName [10] LDAPOID OPTIONAL, - response [11] OCTET STRING OPTIONAL - } - - Control ::= SEQUENCE { - controlType LDAPOID, - criticality BOOLEAN DEFAULT FALSE, - controlValue OCTET STRING OPTIONAL - } - - -2.1 Common Protocol Elements - - groupCookie ::= OCTET STRING - - A groupCookie is an octet string used to uniquely identify a grouping - of related operations within the session. A groupCookie is a - notational convenience. - - -2.2 Create Grouping Operation - - The Create Grouping extended operation is used to create or start a - grouping of related operations. The operation consists of the - createGroupingRequest and the createGroupingResponse. The object - identifier createGroupingOID identifies this operation and SHOULD be - listed as a value of supportedExtension in the root DSE of servers - which support this operation. - - createGroupingOID ::= "IANA-ASSIGNED-OID.1" - - -2.2.1 createGroupingRequest - - The client initiates this operation by sending a - createGroupingRequest. This request is an ExtendedRequest where the - requestName is the object identifier createGroupOID and requestValue - is BER-encoded createGroupingRequestValue: - - createGroupingRequestValue ::= SEQUENCE { - createGroupType [0] LDAPOID, - - - -Zeilenga LDAP Grouping [Page 3] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - createGroupValue [1] OCTET STRING OPTIONAL - } - - where createGroupType is an object identifier that describes the - specific type of grouping and createGroupValue contains a type - specific payload. - - -2.2.2 createGroupingResponse - - The createGroupingResponse is sent in response to a - createGroupingRequest. This response is an ExtendedResponse where the - responseName MUST be the value of the requestName provided in the - request and the response is a BER-encoded createGroupingResponseValue: - - createGroupingResponseValue ::= SEQUENCE { - createGroupCookie [0] groupCookie OPTIONAL, - createGroupValue [1] OCTET STRING OPTIONAL - } - - where createGroupCookie, if present, is a cookie uniquely identifying - the new grouping and createGroupValue is a type specific payload. The - createGroupCookie only when the operation results in the creation of a - group. Otherwise, it is absent. - - -2.3 End Grouping Operation - - The End Grouping extended operation is used to end or stop a grouping - of related operations. The operation consists of the - endGroupingRequest and the endGroupingResponse. The object identifier - endGroupingOID identifies this operation and SHOULD be listed as a - value of supportedExtension in the root DSE of servers which support - this operation. - - endGroupingOID ::= "IANA-ASSIGNED-OID.2" - - -2.3.1 endGroupingRequest - - The client initiates this operation by sending an endGroupingRequest. - This request is an ExtendedRequest where the requestName is the object - identifier endGroupOID and requestValue is BER-encoded - endGroupingRequestValue: - - endGroupingRequestValue ::= SEQUENCE { - endGroupCookie [0] groupCookie, - endGroupValue [1] OCTET STRING OPTIONAL - - - -Zeilenga LDAP Grouping [Page 4] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - } - - where endGroupCookie is a cookie identifying the grouping and - endGroupValue contains a type specific payload. - - -2.3.2 endGroupingResponse - - The endGroupingResponse is sent in response to a endGroupingRequest. - This response is an ExtendedResponse where the responseName MUST be - the value of the requestName provided in request and the response is a - BER-encoded endGroupingResponseValue: - - endGroupingResponseValue ::= SEQUENCE { - endGroupValue [1] OCTET STRING OPTIONAL - } - - where endGroupValue is a type specific payload. - - -2.4 endGroupingNotice - - The endGroupingNotice is an LDAP unsolicited notification. The - notification may be sent to the client to end a grouping which the - server is unable or unwilling to continue to process. The notice is - an extendedResponse where the responseName is the object identifier - endGroupingNoticeOID and the response is a BER-encoded - endGroupingNoticeValue: - - endGroupingNoticeOID ::= "IANA-ASSIGNED-OID.3" - - endGroupingNoticeValue ::= SEQUENCE { - endGroupingCookie [0] groupCookie, - endGroupValue [1] OCTET STRING OPTIONAL - } - - where endGroupingCookie is a cookie uniquely identifying the grouping - and endGroupValue contains a type specific payload. - - -2.5 Action Grouping Operation - - The Action Grouping extended operation is used to take an action - affecting a grouping of related operations. The operation consists of - the actionGroupingRequest and the actionGroupingResponse. The object - identifier actionGroupingOID identifies this operation and SHOULD be - listed as a value of supportedExtension in the root DSE of servers - which support this operation. - - - -Zeilenga LDAP Grouping [Page 5] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - actionGroupingOID ::= "IANA-ASSIGNED-OID.4" - - -2.5.1 actionGroupingRequest - - The client initiates this operation by sending an - actionGroupingRequest. This request is an ExtendedRequest where the - requestName is the object identifier actionGroupOID and requestValue - is BER-encoded actionGroupingRequestValue: - - actionGroupingRequestValue ::= SEQUENCE { - actionGroupCookie [0] groupCookie, - actionGroupValue [1] OCTET STRING OPTIONAL - } - - where actionGroupCookie is a cookie identifying the grouping and - actionGroupValue contains a type specific payload. - - -2.5.2 actionGroupingResponse - - The actionGroupingResponse is sent in response to a - actionGroupingRequest. This response is an ExtendedResponse where the - responseName MUST be the value of the requestName provided in request - and the response is a BER-encoded actionGroupingResponseValue: - - actionGroupingResponseValue ::= SEQUENCE { - actionGroupValue [1] OCTET STRING OPTIONAL - } - - where actionGroupValue is a type specific payload. - - -2.6 infoGroupingNotice - - The infoGroupingNotice is an LDAP unsolicited notification. The - notice may be sent to the client to provide additional grouping type - specific information. The notice is an extendedResponse where the - responseName is the object identifier infoGroupingNoticeOID and the - response is a BER-encoded infoGroupingNoticeValue: - - infoGroupingNoticeOID ::= "IANA-ASSIGNED-OID.5" - - infoGroupingNoticeValue ::= SEQUENCE { - infoGroupingCookie [0] groupCookie, - infoGroupValue [1] OCTET STRING OPTIONAL - } - - - - -Zeilenga LDAP Grouping [Page 6] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - where infoGroupingCookie is a cookie uniquely identifying the grouping - and infoGroupValue contains a type specific payload. - - -2.7 groupingControl - - The groupingControl is used to identify requests and responses as - belonging to a grouping of operations. The groupingControl is a - Control where the controlType is the object identifier - groupingControlOID, the criticality is TRUE, and the controlValue is a - BER-encoded groupingControlValue: - - groupingControlOID ::= "IANA-ASSIGNED-OID.6" - - groupingControlValue ::= SEQUENCE { - groupingCookie [0] groupCookie, - groupValue [1] OCTET STRING OPTIONAL - } - - where groupingCookie is a cookie uniquely identifying the grouping and - groupingValue contains a type specific payload. - - The value groupingControlOID SHOULD be listed as a value of - supportedControl in the root DSE by servers which support this - control. - - The control SHALL NOT appear multiple times in the same LDAP PDU. If - multiple occurrences of the control are detected, the PDU SHALL be - treated as a protocol error. - - -3. Schema Elements - - The document describes one attribute type. - - -3.1. supportedGroupingTypes - - Servers SHOULD publish grouping types they support listing group type - object identifiers as values of the supportedGroupingTypes attribute - type in the root DSE. The supportedGroupingTypes attribute type is - defined as: - - ( IANA-ASSIGNED-OID.7 NAME 'supportedGroupingTypes' - DESC 'supported types of groupings of operations' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) - - - - -Zeilenga LDAP Grouping [Page 7] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - The objectIdentifierMatch and OBJECT IDENTIFIER - (1.3.6.1.4.1.1466.115.121.1.38) are defined in [RFC2252]. - - Servers MUST be capable of recognizing this attribute type by the name - 'supportedGroupingTypes'. Servers MAY recognize the attribute type by - other names. - - -4. Operational Semantics - - This section details the common semantics of groups of related - operations. Additional semantics may be associated with each - grouping type as described by other documents. - - -4.1 Grouping Semantics - - This subsection details semantics of the protocol elements introduced - in Section 2. - - -4.1.1 Create Grouping - - To group related operations, the client MUST request a groupCookie - from the server by sending a createGroupingRequest as described in - Section 2.2.1. The client SHALL provide type specific payload in - createGroupValue if so required by the grouping type. - - The server SHALL respond with a createGroupingResponse as described in - Section 2.2.2. If the server is willing and able to create the - grouping as requested (and per type requirements), it SHALL respond - with success, provide a session-unique groupCookie and, if - appropriate, a type specific payload. Otherwise the server SHALL - respond with a non-successful response containing no groupCookie, but - MAY, if appropriate, provide a type specific payload. - - -4.1.2 End Grouping - - When the client wishes to end the grouping, the client SHALL send a - endGroupingRequest as described in Section 2.3.1. The client SHALL - provide the groupCookie of the grouping to end and MAY provided a type - specific payload. If the grouping to end contains active nested - groupings, these are implicitly ended as well without notice. The - server SHALL respond with an endGroupingResponse as described in - Section 2.3.2. - - - - - -Zeilenga LDAP Grouping [Page 8] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - -4.1.3 End Group Notice - - The server MAY end a group without solicitation for any reason. The - server SHALL notify the client of this action by sending a endGrouping - Notice, as described in Section 2.4. The server SHALL provide the - groupCookie of the group it terminated and MAY provide a type specific - payload. The notice SHALL have a non-success resultCode. - - If the group contains nested groups, the nested groups are implicitly - ended as well without additional notice. - - -4.1.4 Action Grouping - - To perform an action within a group of related operations, the client - sends to the server actionGroupingRequest as described in Section - 2.5.1. The client SHALL provide the groupCookie of the group the - operation is requested upon and, if required by the grouping type, a - type specific payload. - - The server SHALL respond with a actionGroupingResponse as described in - Section 2.5.2. The server SHALL, if required by the grouping type, - provide type specific payload. - - -4.1.5 Info Grouping Notice - - As allowed by the grouping type, the server MAY provide to the client - a notice regarding the grouping of related operations in an - infoGroupingNotice as described in Section 2.6. The server SHALL, if - required by the grouping type, provide type specific payload. - - -4.2 Nested groupings - - Groups of the same or different types MAY be nested. A nested group - is instantiated by providing a groupingControl containing the parent - group's cookie with the createGroupingRequest. - - Group type specifications MAY restrict the types of groupings which - may be nested. Servers MAY also place additional restrictions upon - nesting. Clients SHOULD NOT assume support for arbitrary nesting. - - -4.3 Intermixing of unrelated operations - - LDAP is designed to allow clients to perform unrelated tasks - concurrently. In keeping with this design, operations which unrelated - - - -Zeilenga LDAP Grouping [Page 9] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - to the grouping are generally allowed be intermixed with grouped - operations. (See Section 4.5 for specific exceptions to this general - rule.) It is noted that undue restrictions often unrelated operation - cause unnecessary serialization of independent tasks, place - unnecessary burden upon implementors, and can limit extensibility. - - Group type specifications SHOULD NOT disallow unrelated operations - from being intermixed with grouped operations. - - Note: a grouping which disallows unrelated operatoins from being - intermixed with grouped operations can be viewed as providing - "framing" semantics. - - -4.4 Grouped operations - - Interrogation (compare, search) and update (add, delete, modify, - rename) MAY be grouped. Certain extended operations MAY also be - grouped, but those which affect the session as a whole, such as Start - TLS, MUST NOT be grouped. - - Requests and Responses associated with grouped operations contain a - groupingControl control as described in Section 2.7. - - Group type specifications MAY restrict the kind and/or number of - operations which may be related. Servers MAY place additional - restrictions upon groupings. Clients SHOULD NOT assume support for - arbitrary grouping. - - -4.5 Other Operations - - Upon issuing any grouping operation, the semantics of following - operations listed is modified as described below. - - -4.5.1 abandon - - The abandon operation SHOULD NOT be used to cancel grouped operations. - The Cancel operation is to be used instead (as discussed in 4.5.3). - - -4.5.2 bind - - The client SHOULD end all outstanding groupings before issuing a bind - request. The server SHALL, in addition to the behavior described in - [RFC2251] and [RFC2829], abandon all outstanding groups. No - endGroupingNotice notification is sent upon such abandonment. - - - -Zeilenga LDAP Grouping [Page 10] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - A Bind operation cannot be related to other operations using this - grouping mechanism. The bind messages SHOULD NOT contain - groupingControl controls and, if present, SHALL be treated as a a - protocol error. - - -4.5.3 cancel - - The cancel operation [CANCEL] MAY be used to cancel grouped operations - but SHOULD NOT contain a groupingControl control unless the group type - calls for a type specific payload to be provided. The groupingCookie - in the provided groupingControl control MUST be the same associated - with the operation to be canceled, otherwise the cancel request SHALL - be treated as an error. - - -4.5.4 Start TLS - - The client SHOULD end all outstanding groupings before issuing a Start - TLS [RFC2930] request. If there are any outstanding groupings, the - server MUST return operationsError in response to a StartTLS request. - Start TLS operation cannot be related to other operations using this - grouping mechanism and the Start TLS request and response PDUs SHALL - NOT contain a groupingControl control. - - -4.5.5 unbind - - The server SHALL, in addition to the behavior described in [RFC2251], - abandon all outstanding groups. No endGroupingNotice is sent upon - such abandonment. An unbind operation cannot be related to other - operations using this grouping mechanism. The unbind request SHOULD - NOT contain a groupingControl control and, if present, SHALL be - ignored. - - -5. Profiling Requirements - - Documents detailing extensions using the grouping mechanism MUST - provide a profile of its use of the mechanism. - - The profile SHALL specify the object identifier to be used to uniquely - identify each grouping type it defines. Object identifiers used to - identity group types, like other protocol elements, SHALL be delegated - in accordance with BCP 64 [RFC3383] and registered as LDAP Protocol - Mechanisms [RFC3383] as detailed in Section 7.1 of this document. - - The profile SHALL state which protocol elements of the mechanism it - - - -Zeilenga LDAP Grouping [Page 11] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - uses. - - Each of the grouping protocol elements defined in this document allow - transfer of type specific payloads. For each protocol element used, - the profile SHALL state whether the element is to carry a type - specific payload or not and SHALL fully describe the syntax and - semantics associated with each type specific payload. - - The profile MAY define grouping type specific semantics which place - further restrictions upon the grouping related operations. - - -6. Security Considerations - - This mechanism can be used to support complex groupings of related - operations. With such complexity comes inherit risk. Specifications - of uses of this mechanism should take special care to address security - issues. In particular, denial of service and authentication, - authorization, and access-control issues should be addressed in - documents detailing uses of this grouping mechanism. - - -7. IANA Considerations - -7.1. Future Registration of Grouping Types - - Future specifications which detail LDAP grouping types are to register - each grouping type as a LDAP Protocol Mechanism per guidance given in - BCP 64 [RFC3383]. A usage of "Grouping Type" in a Protocol Mechanism - registration template indicates that the value to be registered is - associated with an LDAP Grouping Type. - - -7.2. Object Identifier Registration - - It is requested that IANA register upon Standards Action an LDAP - Object Identifier to identify protocol elements defined in this - technical specification. The following registration template is - suggested: - - Subject: Request for LDAP OID Registration - Person & email address to contact for further information: - Kurt Zeilenga - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: - Identifies elements of the LDAP Grouping Operation - - - - -Zeilenga LDAP Grouping [Page 12] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - -7.3. LDAP Protocol Mechanism - - It is requested that IANA register upon Standards Action the LDAP - protocol mechanism described in this document. The following - registration template is suggested: - - Subject: Request for LDAP Protocol Mechansism Registration - Object Identifier: IANA-ASSIGNED-OID - Description: See comments - Person & email address to contact for further information: - Kurt Zeilenga - Usage: Extended Operation - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: none - - Object Identifier Type Description - ------------------- ---- ------------------------- - IANA-ASSIGNED-OID.1 E Create Grouping Operation - IANA-ASSIGNED-OID.2 E End Grouping Operation - IANA-ASSIGNED-OID.4 E Action Grouping Operation - - in 2 - - -7.4. supportedGroupingTypes Registration - - It is requested that IANA register upon Standards Action the LDAP - 'supportedGroupingTypes' descriptor. The following registration - template is suggested: - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): supportedGroupingTypes - Object Identifier: IANA-ASSIGNED-OID.7 - Person & email address to contact for further information: - Kurt Zeilenga - Usage: Attribute Type - Specification: RFCXXXX - Author/Change Controller: IESG - - -8. Acknowledgments - - The author gratefully acknowledges the contributions of the IETF - LDAPext and LDUP working groups. In particular, Roger Harrison - provided many useful suggestions. Also, the author notes that this - document builds upon the early works "Extended Operations for Framing - LDAP Operations" by Ellen Stokes, Roger Harrison, and Gordon Good and - - - -Zeilenga LDAP Grouping [Page 13] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - "Profile for Framing LDAPv3 Operations" by Roger Harrison. - - -9. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -10. References - -10.1 Normative References - - [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax - Definitions", RFC 2252, December 1997. - - [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, - "Authentication Methods for LDAP", RFC 2829, May 2000. - - [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory - Access Protocol (v3): Extension for Transport Layer - Security", RFC 2830, May 2000. - - [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, - September 2002. - - [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also - RFC 3383), September 2002. - - [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - - Specification of Basic Notation", X.680, 1994. - - [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, - Canonical, and Distinguished Encoding Rules", X.690, 1994. - - -10.2. Informative References - - [TXNGRP] K. Zeilenga, "LDAP Transactions" (a work in progress), - - - -Zeilenga LDAP Grouping [Page 14] - -INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003 - - - draft-zeilenga-ldap-txn-xx.txt. - - -Copyright 2003, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga LDAP Grouping [Page 15] - diff --git a/doc/drafts/draft-zeilenga-ldap-txn-xx.txt b/doc/drafts/draft-zeilenga-ldap-txn-xx.txt deleted file mode 100644 index a9683c5d29..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-txn-xx.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Experimental OpenLDAP Foundation -Expires in six months 3 May 2003 - - - LDAP Transactions - - - -Status of Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as an Experimental document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial comments - directly to the author . - - Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2003, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - Lightweight Directory Access Protocol (LDAP) update operations acting - upon entries have atomic, consistency, isolation, durability (ACID) - properties. However, it is often desirable to update two or more - entries as one unit of interaction, a transaction. Transactions are - necessary to support a number of applications including resource - provisioning and information replication. This document defines an - - - -Zeilenga LDAP Transactions [Page 1] - -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 - - - LDAP extension to support transactions. - - -Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - Protocol elements are described using ASN.1 [X.680]. The term - "BER-encoded" means the element is to be encoded using the Basic - Encoding Rules [X.690] under the restrictions detailed in Section 5.1 - of [RFC2251]. - - -1. Overview - - This document extends the Lightweight Directory Access Protocol (LDAP) - [RFC3377] to allow clients to group a number of related update - operations [RFC2251] and have them preformed as one unit of - interaction, a transaction. As with distinct update operations, each - transaction has atomic, consistency, isolation, and durability - ([ACID]) properties. - - This extension uses the grouping mechanism provided by [GROUP] to - relate operations of the transaction. The createGrouping operation is - used to obtain a group cookie which is used to identify operations - which are apart of the transaction. The group cookie can be viewed as - a transaction identifier. The endGrouping operation is used to settle - (commit or abort) the transaction. - - -2. Specification of a Transaction - - Servers implementing this specification SHOULD publish the - transactionGroupingType as a value of the 'supportedGroupingTypes' - attribute contained within the Root DSE. - - transactionGroupingType ::= IANA-ASSIGNED-OID - - A client wishing to preform a transaction issues a - createGroupingRequest with a createGroupType of - transactionGroupingType and no createGroupValue. A server which is - willing and able to support transactions returns a - createGroupingResponse with a success result code, a - createGroupCookie, and no createGroupValue. Otherwise the server - returns a non-success result code, no createGroupCookie, and no - createGroupValue. - - - -Zeilenga LDAP Transactions [Page 2] - -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 - - - The client then issues may issue one or more update (add, delete, - modify, rename) requests, each with a GroupingControl indicating they - are to processed as part of the transaction grouping. If the server - is willing and able to attempt to process operation as part of the - transaction, the server returns success. As further processing of the - operation is be deferred until settlement, the operation is considered - still outstanding and its messageID cannot to be reused until after - settlement. If the server is unwilling or unable to attempt to - process the operation as part of the transaction, the server returns a - non-successful result code. - - If the server becomes unwilling or unable to continue the - specification of a transaction, the server return the canceled - resultCode for each deferred operation and then issue a endGroupNotice - with a non-success resultCode. Any future use of cookie by the client - will result in a response containing a non-success result code. Upon - receipt of a endGroupingNotice, the client is to discontinue all use - of the grouping cookie as the transaction is null and void. - - A client requests settling of transaction by issuing an - endGroupingRequest where the groupingCookie is the group cookie - identify the transaction. The absence of any endGroupingValue - indicates a commit request. The presence of an empty endGroupValue - indicates an abort request. The endGroupValue MUST be empty if - provided. - - If the commit response indicates failure, the server may return an - endGroupingValue with the endGroupingResponse. If so, it contains the - BER-encoding of a MessageID [RFC2251] of the update operation - associated with the failure. - - -3. Settling of the Transaction - - Upon receipt of a request to abort the transaction, the server is to - abort the transaction and then return an endGroupingResponse - indicating success. - - Upon receipt of a request to commit the transaction, the server - processes the group of update operations as one atomic, isolated - action with each update request being processed in turn. Either all - of the requested updates SHALL be successfully applied or none of the - requested SHALL be applied. If all are applied, the server returns an - endGroupingResponse indicating success. Otherwise, the server returns - an endGroupingResponse indicating the nature of the failure. If the - failure is associated with a particular update operation, the message - ID is returned an attached endGroupingValue. If the failure was not - associated with any particular update operation, no endGroupingValue - - - -Zeilenga LDAP Transactions [Page 3] - -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 - - - is to be provided. - - There is no requirement that a server serialize transactions. That - is, a server MAY process multiple transactions commit requests (from - one or more clients) acting upon different sets of entries - concurrently. A server MUST avoid deadlock. - - -4. Distributed Directory Considerations - - The LDAP/X.500 models provide for distributed directory operations - including server-side chaining and client-side chasing of operations. - - This document does not disallow servers from chaining operations which - are part of a transaction. However, if a server does allow such - chaining, it MUST ensure that transaction semantics detailed above are - provided. - - This mechanism defined by this document does not support client-side - chasing. Grouping cookies used to identify the transaction are - specific to a particular client/server session. - - The LDAP/X.500 models provide for a single-master/multiple-slave - replication architecture. This document states no requirement that - changes made to the directory based upon processing a transaction be - replicated as one atomic action. That is, the client SHOULD NOT - assume tight data consistency nor fast data convergence at slave - servers unless they have prior knowledge that such is provided. - Though this mechanism could be used to support replication, such use - is not described in this document. - - The LDAP/X.500 models do not currently support a multi-master - replication architecture and, hence, not considered by this - specification. - - -5. Security Considerations - - Transactions mechanisms and related grouping operations may be the - target of denial of service attacks. Implementors should provide - safeguards to ensure these mechanisms are not abused. - - -6. IANA Considerations - - In accordance with [RFC3383], it is requested that Internet Assigned - Numbers Authority (IANA) make the following assignments. - - - - -Zeilenga LDAP Transactions [Page 4] - -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 - - -6.1. Object Identifier - - An LDAP Object Identifier to identify the grouping type defined in - this document is requested. - - The following registration template is suggested: - - Subject: Request for LDAP Object Identifier Registration - Person & email address to contact for further information: - Kurt Zeilenga - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: - Identifies the LDAP Transactions Grouping Type - - -6.2. LDAP Protocol Mechanism - - Registration of the protocol mechanisms defined in this document is - requested. - - Subject: Request for LDAP Protocol Mechansism Registration - - Object Identifier: IANA-ASSIGNED-OID - Description: LDAP Transaction Grouping Type - Person & email address to contact for further information: - Kurt Zeilenga - Usage: Grouping - Specification: RFCxxxx - Author/Change Controller: IESG - Comments: none - - -7. Acknowledgments - - The author gratefully acknowledges the contributions made by members - of the Internet Engineering Task Force. - - -8. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -9. Normative References - - - - -Zeilenga LDAP Transactions [Page 5] - -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 - - - [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, September 2002. - - [GROUP] K. Zeilenga, "LDAP: Grouping of Related Operations", - draft-zeilenga-ldap-grouping-xx.txt, a work in progress. - - [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification - of Basic Notation", X.680, 1994. - - [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, - Canonical, and Distinguished Encoding Rules", X.690, 1994. - - -10. Informative References - - [ACID] Section 4 of ISO/IEC 10026-1:1992. - - [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also - RFC 3383), September 2002. - - [X.500] ITU-T, "The Directory: Overview of Concepts, Models, and - Services", X.500, 1993. - - [X.501] ITU-T, "The Directory: Models", X.501, 1993. - - -Copyright 2003, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished - to others, and derivative works that comment on or otherwise explain - it or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, - this document itself may not be modified in any way, such as by - removing the copyright notice or references to the Internet Society - or other Internet organizations, except as needed for the purpose - of developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not - - - -Zeilenga LDAP Transactions [Page 6] - -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 - - - be revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on - an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE - INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE - OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga LDAP Transactions [Page 7] - -- 2.39.5