GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3909

Network Working Group K. Zeilenga Request for Comments: 3909 OpenLDAP Foundation Category: Standards Track October 2004

           Lightweight Directory Access Protocol (LDAP)
                          Cancel Operation

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This specification describes a Lightweight Directory Access Protocol
 (LDAP) extended operation to cancel (or abandon) an outstanding
 operation.  Unlike the LDAP Abandon operation, but like the X.511
 Directory Access Protocol (DAP) Abandon operation, this operation has
 a response which provides an indication of its outcome.

1. Background and Intent of Use

 The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides
 an Abandon operation [RFC2251] which clients may use to cancel other
 operations.  The Abandon operation does not have a response and
 requires no response from the abandoned operation.  These semantics
 provide the client with no clear indication of the outcome of the
 Abandon operation.
 The X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon
 operation which has a response and also requires the abandoned
 operation to return a response indicating it was canceled.  The LDAP
 Cancel operation is modeled after the DAP Abandon operation.
 The LDAP Cancel operation SHOULD be used instead of the LDAP Abandon
 operation when the client needs an indication of the outcome.  This
 operation may be used to cancel both interrogation and update
 operations.

Zeilenga Standards Track [Page 1] RFC 3909 LDAP Cancel Operation October 2004

 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.1 of [RFC2251].
 DSA stands for Directory System Agent (or server).
 DSE stands for DSA-specific Entry.
 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].

2. Cancel Operation

 The Cancel operation is defined as an LDAP Extended Operation
 [RFC2251, Section 4.12] identified by the object identifier
 1.3.6.1.1.8.  This section details the syntax of the Cancel request
 and response messages and defines additional LDAP resultCodes.

2.1. Cancel Request

 The Cancel request is an ExtendedRequest with the requestName field
 containing 1.3.6.1.1.8 and a requestValue field which contains a
 BER-encoded cancelRequestValue value.
    cancelRequestValue ::= SEQUENCE {
        cancelID        MessageID
                        -- MessageID is as defined in [RFC2251]
    }
 The cancelID field contains the message ID associated with the
 operation to be canceled.

2.2. Cancel Response

 A Cancel response is an ExtendedResponse where the responseName and
 response fields are absent.

2.3. Additional Result Codes

 Implementations of this specification SHALL recognize the following
 additional resultCode values:
    canceled        (118)
    noSuchOperation (119)
    tooLate         (120)
    cannotCancel    (121)

Zeilenga Standards Track [Page 2] RFC 3909 LDAP Cancel Operation October 2004

3. Operational Semantics

 The function of the Cancel Operation is to request that the server
 cancel an outstanding operation issued within the same session.
 The client requests the cancelation of an outstanding operation by
 issuing a Cancel Response with a cancelID set to the message ID of
 the outstanding operation.  The Cancel Request itself has a distinct
 message ID.  Clients SHOULD NOT request the cancelation of an
 operation multiple times.
 If the server is willing and able to cancel the outstanding operation
 identified by the cancelId, the server SHALL return a Cancel Response
 with a success resultCode, and the canceled operation SHALL fail with
 canceled resultCode.  Otherwise the Cancel Response SHALL have a
 non-success resultCode and SHALL NOT have an impact upon the
 outstanding operation (if it exists).
 The protocolError resultCode is returned if the server is unable to
 parse the requestValue or the requestValue is absent,
 The noSuchOperation resultCode is returned if the server has no
 knowledge of the operation requested for cancelation.
 The cannotCancel resultCode is returned if the identified operation
 does not support cancelation or the cancel operation could not be
 performed.  The following classes of operations are not cancelable:
  1. operations which have no response,
  1. operations which create, alter, or destroy authentication and/or

authorization associations,

  1. operations which establish, alter, or tear-down security services,

and

  1. operations which abandon or cancel other operations.
 Specifically, the Abandon, Bind, Start TLS [RFC2830], Unbind, and
 Cancel operations are not cancelable.
 The Cancel operation cannot be abandoned.
 The tooLate resultCode is returned to indicate that it is too late to
 cancel the outstanding operation.  For example, the server may return
 tooLate for a request to cancel an outstanding modify operation which
 has already committed updates to the underlying data store.

