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                                    17 May 2002
  10
  11
  12                       LDAP Cancel Extended Operation
  13                    <draft-zeilenga-ldap-cancel-05.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
  38   Internet-Draft Shadow Directories can be accessed at
  39   <http://www.ietf.org/shadow.html>.
  40
  41   Copyright 2002, The Internet Society.  All Rights Reserved.
  42
  43   Please see the Copyright section near the end of this document for
  44   more information.
  45
  46
  47 Abstract
  48
  49   This specification describes an LDAP (Lightweight Directory Access
  50   Protocol) extended operation to cancel (or abandon) an outstanding
  51   operation.   Unlike the LDAP Abandon operation but like the X.511 DAP
  52   Abandon operation, this operation has a response which provides an
  53   indication of its outcome.
  54
  55
  56
  57
  58 Zeilenga                       LDAP Cancel                      [Page 1]
  59 \f
  60 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-05          17 May 2002
  61
  62
  63 Conventions
  64
  65   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  66   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  67   document are to be interpreted as described in BCP 14 [RFC2119].
  68
  69   Protocol elements are described using ASN.1 [X.680].  The term
  70   "BER-encoded" means the element is to be encoded using the Basic
  71   Encoding Rules [X.690] under the restrictions detailed in Section 5.1
  72   of [RFC2251].
  73
  74
  75 1. Background and Intent of Use
  76
  77   LDAP [RFC2251] provides an Abandon operation which clients may use to
  78   cancel other operations.  The Abandon operation does not have a
  79   response and also calls for there to be no response of the abandoned
  80   operation.  These semantics provide the client with no clear
  81   indication of the outcome of the Abandon operation.
  82
  83   X.511 DAP [X.511] provides an Abandon operation which does have a
  84   response and also requires the abandoned operation to return a
  85   response with indicating it was canceled.  The Cancel operation is
  86   modeled after the DAP Abandon operation.
  87
  88   The Cancel operation SHOULD be used instead of the LDAP Abandon
  89   operation when the client needs an indication of the outcome.  This
  90   operation may be used to cancel both interrogation and update
  91   operations.
  92
  93
  94 4. Cancel Operation
  95
  96   The Cancel operation is defined as a LDAPv3 Extended Operation
  97   [RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID.
  98   This section details the syntax of the Cancel request and response
  99   messages and defines additional LDAP resultCodes.
 100
 101       cancelOID OBJECT IDENTIFIER ::= IANA-ASSIGNED
 102
 103       cancelRequestValue ::= SEQUENCE {
 104           cancelID        MessageID
 105       }
 106
 107
 108 4.1. Cancel Request
 109
 110   The Cancel request is an ExtendedRequest with the requestName field
 111
 112
 113
 114 Zeilenga                       LDAP Cancel                      [Page 2]
 115 \f
 116 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-05          17 May 2002
 117
 118
 119   containing cancelOID OID and a requestValue field which contains a
 120   cancelRequestValue value encoded per [RFC2251, Section 5.1].  The
 121   cancelID field contains the message id associated with the operation
 122   to be canceled.
 123
 124
 125 4.2. Cancel Response
 126
 127   A Cancel response is an ExtendedResponse where the responseName and
 128   response fields are absent.
 129
 130
 131 4.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 5. 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 with the message id
 149   identifying the outstanding operation.  The Cancel Request itself has
 150   a distinct message id.  Clients SHOULD NOT request cancelation of an
 151   operation multiple times.
 152
 153   If the server is unable to parse the requestValue or the requestValue
 154   is absent, the server shall return protocolError.
 155
 156   If the server is willing and able to cancel the outstanding operation
 157   identified by the cancelId, the server SHALL return a Cancel Response
 158   with a success resultCode and the canceled operation SHALL fail with
 159   canceled resultCode.  Otherwise the Cancel Response SHALL have a
 160   non-success resultCode and SHALL NOT have impact upon the outstanding
 161   operation (if it exists).
 162
 163   The server SHALL return noSuchOperation if it has no knowledge of the
 164   operation requested to be canceled.
 165
 166   The server SHALL return cannotCancel if the identified operation does
 167
 168
 169
 170 Zeilenga                       LDAP Cancel                      [Page 3]
 171 \f
 172 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-05          17 May 2002
 173
 174
 175   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 associate or disassociate authentication and/or
 181       authorization associations,
 182
 183     - operations which establish or tear-down security services, and
 184
 185     - operations which abandon or cancel other operations.
 186
 187   Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
 188   operations are not cancelable.
 189
 190   If the result of the outstanding operation has been determined by the
 191   server, the outstanding operation SHALL NOT be canceled and the cancel
 192   operation SHALL result in tooLate.
 193
 194   Servers SHOULD indicate their support for this extended operation by
 195   providing cancelOID as a value of the supportedExtension attribute
 196   type in their root DSE.  A server MAY choose to advertise this
 197   extension only when the client is authorized and/or has established
 198   the necessary security protections to use this operation.  Clients
 199   SHOULD verify the server implements this extended operation prior to
 200   attempting the operation by asserting the supportedExtension attribute
 201   contains a value of cancelOID.
 202
 203
 204 6. Security Considerations
 205
 206   This operation is intended to allow a user to cancel operations they
 207   previously issued.  No user should be allowed to cancel an operation
 208   issued by another user (within the same session or not).  However, as
 209   this operation may only be used to cancel within the same session and
 210   LDAP requires operations to be abandoned upon bind requests, this is a
 211   non-issue.
 212
 213   Some operations should not be cancelable for security reasons.  This
 214   specification disallows cancelation of Bind operation and Start TLS
 215   extended operation so as to avoid adding complexity to authentication,
 216   authorization, and security layer semantics.  Designers of future
 217   extended operations and/or controls SHOULD disallow abandonment and
 218   cancelation when appropriate.
 219
 220
 221 7.  IANA Considerations
 222
 223
 224
 225
 226 Zeilenga                       LDAP Cancel                      [Page 4]
 227 \f
 228 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-05          17 May 2002
 229
 230
 231 7.1.  Object Identifiers
 232
 233   It is requested that IANA register a Directory Number OID for use in
 234   this document upon Standards Action by the IESG.   This OID will be
 235   used to identify the LDAP Cancel extended operation as indicated
 236   above.  The following registration template is suggested:
 237
 238       Subject: Request for LDAP OID Registration
 239       Person & email address to contact for further information:
 240            Kurt Zeilenga <kurt@OpenLDAP.org>
 241       Specification: RFCXXX
 242       Author/Change Controller: IESG
 243
 244
 245 7.2.  LDAP Result Codes
 246
 247   It is requested that IANA register the LDAP result codes:
 248
 249       canceled        (IANA-ASSIGNED-1)
 250       noSuchOperation (IANA-ASSIGNED-2)
 251       tooLate         (IANA-ASSIGNED-3)
 252       cannotCancel    (IANA-ASSIGNED-4)
 253
 254   upon Standards Action by the IESG.  The following registration
 255   template is suggested:
 256
 257       Subject: LDAP Result Code Registration
 258       Person & email address to contact for further information:
 259            Kurt Zeilenga <kurt@OpenLDAP.org>
 260       Result Code Name: canceled
 261       Result Code Name: noSuchOperation
 262       Result Code Name: tooLate
 263       Result Code Name: cannotCancel
 264       Specification: RFCXXXX
 265       Author/Change Controller: IESG
 266       Comments:  request four consecutive result codes be assigned
 267
 268
 269 8. Acknowledgment
 270
 271   This document is based upon input from the IETF LDAPext working group.
 272
 273
 274 9. Normative References
 275
 276   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
 277             Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 278
 279
 280
 281
 282 Zeilenga                       LDAP Cancel                      [Page 5]
 283 \f
 284 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-05          17 May 2002
 285
 286
 287   [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
 288             Protocol (v3)", RFC 2251, December 1997.
 289
 290   [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
 291             Access Protocol (v3): Extension for Transport Layer
 292             Security", RFC 2830, May 2000.
 293
 294   [X.680]   ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
 295             of Basic Notation", X.680, 1994.
 296
 297   [X.690]   ITU-T, "Specification of ASN.1 encoding rules:  Basic,
 298             Canonical, and Distinguished Encoding Rules", X.690, 1994.
 299
 300
 301 9. Informative References
 302
 303   [X.511]   ITU-T Rec. X.511, "The Directory: Abstract Service
 304             Definition", 1993.
 305
 306
 307 11. Author's Address
 308
 309   Kurt D. Zeilenga
 310   OpenLDAP Foundation
 311   <Kurt@OpenLDAP.org>
 312
 313
 314 Copyright 2002, The Internet Society.  All Rights Reserved.
 315
 316   This document and translations of it may be copied and furnished to
 317   others, and derivative works that comment on or otherwise explain it
 318   or assist in its implementation may be prepared, copied, published and
 319   distributed, in whole or in part, without restriction of any kind,
 320   provided that the above copyright notice and this paragraph are
 321   included on all such copies and derivative works.  However, this
 322   document itself may not be modified in any way, such as by removing
 323   the copyright notice or references to the Internet Society or other
 324   Internet organizations, except as needed for the  purpose of
 325   developing Internet standards in which case the procedures for
 326   copyrights defined in the Internet Standards process must be followed,
 327   or as required to translate it into languages other than English.
 328
 329   The limited permissions granted above are perpetual and will not be
 330   revoked by the Internet Society or its successors or assigns.
 331
 332   This document and the information contained herein is provided on an
 333   "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
 334   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
 335
 336
 337
 338 Zeilenga                       LDAP Cancel                      [Page 6]
 339 \f
 340 INTERNET-DRAFT        draft-zeilenga-ldap-cancel-05          17 May 2002
 341
 342
 343   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 344   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 345   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Zeilenga                       LDAP Cancel                      [Page 7]
 395 \f