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
- <draft-zeilenga-ldap-dontusecopy-01.txt>
+ <draft-zeilenga-ldap-dontusecopy-02.txt>
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.
Zeilenga LDAP Don't Use Copy Control [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
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
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]
\f
-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
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
+ Specification: RFC XXXX
Zeilenga LDAP Don't Use Copy Control [Page 3]
\f
-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
+
Zeilenga LDAP Don't Use Copy Control [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
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
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 3 May 2003
-
-
-
- LDAP: Grouping of Related Operations
- <draft-zeilenga-ldap-grouping-06.txt>
-
-
-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 <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
-
- 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
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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 <kurt@OpenLDAP.org>
- Specification: RFCXXXX
- Author/Change Controller: IESG
- Comments:
- Identifies elements of the LDAP Grouping Operation
-
-
-
-
-Zeilenga LDAP Grouping [Page 12]
-\f
-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 <kurt@openldap.org>
- 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 <kurt@OpenLDAP.org>
- 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]
-\f
-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
- <Kurt@OpenLDAP.org>
-
-
-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]
-\f
-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]
-\f
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
- <draft-zeilenga-ldap-noop-07.txt>
+ <draft-zeilenga-ldap-noop-08.txt>
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.
Zeilenga LDAP No-Op Control [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
Abstract
Zeilenga LDAP No-Op Control [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
2. No-Op Control
Zeilenga LDAP No-Op Control [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
4. IANA Considerations
Zeilenga LDAP No-Op Control [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
Email: Kurt@OpenLDAP.org
Zeilenga LDAP No-Op Control [Page 5]
\f
-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
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
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
- <draft-zeilenga-ldap-txn-06.txt>
+ <draft-zeilenga-ldap-txn-07.txt>
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 <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
+ 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 <ldapext@ietf.org>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
+ 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]
\f
-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]
\f
-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]
\f
-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]
+\f
+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
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]
+\f
+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
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]
-\f
-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 <kurt@OpenLDAP.org>
- 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 <kurt@openldap.org>
- 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]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
-8. Author's Address
+ Kurt Zeilenga <kurt@openldap.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
+ 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]
-\f
-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]
+\f
+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]
-\f
-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]
+\f
+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.
-Zeilenga LDAP Transactions [Page 7]
+Zeilenga LDAP Transactions [Page 9]
\f
projects / openldap / commitdiff