Zeilenga Standards Track [Page 3] RFC 3909 LDAP Cancel Operation October 2004

 Servers SHOULD indicate their support for this extended operation by
 providing 1.3.6.1.1.8 as a value of the 'supportedExtension'
 attribute type in their root DSE.  A server MAY choose to advertise
 this extension only when the client is authorized to use it.

4. Security Considerations

 This operation is intended to allow a user to cancel operations they
 previously issued during the current LDAP association.  In certain
 cases, such as when the Proxy Authorization Control is in use,
 different outstanding operations may be processed under different
 LDAP associations.  Servers MUST NOT allow a user to cancel an
 operation belonging to another user.
 Some operations should not be cancelable for security reasons.  This
 specification disallows the cancelation of the Bind operation and
 Start TLS extended operation so as to avoid adding complexity to
 authentication, authorization, and security layer semantics.
 Designers of future extended operations and/or controls should
 disallow abandonment and cancelation when appropriate.

5. IANA Considerations

 The following values [RFC3383] have been registered by the IANA.

5.1. Object Identifier

 The IANA has registered upon Standards Action the LDAP Object
 Identifier 1.3.6.1.1.8 to identify the LDAP Cancel Operation as
 defined in this document.
    Subject: Request for LDAP Object Identifier Registration
    Person & email address to contact for further information:
         Kurt Zeilenga <kurt@OpenLDAP.org>
    Specification: RFC 3909
    Author/Change Controller: IESG
    Comments:
         Identifies the LDAP Cancel Operation

Zeilenga Standards Track [Page 4] RFC 3909 LDAP Cancel Operation October 2004

5.2. LDAP Protocol Mechanism

 The IANA has registered upon Standards Action the LDAP Protocol
 Mechanism described in this document.
    Subject: LDAP Protocol Mechanism Registration
    Object Identifier: 1.3.6.1.1.8
    Description: LDAP Cancel Operation
    Person & email address to contact for further information:
         Kurt Zeilenga <kurt@openldap.org>
    Usage: Extended Operation
    Specification: RFC 3909
    Author/Change Controller: IESG
    Comments: none

5.3. LDAP Result Codes

 The IANA has registered upon Standards Action the LDAP Result Codes
 described in this document.
    Subject: LDAP Result Code Registration
    Person & email address to contact for further information:
         Kurt Zeilenga <kurt@OpenLDAP.org>
    Result Code Name: canceled (118)
    Result Code Name: noSuchOperation (119)
    Result Code Name: tooLate (120)
    Result Code Name: cannotCancel (121)
    Specification: RFC 3909
    Author/Change Controller: IESG

6. Acknowledgment

 The LDAP Cancel operation is modeled after the X.511 DAP Abandon
 operation.

Zeilenga Standards Track [Page 5] RFC 3909 LDAP Cancel Operation October 2004

7. References

7.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
            Access Protocol (v3)", RFC 2251, December 1997.
 [RFC2830]  Hodges, J., Morgan, R., and M. Wahl, "Lightweight
            Directory Access Protocol (v3): Extension for Transport
            Layer Security", RFC 2830, May 2000.
 [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
            Protocol (v3): Technical Specification", RFC 3377,
            September 2002.
 [X.680]    International Telecommunication Union - Telecommunication
            Standardization Sector, "Abstract Syntax Notation One
            (ASN.1) - Specification of Basic Notation", X.680(1997)
            (also ISO/IEC 8824-1:1998).
 [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(1997) (also ISO/IEC 8825-1:1998).

7.2. Informative References

 [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
            Considerations for the Lightweight Directory Access
            Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
 [X.511]    International Telecommunication Union - Telecommunication
            Standardization Sector, "The Directory: Abstract Service
            Definition", X.511(1993).

8. Author's Address

 Kurt D. Zeilenga
 OpenLDAP Foundation
 EMail: Kurt@OpenLDAP.org

Zeilenga Standards Track [Page 6] RFC 3909 LDAP Cancel Operation October 2004

9. Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and at www.rfc-editor.org, 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.

Intellectual Property

 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 ISOC's procedures with respect to rights in ISOC 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.
 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Zeilenga Standards Track [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3909.txt · Last modified: 2004/10/06 19:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki