git.sur5r.net Git - openldap/blob - doc/drafts/draft-zeilenga-ldap-cancel-xx.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                      Kurt D. Zeilenga
   8 Intended Category: Standard Track                OpenLDAP Foundation
   9 Expires: 1 October 2001                                 1 April 2001
  10
  11
  12                       LDAP Cancel Extended Operation
  13                    <draft-zeilenga-ldap-cancel-03.txt>
  14
  15
  16 1.      Status of this Memo
  17
  18   This document is an Internet-Draft and is in full conformance with all
  19   provisions of Section 10 of RFC2026.
  20
  21   This document is intended to be, after appropriate review and
  22   revision, submitted to the RFC Editor as a Standard Track document.
  23   Distribution of this memo is unlimited.  Technical discussion of this
  24   document will take place on the IETF LDAP Extension Working Group
  25   mailing list <ietf-ldapext@netscape.com>.  Please send editorial
  26   comments directly to the author <Kurt@OpenLDAP.org>.
  27
  28   Internet-Drafts are working documents of the Internet Engineering Task
  29   Force (IETF), its areas, and its working groups.  Note that other
  30   groups may also distribute working documents as Internet-Drafts.
  31   Internet-Drafts are draft documents valid for a maximum of six months
  32   and may be updated, replaced, or obsoleted by other documents at any
  33   time.  It is inappropriate to use Internet-Drafts as reference
  34   material or to cite them other than as ``work in progress.''
  35
  36   The list of current Internet-Drafts can be accessed at
  37   http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
  38   Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
  39
  40   Copyright 2001, The Internet Society.  All Rights Reserved.
  41
  42   Please see the Copyright section near the end of this document for
  43   more information.
  44
  45
  46 2.      Abstract
  47
  48   This specification describes an extended operation to cancel (or
  49   abandon) an outstanding operation.   Unlike the LDAP Abandon operation
  50   [RFC2251] but like the DAP Abandon operation [X.511], this operation
  51   has a response which provides an indication of its outcome.
  52
  53   The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
  54   NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'',  and ``MAY'' in
  55
  56
  57
  58 Zeilenga                       LDAP Cancel                      [Page 1]
  59 \f
  60 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-03         1 April 2001
  61
  62
  63   this document are to be interpreted as described in RFC 2119
  64   [RFC2119].
  65
  66
  67 3.      Background and Intent of Use
  68
  69   LDAP provides an Abandon operation which clients may use to cancel
  70   other operations.  The Abandon operation does not have a response and
  71   also calls for there to be no response of the abandoned operation.
  72   These semantics provide the client with no clear indication of the
  73   outcome of the Abandon operation.
  74
  75   DAP provides an Abandon operation which does have a response and also
  76   requires the abandoned operation to return a response with indicating
  77   it was canceled.  The Cancel operation is modeled after the DAP
  78   Abandon operation.
  79
  80   The Cancel operation is intended to be used instead of the LDAP
  81   Abandon operation.  This operation may be used to cancel both
  82   interrogation and update operations.
  83
  84
  85 4.      Cancel Operation
  86
  87   The Cancel operation is defined as a LDAPv3 Extended Operation
  88   [RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID.
  89   This section details the syntax of the Cancel request and response
  90   messages and defines additional LDAP resultCodes.
  91
  92       cancelOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.2
  93
  94       cancelRequestValue ::= SEQUENCE {
  95           cancelID        MessageID
  96       }
  97
  98
  99 4.1.    Cancel Request
 100
 101   The Cancel request is an ExtendedRequest with the requestName field
 102   containing cancelOID OID and a requestValue field which contains a
 103   cancelRequestValue value encoded per [RFC2251, Section 5.1].  The
 104   cancelID field contains the message id associated with the operation
 105   to be canceled.
 106
 107
 108 4.2.    Cancel Response
 109
 110   A Cancel response is an ExtendedResponse where the responseName and
 111
 112
 113
 114 Zeilenga                       LDAP Cancel                      [Page 2]
 115 \f
 116 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-03         1 April 2001
 117
 118
 119   response fields are absent.
 120
 121
 122 4.3.    Additional Result Codes
 123
 124   Implementations of this specification SHALL recognize the following
 125   additional resultCode values:
 126
 127       canceled        (72)
 128       noSuchOperation (73)
 129       tooLate         (74)
 130       cannotCancel    (75)
 131
 132
 133 5.      Operational Semantics
 134
 135   The function of the Cancel Operation is to request that the server
 136   cancel an outstanding operation issued within the same session.
 137
 138   The client requests the cancelation of an outstanding operation by
 139   issuing a Cancel Response with a cancelID with the message id
 140   identifying the outstanding operation.  The Cancel Request itself has
 141   a distinct message id.  Clients SHOULD NOT request cancelation of an
 142   operation multiple times.
 143
 144   If the server is unable to parse the requestValue or the requestValue
 145   is absent, the server shall return protocolError.
 146
 147   If the server is willing and able to cancel the outstanding operation
 148   identified by the cancelId, the server SHALL return a Cancel Response
 149   with a success resultCode and the canceled operation SHALL fail with
 150   canceled resultCode.  Otherwise the Cancel Response SHALL have a
 151   non-success resultCode and SHALL NOT have impact upon the outstanding
 152   operation (if it exists).
 153
 154   The server SHALL return noSuchOperation if it has no knowledge of the
 155   operation requested to be canceled.
 156
 157   The server SHALL return cannotCancel if the identified operation does
 158   not support cancelation or the cancel operation could not be
 159   performed.  The following classes of operations are not cancelable:
 160
 161     - operations which have no response,
 162
 163     - operations which associate or disassociate authentication and/or
 164       authorization associations,
 165
 166     - operations which establish or tear-down security services, and
 167
 168
 169
 170 Zeilenga                       LDAP Cancel                      [Page 3]
 171 \f
 172 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-03         1 April 2001
 173
 174
 175     - operations which abandon or cancel other operations.
 176
 177   Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
 178   operations are not cancelable.
 179
 180   If the result of the outstanding operation has been determined by the
 181   server, the outstanding operation SHALL NOT be canceled and the cancel
 182   operation SHALL result in tooLate.
 183
 184   Servers SHOULD indicate their support for this extended operation by
 185   providing cancelOID as a value of the supportedExtension attribute
 186   type in their root DSE.  A server MAY choose to advertise this
 187   extension only when the client is authorized and/or has established
 188   the necessary security protections to use this operation.  Clients
 189   SHOULD verify the server implements this extended operation prior to
 190   attempting the operation by asserting the supportedExtension attribute
 191   contains a value of cancelOID.
 192
 193
 194 6.      Security Considerations
 195
 196   This operation is intended to allow a user to cancel operations they
 197   previously issued.  No user should be allowed to cancel an operation
 198   issued by another user (within the same session or not).  However, as
 199   this operation may only be used to cancel within the same session and
 200   LDAP requires operations to be abandoned upon bind requests, this is a
 201   non-issue.
 202
 203   Some operations should not be cancelable for security reasons.  This
 204   specification disallows cancelation of Bind operation and Start TLS
 205   extended operation so as to avoid adding complexity to authentication,
 206   authorization, and security layer semantics.  Designers of future
 207   extended operations and/or controls SHOULD disallow abandonment and
 208   cancelation when appropriate.
 209
 210
 211 7.      Copyright
 212
 213   Copyright 2001, The Internet Society.  All Rights Reserved.
 214
 215   This document and translations of it may be copied and furnished to
 216   others, and derivative works that comment on or otherwise explain it
 217   or assist in its implementation may be prepared, copied, published and
 218   distributed, in whole or in part, without restriction of any kind,
 219   provided that the above copyright notice and this paragraph are
 220   included on all such copies and derivative works.  However, this
 221   document itself may not be modified in any way, such as by removing
 222   the copyright notice or references to the Internet Society or other
 223
 224
 225
 226 Zeilenga                       LDAP Cancel                      [Page 4]
 227 \f
 228 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-03         1 April 2001
 229
 230
 231   Internet organizations, except as needed for the  purpose of
 232   developing Internet standards in which case the procedures for
 233   copyrights defined in the Internet Standards process must be followed,
 234   or as required to translate it into languages other than English.
 235
 236   The limited permissions granted above are perpetual and will not be
 237   revoked by the Internet Society or its successors or assigns.
 238
 239   This document and the information contained herein is provided on an
 240   "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
 241   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
 242   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 243   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 244   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 245
 246
 247 8.      Bibliography
 248
 249   [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
 250             Requirement Levels", RFC 2119, March 1997.
 251
 252   [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
 253             Protocol (v3)", RFC 2251, December 1997.
 254
 255   [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
 256             Access Protocol (v3): Extension for Transport Layer
 257             Security", RFC 2830, May 2000.
 258
 259   [X.511]   ITU-T Rec. X.511, "The Directory: Abstract Service
 260             Definition", 1993. (not normative)
 261
 262
 263 9.     Acknowledgment
 264
 265   This document is based upon input from the IETF LDAPext working group.
 266
 267
 268 10.     Author's Address
 269
 270   Kurt D. Zeilenga
 271   OpenLDAP Foundation
 272   <Kurt@OpenLDAP.org>
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Zeilenga                       LDAP Cancel                      [Page 5]
 283 \f