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 in six months                                25 October 2003
  10
  11
  12                           LDAP Cancel Operation
  13                    <draft-zeilenga-ldap-cancel-10.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 Extensions mailing list
  25   <ldapext@ietf.org>.  Please send editorial comments directly to the
  26   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
  38   Internet-Draft Shadow Directories can be accessed at
  39   <http://www.ietf.org/shadow.html>.
  40
  41   Copyright (C) The Internet Society (2003).  All Rights Reserved.
  42
  43   Please see the Full Copyright section near the end of this document
  44   for more information.
  45
  46
  47 Abstract
  48
  49   This specification describes a Lightweight Directory Access Protocol
  50   (LDAP) extended operation to cancel (or abandon) an outstanding
  51   operation.   Unlike the LDAP Abandon operation but like the X.511
  52   Directory Access Protocol (DAP) Abandon operation, this operation has
  53   a response which provides an indication of its outcome.
  54
  55
  56
  57
  58 Zeilenga                       LDAP Cancel                      [Page 1]
  59 \f
  60 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-10     25 Octeboer 2003
  61
  62
  63 Terminology
  64
  65   Protocol elements are described using ASN.1 [X.680] with implicit
  66   tags.  The term "BER-encoded" means the element is to be encoded using
  67   the Basic Encoding Rules [X.690] under the restrictions detailed in
  68   Section 5.1 of [RFC2251].
  69
  70   DSA stands for Directory System Agent (or server).
  71   DSE stands for DSA-specific Entry.
  72
  73   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  74   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  75   document are to be interpreted as described in BCP 14 [RFC2119].
  76
  77
  78 1. Background and Intent of Use
  79
  80   The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides an
  81   Abandon operation [RFC2251] which clients may use to cancel other
  82   operations.  The Abandon operation does not have a response and calls
  83   for there to be no response of the abandoned operation.  These
  84   semantics provide the client with no clear indication of the outcome
  85   of the Abandon operation.
  86
  87   X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon
  88   operation which does have a response and also requires the abandoned
  89   operation to return a response indicating it was canceled.  The LDAP
  90   Cancel operation is modeled after the DAP Abandon operation.
  91
  92   The LDAP Cancel operation SHOULD be used instead of the LDAP Abandon
  93   operation when the client needs an indication of the outcome.  This
  94   operation may be used to cancel both interrogation and update
  95   operations.
  96
  97
  98 2. Cancel Operation
  99
 100   The Cancel operation is defined as a LDAP Extended Operation [RFC2251,
 101   Section 4.12] identified by the IANA-ASSIGNED-OID.  This section
 102   details the syntax of the Cancel request and response messages and
 103   defines additional LDAP resultCodes.
 104
 105       cancelRequestValue ::= SEQUENCE {
 106           cancelID        MessageID
 107       }
 108
 109
 110 2.1. Cancel Request
 111
 112
 113
 114 Zeilenga                       LDAP Cancel                      [Page 2]
 115 \f
 116 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-10     25 Octeboer 2003
 117
 118
 119   The Cancel request is an ExtendedRequest with the requestName field
 120   containing the IANA-ASSIGNED-OID and a requestValue field which
 121   contains a BER-encoded cancelRequestValue value.  The cancelID field
 122   contains the message id associated with the operation to be canceled.
 123
 124
 125 2.2. Cancel Response
 126
 127   A Cancel response is an ExtendedResponse where the responseName and
 128   response fields are absent.
 129
 130
 131 2.3. Additional Result Codes
 132
 133   Implementations of this specification SHALL recognize the following
 134   additional resultCode values:
 135
 136       canceled        (IANA-ASSIGNED-1)
 137       noSuchOperation (IANA-ASSIGNED-2)
 138       tooLate         (IANA-ASSIGNED-3)
 139       cannotCancel    (IANA-ASSIGNED-4)
 140
 141
 142 3. Operational Semantics
 143
 144   The function of the Cancel Operation is to request that the server
 145   cancel an outstanding operation issued within the same session.
 146
 147   The client requests the cancelation of an outstanding operation by
 148   issuing a Cancel Response with a cancelID set to the message id of the
 149   outstanding operation.  The Cancel Request itself has a distinct
 150   message id.  Clients SHOULD NOT request cancelation of an operation
 151   multiple times.
 152
 153   If the server is willing and able to cancel the outstanding operation
 154   identified by the cancelId, the server SHALL return a Cancel Response
 155   with a success resultCode and the canceled operation SHALL fail with
 156   canceled resultCode.  Otherwise the Cancel Response SHALL have a
 157   non-success resultCode and SHALL NOT have impact upon the outstanding
 158   operation (if it exists).
 159
 160   The protocolError resultCode is returned if the server is unable to
 161   parse the requestValue or the requestValue is absent,
 162
 163   The noSuchOperation resultCode is returned if the server has no
 164   knowledge of the operation requested to be canceled.
 165
 166   The cannotCancel resultCode is returned if the identified operation
 167
 168
 169
 170 Zeilenga                       LDAP Cancel                      [Page 3]
 171 \f
 172 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-10     25 Octeboer 2003
 173
 174
 175   does not support cancelation or the cancel operation could not be
 176   performed.  The following classes of operations are not cancelable:
 177
 178     - operations which have no response,
 179
 180     - operations which create, alter, or destroy authentication and/or
 181       authorization associations,
 182
 183     - operations which establish, alter, or tear-down security services,
 184       and
 185
 186     - operations which abandon or cancel other operations.
 187
 188   Specifically, the Abandon, Bind, Start TLS [RFC2830], Unbind and
 189   Cancel operations are not cancelable.
 190
 191   The tooLate resultCode is returned to indicate that it is too late to
 192   cancel the outstanding operation.  For example, the server may return
 193   tooLate for a request to cancel an outstanding modify operation which
 194   as already committed updates to the underlying data store.
 195
 196   Servers SHOULD indicate their support for this extended operation by
 197   providing IANA-ASSIGNED-OID as a value of the 'supportedExtension'
 198   attribute type in their root DSE.  A server MAY choose to advertise
 199   this extension only when the client is authorized to use it.
 200
 201
 202 4. Security Considerations
 203
 204   This operation is intended to allow user to cancel operations they
 205   previously issued during the current LDAP association.  In certain
 206   cases, such as when the Proxy Authorization Control is in use,
 207   different outstanding operations may be processed under different LDAP
 208   associations.  Servers MUST NOT allow a user to cancel an operation
 209   belonging to another user.
 210
 211   Some operations should not be cancelable for security reasons.  This
 212   specification disallows cancelation of Bind operation and Start TLS
 213   extended operation so as to avoid adding complexity to authentication,
 214   authorization, and security layer semantics.  Designers of future
 215   extended operations and/or controls should disallow abandonment and
 216   cancelation when appropriate.
 217
 218
 219 5.  IANA Considerations
 220
 221   Registration of the following values [RFC3383] is requested.
 222
 223
 224
 225
 226 Zeilenga                       LDAP Cancel                      [Page 4]
 227 \f
 228 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-10     25 Octeboer 2003
 229
 230
 231 5.1.  Object Identifier
 232
 233   It is requested that IANA register upon Standards Action an LDAP
 234   Object Identifier to identify the LDAP Cancel Operation as defined in
 235   this document.
 236
 237       Subject: Request for LDAP Object Identifier Registration
 238       Person & email address to contact for further information:
 239            Kurt Zeilenga <kurt@OpenLDAP.org>
 240       Specification: RFC XXXX
 241       Author/Change Controller: IESG
 242       Comments:
 243            Identifies the LDAP Cancel Operation
 244
 245
 246 5.2.  LDAP Protocol Mechanism
 247
 248   It is requested that IANA register upon Standards Action the LDAP
 249   Protocol Mechanism described in this document.
 250
 251       Subject: Request for LDAP Protocol Mechanism Registration
 252       Object Identifier: IANA-ASSIGNED-OID
 253       Description: LDAP Cancel Operation
 254       Person & email address to contact for further information:
 255            Kurt Zeilenga <kurt@openldap.org>
 256       Usage: Extended Operation
 257       Specification: RFC XXXX
 258       Author/Change Controller: IESG
 259       Comments: none
 260       in 2
 261
 262
 263 5.3.  LDAP Result Codes
 264
 265       It is requested that IANA register upon Standards Action the LDAP
 266       Result Codes described in this document.
 267
 268       Subject: LDAP Result Code Registration
 269       Person & email address to contact for further information:
 270            Kurt Zeilenga <kurt@OpenLDAP.org>
 271       Result Code Name: canceled
 272       Result Code Name: noSuchOperation
 273       Result Code Name: tooLate
 274       Result Code Name: cannotCancel
 275       Specification: RFC XXXX
 276       Author/Change Controller: IESG
 277       Comments:  request four consecutive result codes be assigned
 278
 279
 280
 281
 282 Zeilenga                       LDAP Cancel                      [Page 5]
 283 \f
 284 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-10     25 Octeboer 2003
 285
 286
 287 6. Acknowledgment
 288
 289   The LDAP Cancel operation is modeled after the X.511 DAP Abandon
 290   operation.
 291
 292
 293 7. Normative References
 294
 295   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 296                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 297
 298   [RFC2251]     Wahl, M., T. Howes and S. Kille, "Lightweight Directory
 299                 Access Protocol (v3)", RFC 2251, December 1997.
 300
 301   [RFC2830]     Hodges, J., R. Morgan, and M. Wahl, "Lightweight
 302                 Directory Access Protocol (v3): Extension for Transport
 303                 Layer Security", RFC 2830, May 2000.
 304
 305   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
 306                 Protocol (v3): Technical Specification", RFC 3377,
 307                 September 2002.
 308
 309   [X.680]       International Telecommunication Union -
 310                 Telecommunication Standardization Sector, "Abstract
 311                 Syntax Notation One (ASN.1) - Specification of Basic
 312                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
 313
 314   [X.690]       International Telecommunication Union -
 315                 Telecommunication Standardization Sector, "Specification
 316                 of ASN.1 encoding rules: Basic Encoding Rules (BER),
 317                 Canonical Encoding Rules (CER), and Distinguished
 318                 Encoding Rules (DER)", X.690(1997) (also ISO/IEC
 319                 8825-1:1998).
 320
 321
 322 8. Informative References
 323
 324   [RFC3383]     Zeilenga, K., "IANA Considerations for LDAP", BCP 64
 325                 (also RFC 3383), September 2002.
 326
 327   [X.511]       International Telecommunication Union -
 328                 Telecommunication Standardization Sector, "The
 329                 Directory: Abstract Service Definition", X.511(1993).
 330
 331
 332 9. Author's Address
 333
 334   Kurt D. Zeilenga
 335
 336
 337
 338 Zeilenga                       LDAP Cancel                      [Page 6]
 339 \f
 340 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-10     25 Octeboer 2003
 341
 342
 343   OpenLDAP Foundation
 344   <Kurt@OpenLDAP.org>
 345
 346
 347
 348 Intellectual Property Rights
 349
 350   The IETF takes no position regarding the validity or scope of any
 351   intellectual property or other rights that might be claimed to pertain
 352   to the implementation or use of the technology described in this
 353   document or the extent to which any license under such rights might or
 354   might not be available; neither does it represent that it has made any
 355   effort to identify any such rights.  Information on the IETF's
 356   procedures with respect to rights in standards-track and
 357   standards-related documentation can be found in BCP-11.  Copies of
 358   claims of rights made available for publication and any assurances of
 359   licenses to be made available, or the result of an attempt made to
 360   obtain a general license or permission for the use of such proprietary
 361   rights by implementors or users of this specification can be obtained
 362   from the IETF Secretariat.
 363
 364   The IETF invites any interested party to bring to its attention any
 365   copyrights, patents or patent applications, or other proprietary
 366   rights which may cover technology that may be required to practice
 367   this standard.  Please address the information to the IETF Executive
 368   Director.
 369
 370
 371
 372 Full Copyright
 373
 374   Copyright (C) The Internet Society (2003). All Rights Reserved.
 375
 376   This document and translations of it may be copied and furnished to
 377   others, and derivative works that comment on or otherwise explain it
 378   or assist in its implmentation may be prepared, copied, published and
 379   distributed, in whole or in part, without restriction of any kind,
 380   provided that the above copyright notice and this paragraph are
 381   included on all such copies and derivative works.  However, this
 382   document itself may not be modified in any way, such as by removing
 383   the copyright notice or references to the Internet Society or other
 384   Internet organizations, except as needed for the  purpose of
 385   developing Internet standards in which case the procedures for
 386   copyrights defined in the Internet Standards process must be followed,
 387   or as required to translate it into languages other than English.
 388
 389
 390
 391
 392
 393
 394 Zeilenga                       LDAP Cancel                      [Page 7]
 395 \f