From: Kurt Zeilenga Date: Mon, 6 Mar 2006 20:55:11 +0000 (+0000) Subject: I-D updates X-Git-Tag: OPENLDAP_REL_ENG_2_4_BP~146 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=f43cb38485559b1066e56f4d69d4cd15fb6f5f9a;p=openldap I-D updates --- diff --git a/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt b/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt index 495ea5cc93..84065c8dfc 100644 --- a/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt +++ b/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt @@ -6,12 +6,12 @@ INTERNET-DRAFT Kurt D. Zeilenga Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 17 July 2005 +Expires in six months 5 March 2006 The LDAP Don't Use Copy Control - + Status of this Memo @@ -44,7 +44,7 @@ Status of this Memo http://www.ietf.org/shadow.html - Copyright (C) The Internet Society (2005). All Rights Reserved. + Copyright (C) The Internet Society (2006). All Rights Reserved. Please see the Full Copyright section near the end of this document for more information. @@ -57,7 +57,7 @@ Status of this Memo Zeilenga LDAP Don't Use Copy Control [Page 1] -INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005 +INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006 Abstract @@ -96,8 +96,7 @@ Abstract The Don't Use Copy control is an LDAP Control [Protocol] whose controlType is IANA-ASSIGNED-OID and controlValue is absent. The - criticality may be TRUE or FALSE. There is no corresponding response - control. + criticality MUST be TRUE. There is no corresponding response control. The control is appropriate for both LDAP interrogation operations, including Compare and Search operations [Protocol]. It is @@ -108,15 +107,15 @@ Abstract operation MUST NOT be performed on copied information. That is, the requested operation MUST be performed on original information. + If original information for the target or base object of the operation Zeilenga LDAP Don't Use Copy Control [Page 2] -INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005 +INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006 - If original information for the target or base object of the operation is not available (either locally or through chaining), the server MUST either return a referral directing the client to a server believed to be better able to service the request or return an appropriate result @@ -164,15 +163,15 @@ INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005 Person & email address to contact for further information: Kurt Zeilenga Usage: Control + Specification: RFC XXXX Zeilenga LDAP Don't Use Copy Control [Page 3] -INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005 +INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006 - Specification: RFC XXXX Author/Change Controller: IESG Comments: none @@ -223,9 +222,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005 + Zeilenga LDAP Don't Use Copy Control [Page 4] -INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005 +INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006 Intellectual Property Rights @@ -256,7 +256,7 @@ Intellectual Property Rights Full Copyright - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors 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-noop-xx.txt b/doc/drafts/draft-zeilenga-ldap-noop-xx.txt index c0a30b58be..100a845bb6 100644 --- a/doc/drafts/draft-zeilenga-ldap-noop-xx.txt +++ b/doc/drafts/draft-zeilenga-ldap-noop-xx.txt @@ -6,12 +6,12 @@ INTERNET-DRAFT Kurt D. Zeilenga Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 28 October 2005 +Expires in six months 5 March 2006 The LDAP No-Op Control - + Status of this Memo @@ -44,7 +44,7 @@ Status of this Memo http://www.ietf.org/shadow.html - Copyright (C) The Internet Society (2005). All Rights Reserved. + Copyright (C) The Internet Society (2006). All Rights Reserved. Please see the Full Copyright section near the end of this document for more information. @@ -57,7 +57,7 @@ Status of this Memo Zeilenga LDAP No-Op Control [Page 1] -INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005 +INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006 Abstract @@ -113,7 +113,7 @@ Abstract Zeilenga LDAP No-Op Control [Page 2] -INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005 +INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006 2. No-Op Control @@ -169,7 +169,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005 Zeilenga LDAP No-Op Control [Page 3] -INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005 +INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006 4. IANA Considerations @@ -225,7 +225,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005 Zeilenga LDAP No-Op Control [Page 4] -INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005 +INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006 Email: Kurt@OpenLDAP.org @@ -281,7 +281,7 @@ Intellectual Property Rights Zeilenga LDAP No-Op Control [Page 5] -INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005 +INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006 Intellectual Property Rights or other rights that might be claimed to @@ -309,7 +309,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005 Full Copyright - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors diff --git a/doc/drafts/draft-zeilenga-ldap-txn-xx.txt b/doc/drafts/draft-zeilenga-ldap-txn-xx.txt index a9683c5d29..639ce0208b 100644 --- a/doc/drafts/draft-zeilenga-ldap-txn-xx.txt +++ b/doc/drafts/draft-zeilenga-ldap-txn-xx.txt @@ -5,179 +5,258 @@ INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Experimental OpenLDAP Foundation -Expires in six months 3 May 2003 +Intended Category: Standard Track OpenLDAP Foundation +Expires in six months 5 March 2006 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 . + revision, submitted to the IESG for consideration as a Proposed + Standard. Distribution of this memo is unlimited. Technical + discussion of this document will take place on the IETF LDAP + Extensions mailing list . Please send editorial + comments directly to the author . + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware have + been or will be disclosed, and any of which he or she becomes aware + will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF), its areas, and its working groups. Note that other + 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.'' + 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 - . + http://www.ietf.org/1id-abstracts.html - Copyright 2003, The Internet Society. All Rights Reserved. + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html - Please see the Copyright section near the end of this document for - more information. + + Copyright (C) The Internet Society (2006). All Rights Reserved. + + Please see the Full 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 + Lightweight Directory Access Protocol (LDAP) update operations, such Zeilenga LDAP Transactions [Page 1] -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 - +INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006 - 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]. + as Add, Delete, and Modify operations, have atomic, consistency, + isolation, durability (ACID) properties. Each of these update + operations act upon an entry. However, It is often desirable to + update two or more entries in a single unit of interaction, a + transaction. Transactions are necessary to support a number of + applications including resource provisioning and information + replication. This document defines an LDAP extension to support + transactions. 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 + [Roadmap] to allow clients to group a number of related update + operations [Protocol] 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. + This extension consists of two extended operations, one control, and + one unsolicited notification message. The Start Transaction operation + is used to obtain a transaction identifier. This identifier is then + attached to multiple update operations to indicate that they belong to + transaction using the Transaction Specification control. The End + Transaction is used to settle (commit or abort) the transaction. The + Aborted Tranaction Notice is used notify the client the server is no + longer willing or able to process an outstanding transaction. -2. Specification of a Transaction +1.1. Conventions and Terminology + + 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] with implicit + tags. 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.2 of [Protocol]. + + DSA stands for "Directory System Agent" (a server). DSE stands for + "DSA-specific entry". - Servers implementing this specification SHOULD publish the - transactionGroupingType as a value of the 'supportedGroupingTypes' - attribute contained within the Root DSE. - transactionGroupingType ::= IANA-ASSIGNED-OID +2. Elements of an LDAP Transaction + +2.1. Start Transaction Request and Response - 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 +INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006 - 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. + A Start Transaction Request is an LDAPMessage of CHOICE extendedReq + where the requestName is IANA-ASSIGNED-OID.1 and the requestValue is + absent. - 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 Start Transaction Response is an LDAPMessage of CHOICE extendedRes + sent in response to a Start Transaction Request. Its responesName is + absent. When the resultCode is success, responseValue is present and + contains a transaction identifier. Otherwise, the responseValue is + absent. - 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. +2.2. Transaction Specification Control + A Transaction Specification Control is an LDAPControl where the + controlType is IANA-ASSIGNED-OID.2, the criticality is TRUE, and the + controlValue is a transaction identifer. The control is appropriate + for update requests including Add, Delete, Modify, and ModifyDN + requests [Protocol]. -3. Settling of the Transaction +2.3. End Transactions Request and Response - Upon receipt of a request to abort the transaction, the server is to - abort the transaction and then return an endGroupingResponse - indicating success. + An End Transaction Request is an LDAPMessage of CHOICE extendedReq + where the requestName is IANA-ASSIGNED-OID.3 and the requestValue is + present and contains a BER-encoded settlementValue. - 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 + settlementValue ::= SEQUENCE { + commit BOOLEAN DEFAULT TRUE, + identifier OCTET STRING } + + A commit value of TRUE indicates a request to commit the transaction + identified by the identifier. A commit value of FALSE indicates a + request to abort the identified transaction. + + An End Transaction Response is an LDAPMessage sent in response to a + End Transaction Request. Its response name is absent. The + responseValue when present contains a BER-encoded MessageID. + + +2.5. Aborted Transaction Notice + + The Aborted Transaction Notice is an Unsolicited Notification message + where the responseName is IANA-ASSIGNED-OID.4 and responseValue is + present and contains a transaction identifier. + + +3. An LDAP Transaction + +3.1. Extension Discovery Zeilenga LDAP Transactions [Page 3] -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 +INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006 + + + To allow clients to discover support for this extension, servers + implementing this specification SHOULD publish IANA-ASSIGNED-OID.1 and + IANA-ASSIGNED-OID.3 as values of the 'supportedExtension' attribute + [Models] within the Root DSE, and publish the IANA-ASSIGNED-OID.2 as a + value of the 'supportedControl' attribute [Models] of the Root DSE. + + A server MAY choose to advertise this extension only when the client + is authorized to use it. + + +3.2. Starting an Transactions + A client wishing to preform a sequence of directory updates as an + transaction issues a Start Transaction Request. A server which is + willing and able to support transactions responds to this request with + a Start Transaction Response providing a transaction identifier and + with a resultCode of success. Otherwise, the server responds with a + Start Transaction Response wth a result code other than success + indicating the nature of the failure. + + The transaction identifier provided upon successful start of a + transaction is used in subseqent protocol messages to identify this + transaction. + + +3.3. Specification of a Transaction + + The client then may issue may issue one or more update (add, delete, + modify, modifyDN) requests, each with a Transaction Specification + control containing the transaction identifier indicating the updates + are to processed as part of the transaction. Each of these update + request MUST have a different MessageId value. If the server is + unwilling or unable to attempt to process the requested update + operation as part of the transaction, the server immediately returns + the approrpiate response to the request with a resultCode indicating + the nature of the failure. Otherwise, the server immediately returns + success and the defers further processing of the operation is then + deferred until settlement. + + If the server becomes unwilling or unable to continue the + specification of a transaction, the server issues an Aborted + Transaction Notice with a non-success resultCode indicating the nature + of the failure. All operations that were to be processed as part of + the transaction are implicitly abandoned. Upon receipt of an Aborted + Transaction Notice, the client is to discontinue all use of the + transaction identifier as the transaction is null and void. Any + future use of identifier by the client will result in a response + containing a non-success resultCode. + + + +Zeilenga LDAP Transactions [Page 4] + +INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006 - 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. +3.4. Transaction Settlement + + A client requests settlement of transaction by issuing an End + Transaction request for the transaction indicating whether it desires + the transaction to be committed or aborted. + + Upon receipt of a request to abort the transaction, the server is to + abort the identified transaction (abandoning all operations which are + part of the transaction) and indicate that it has done so by returning + an End Transaction response with a resultCode of success. + + Upon receipt of a request to commit the transaction, the server + processes all update operations of the transaction as one atomic, + isolated action with each requested update being processed in turn. + Either all of the requested updates are to be successfully applied or + none of the requested are to be applied. The server returns an End + Transaction Response with a resultCode of success and no responseValue + to indicate all the requested updates were applied. Otherwise, the + server returns an End Transaction with an non-success resultCode + indicating the nature of the failure. If the failure is associated + with a particular update request, a responseValue containing its + MessageID is returned. If the failure was not associated with any + particular update request, no responseValue is returned. + + There is no requirement that a server serialize transactions, or + updates requested outside of a transaction. That is, a server MAY + process multiple commit requests (from one or more clients) acting + upon different sets of entries concurrently. A server MUST avoid + deadlock. 4. Distributed Directory Considerations @@ -185,23 +264,30 @@ INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 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 + This document does not preclude 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. + chaining, it MUST ensure that transaction semantics 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 + The LDAP/X.500 models provide for a single-master/multiple-shadow 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. + + + +Zeilenga LDAP Transactions [Page 5] + +INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006 + + + assume tight data consistency nor fast data convergence at shadow + servers unless they have prior knowledge that such service is + provided. Though this mechanism could be used to support replication, + use in replication 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 @@ -210,159 +296,185 @@ INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 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. + Transactions mechanisms may be the target of denial of service + attacks. Implementors should provide safeguards to ensure these + mechanisms are not abused. + + General security considerations [Roadmap], especially associated with + update operations [Protocol], apply to this extension. 6. IANA Considerations - In accordance with [RFC3383], it is requested that Internet Assigned + In accordance with [BCP64bis], 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: + Assignment of an LDAP Object Identifier to identify the protocol + elements specified in this document this document is requested. Subject: Request for LDAP Object Identifier Registration Person & email address to contact for further information: Kurt Zeilenga - Specification: RFCXXXX + Specification: RFC XXXX Author/Change Controller: IESG - Comments: - Identifies the LDAP Transactions Grouping Type + Comments: Identifies protocol elements for LDAP Transactions 6.2. LDAP Protocol Mechanism - Registration of the protocol mechanisms defined in this document is + Registration of the protocol mechanisms specified in this document is requested. - Subject: Request for LDAP Protocol Mechansism Registration - - Object Identifier: IANA-ASSIGNED-OID - Description: LDAP Transaction Grouping Type + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: see table + Description: see table 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. +Zeilenga LDAP Transactions [Page 6] + +INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006 -8. Author's Address + Kurt Zeilenga + Specification: RFC XXXX + Author/Change Controller: IESG + Comments: - Kurt D. Zeilenga - OpenLDAP Foundation - + Object Identifier Type Description + ------------------- ---- ----------------------------------------- + IANA-ASSIGNED-OID.1 E Start Transaction Extended Request + IANA-ASSIGNED-OID.2 C Transaction Specification Control + IANA-ASSIGNED-OID.3 E End Transaction Extended Request -9. Normative References +7. Acknowledgments + The author gratefully acknowledges the contributions made by members + of the Internet Engineering Task Force. +8. Author's Address -Zeilenga LDAP Transactions [Page 5] - -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 + Kurt D. Zeilenga + OpenLDAP Foundation + Email: Kurt@OpenLDAP.org - [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. +9. References - [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, September 2002. + [[Note to the RFC Editor: please replace the citation tags used in + referencing Internet-Drafts with tags of the form RFCnnnn where + possible.]] - [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. +9.1. Normative References - [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, - Canonical, and Distinguished Encoding Rules", X.690, 1994. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14 (also RFC 2119), March 1997. + [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification + Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in + progress. -10. Informative References + [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", + draft-ietf-ldapbis-protocol-xx.txt, a work in progress. - [ACID] Section 4 of ISO/IEC 10026-1:1992. + [Models] Zeilenga, K. (editor), "LDAP: Directory Information + Models", draft-ietf-ldapbis-models-xx.txt, a work in + progress. - [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. +Zeilenga LDAP Transactions [Page 7] + +INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006 -Copyright 2003, The Internet Society. All Rights Reserved. + [X.680] International Telecommunication Union - + Telecommunication Standardization Sector, "Abstract + Syntax Notation One (ASN.1) - Specification of Basic + Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - 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. + [X.690] International Telecommunication Union - + Telecommunication Standardization Sector, "Specification + of ASN.1 encoding rules: Basic Encoding Rules (BER), + Canonical Encoding Rules (CER), and Distinguished + Encoding Rules (DER)", X.690(2002) (also ISO/IEC + 8825-1:2002). - The limited permissions granted above are perpetual and will not +9.2. Informative References + [ACID] Section 4 of ISO/IEC 10026-1:1992. -Zeilenga LDAP Transactions [Page 6] - -INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 + [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", + draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. + [X.500] International Telecommunication Union - + Telecommunication Standardization Sector, "The Directory + -- Overview of concepts, models and services," + X.500(1993) (also ISO/IEC 9594-1:1994). - be revoked by the Internet Society or its successors or assigns. + [X.501] International Telecommunication Union - + Telecommunication Standardization Sector, "The Directory + -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). - 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. +Intellectual Property Rights + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be found + in BCP 78 and BCP 79. + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this specification + can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. +Zeilenga LDAP Transactions [Page 8] + +INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006 + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. +Full Copyright + Copyright (C) The Internet Society (2006). + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. @@ -391,5 +503,5 @@ INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003 -Zeilenga LDAP Transactions [Page 7] +Zeilenga LDAP Transactions [Page 9]