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

   1
   2
   3
   4
   5
   6 INTERNET-DRAFT                                      Kurt D. Zeilenga
   7 Intended Category: Standard Track                OpenLDAP Foundation
   8 Expires in six months                               10 February 2005
   9
  10
  11
  12                          LDAP Read Entry Controls
  13                   <draft-zeilenga-ldap-readentry-04.txt>
  14
  15
  16 1.      Status of this Memo
  17
  18   This document is intended to be, after appropriate review and
  19   revision, submitted to the RFC Editor as a Standard Track document.
  20   Distribution of this memo is unlimited.  Technical discussion of this
  21   document will take place on the IETF LDAP Extensions mailing list
  22   <ldapext@ietf.org>.  Please send editorial comments directly to the
  23   author <Kurt@OpenLDAP.org>.
  24
  25   By submitting this Internet-Draft, I accept the provisions of Section
  26   4 of RFC 3667.  By submitting this Internet-Draft, I certify that any
  27   applicable patent or other IPR claims of which I am aware have been
  28   disclosed, or will be disclosed, and any of which I become aware will
  29   be disclosed, in accordance with RFC 3668.
  30
  31   Internet-Drafts are working documents of the Internet Engineering Task
  32   Force (IETF), its areas, and its working groups. Note that other
  33   groups may also distribute working documents as Internet-Drafts.
  34
  35   Internet-Drafts are draft documents valid for a maximum of six months
  36   and may be updated, replaced, or obsoleted by other documents at any
  37   time. It is inappropriate to use Internet-Drafts as reference material
  38   or to cite them other than as "work in progress."
  39
  40   The list of current Internet-Drafts can be accessed at
  41   http://www.ietf.org/1id-abstracts.html
  42
  43   The list of Internet-Draft Shadow Directories can be accessed at
  44   http://www.ietf.org/shadow.html
  45
  46
  47   Copyright (C) The Internet Society (2005).  All Rights Reserved.
  48
  49   Please see the Full Copyright section near the end of this document
  50   for more information.
  51
  52
  53
  54
  55
  56
  57 Zeilenga                LDAP Read Entry Controls                [Page 1]
  58 \f
  59 INTERNET-DRAFT      draft-zeilenga-ldap-readentry-04    10 February 2005
  60
  61
  62 Abstract
  63
  64   This document specifies an extension to the Lightweight Directory
  65   Access Protocol (LDAP) to allow the client to read the target entry of
  66   an update operation.  The client may request to read the entry before
  67   and/or after the modifications are applied.  These reads are done as
  68   an atomic part of the update operation.
  69
  70
  71 1. Background and Intent of Use
  72
  73   This document specifies an extension to the Lightweight Directory
  74   Access Protocol (LDAP) [Roadmap] to allow the client to read the
  75   target entry of an update operation (e.g., Add, Delete, Modify,
  76   ModifyDN).  The extension utilizes controls [Protocol] attached to
  77   update requests to request and return copies of the target entry.  One
  78   request control, called the Pre-Read request control, indicates that a
  79   copy of the entry before application of update is to be returned.
  80   Another control, called the Post-Read request control, indicates that
  81   a copy of the entry after application of the update is to be returned.
  82   Each request control has a corresponding response control used to
  83   return the entry.
  84
  85   To ensure proper isolation, the controls are processed as an atomic
  86   part of the update operation.
  87
  88   The functionality offered by these controls is based upon similar
  89   functionality in the X.500 Directory Access Protocol (DAP) [X.511].
  90
  91   The Pre-Read controls may be used to obtain replaced or deleted values
  92   of modified attributes or a copy of the entry being deleted.
  93
  94   The Post-Read controls may be used to obtain values of operational
  95   attributes, such as the 'entryUUID' [EntryUUID] and 'modifyTimestamp'
  96   [Models] attributes, updated by the server as part of the update
  97   operation.
  98
  99
 100 2. Terminology
 101
 102   Protocol elements are described using ASN.1 [X.680] with implicit
 103   tags.  The term "BER-encoded" means the element is to be encoded using
 104   the Basic Encoding Rules [X.690] under the restrictions detailed in
 105   Section 5.2 of [Protocol].
 106
 107   DN stands for Distinguished Name.
 108   DSA stands for Directory System Agent (i.e., a directory server).
 109   DSE stands for DSA-specific Entry.
 110
 111
 112
 113 Zeilenga                LDAP Read Entry Controls                [Page 2]
 114 \f
 115 INTERNET-DRAFT      draft-zeilenga-ldap-readentry-04    10 February 2005
 116
 117
 118   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 119   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 120   document are to be interpreted as described in BCP 14 [RFC2119].
 121
 122
 123 3. Read Entry Controls
 124
 125 3.1. The Pre-Read Controls
 126
 127   The Pre-Read request and response controls are identified by the
 128   IANA-ASSIGNED-OID.1 object identifier.  Servers implementing these
 129   controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
 130   'supportedControl' [Models] in their root DSE.
 131
 132   The Pre-Read request control is an LDAP Control [Protocol] whose
 133   controlType is IANA-ASSIGNED-OID.1 and whose controlValue is a
 134   BER-encoded AttributeSelection [Protocol], as extended by [RFC3673].
 135   The criticality may be TRUE or FALSE.  This control is appropriate for
 136   the modifyRequest, delRequest, and modDNRequest LDAP messages.
 137
 138   The corresponding response control is a LDAP Control whose controlType
 139   is IANA-ASSIGNED-OID.1 and whose the controlValue, an OCTET STRING,
 140   contains a BER-encoded SearchResultEntry.  The criticality may be TRUE
 141   or FALSE.  This control is appropriate for the modifyResponse,
 142   delResponse, and modDNResponse LDAP messages with a resultCode of
 143   success (0).
 144
 145   When the request control is attached to an appropriate update LDAP
 146   request, the control requests the return of a copy of target entry
 147   prior to the application of the update.  The AttributeSelection
 148   indicates, as discussed in [Protocol][RFC3673] which attributes are
 149   requested to appear in the copy.  The server is to return a
 150   SearchResultEntry containing, subject to access controls and other
 151   constraints, values of the requested attributes.
 152
 153   The normal processing of the update operation and the processing of
 154   this control MUST be performed as one atomic action isolated from
 155   other update operations.
 156
 157   If the update operation fails (in either normal or control
 158   processing), no response control is provided.
 159
 160
 161 3.2. The Post-Read Controls
 162
 163   The Post-Read request and response controls are identified by the
 164   IANA-ASSIGNED-OID.2 object identifier.  Servers implementing these
 165   controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
 166
 167
 168
 169 Zeilenga                LDAP Read Entry Controls                [Page 3]
 170 \f
 171 INTERNET-DRAFT      draft-zeilenga-ldap-readentry-04    10 February 2005
 172
 173
 174   'supportedControl' [Models] in their root DSE.
 175
 176   The Post-Read request control is an LDAP Control [Protocol] whose
 177   controlType is IANA-ASSIGNED-OID.2 and whose controlValue, an OCTET
 178   STRING, contains a BER-encoded AttributeSelection [Protocol], as
 179   extended by [RFC3673].  The criticality may be TRUE or FALSE.  This
 180   control is appropriate for the addRequest, modifyRequest, and
 181   modDNRequest LDAP messages.
 182
 183   The corresponding response control is a LDAP Control whose controlType
 184   is IANA-ASSIGNED-OID.2 and whose controlValue is a BER-encoded
 185   SearchResultEntry.  The criticality may be TRUE or FALSE.  This
 186   control is appropriate for the addResponse, modifyResponse, and
 187   modDNResponse LDAP messages with a resultCode of success (0).
 188
 189   When the request control is attached to an appropriate update LDAP
 190   request, the control requests the return of a copy of target entry
 191   after the application of the update.  The AttributeSelection
 192   indicates, as discussed in [Protocol][RFC3673], which attributes are
 193   requested to appear in the copy.  The server is to return a
 194   SearchResultEntry containing, subject to access controls and other
 195   constraints, values of the requested attributes.
 196
 197   The normal processing of the update operation and the processing of
 198   this control MUST be performed as one atomic action isolated from
 199   other update operations.
 200
 201   If the update operation fails (in either normal or control
 202   processing), no response control is provided.
 203
 204
 205 4. Interaction with other controls
 206
 207   The Pre-Read and Post-Read controls may be combined with each other
 208   and/or with a variety of other controls.  When combined with the
 209   assertion control [Assertion] and/or the manageDsaIT control
 210   [RFC3296], the semantics of each control included in the combination
 211   apply.  The Pre-Read and Post-Read controls may be combined with other
 212   controls as detailed in other technical specifications.
 213
 214
 215 5. Security Considerations
 216
 217   The controls defined in this document extend update operations to
 218   support read capabilities.  Servers MUST ensure that the client is
 219   authorized both for reading of the information provided in this
 220   control in addition to ensuring the client is authorized to perform
 221   the requested directory update.
 222
 223
 224
 225 Zeilenga                LDAP Read Entry Controls                [Page 4]
 226 \f
 227 INTERNET-DRAFT      draft-zeilenga-ldap-readentry-04    10 February 2005
 228
 229
 230   Security considerations for the update operations [Protocol] extended
 231   by this control, as well as general LDAP security considerations
 232   [Roadmap], generally apply to implementation and use of this extension
 233
 234
 235 6.  IANA Considerations
 236
 237   Registration of the following protocol values [BCP64bis] is requested.
 238
 239
 240 6.1.  Object Identifier
 241
 242   It is requested that IANA register an LDAP Object Identifier to
 243   identify LDAP protocol elements defined in this document.
 244
 245       Subject: Request for LDAP Object Identifier Registration
 246       Person & email address to contact for further information:
 247            Kurt Zeilenga <kurt@OpenLDAP.org>
 248       Specification: RFC XXXX
 249       Author/Change Controller: IESG
 250       Comments:
 251            Identifies the LDAP Read Entry Controls
 252
 253
 254 6.2.  LDAP Protocol Mechanisms
 255
 256   It is requested that IANA register the LDAP Protocol Mechanism
 257   described in this document.
 258
 259       Subject: Request for LDAP Protocol Mechanism Registration
 260       Object Identifier: IANA-ASSIGNED-OID.1
 261       Description: LDAP Pre-read Control
 262       Person & email address to contact for further information:
 263            Kurt Zeilenga <kurt@openldap.org>
 264       Usage: Control
 265       Specification: RFC XXXX
 266       Author/Change Controller: IESG
 267       Comments: none
 268       in 2
 269
 270       Subject: Request for LDAP Protocol Mechanism Registration
 271       Object Identifier: IANA-ASSIGNED-OID.2
 272       Description: LDAP Post-read Control
 273       Person & email address to contact for further information:
 274            Kurt Zeilenga <kurt@openldap.org>
 275       Usage: Control
 276       Specification: RFC XXXX
 277       Author/Change Controller: IESG
 278
 279
 280
 281 Zeilenga                LDAP Read Entry Controls                [Page 5]
 282 \f
 283 INTERNET-DRAFT      draft-zeilenga-ldap-readentry-04    10 February 2005
 284
 285
 286       Comments: none
 287
 288
 289 7. Acknowledgment
 290
 291   The LDAP Pre-Read and Post-Read controls are modeled after similar
 292   capabilities offered in the DAP [X.511].
 293
 294
 295 8. References
 296
 297   [[Note to the RFC Editor: please replace the citation tags used in
 298   referencing Internet-Drafts with tags of the form RFCnnnn where
 299   possible.]]
 300
 301
 302 8.1. Normative References
 303
 304   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 305                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 306
 307   [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
 308                 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
 309                 progress.
 310
 311   [Protocol]    Sermersheim, J. (editor), "LDAP: The Protocol",
 312                 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
 313
 314   [Models]      Zeilenga, K. (editor), "LDAP: Directory Information
 315                 Models", draft-ietf-ldapbis-models-xx.txt, a work in
 316                 progress.
 317
 318   [RFC3296]     Zeilenga, K., "Named Subordinate References in
 319                 Lightweight Directory Access Protocol (LDAP)
 320                 Directories", RFC 3296, July 2002.
 321
 322   [RFC3673]     Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
 323                 3673, December 2003.
 324
 325   [Assertion]   Zeilenga, K., "LDAP Assertion Control",
 326                 draft-zeilenga-ldap-assert-xx.txt, a work in progress.
 327
 328   [X.680]       International Telecommunication Union -
 329                 Telecommunication Standardization Sector, "Abstract
 330                 Syntax Notation One (ASN.1) - Specification of Basic
 331                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
 332
 333   [X.690]       International Telecommunication Union -
 334
 335
 336
 337 Zeilenga                LDAP Read Entry Controls                [Page 6]
 338 \f
 339 INTERNET-DRAFT      draft-zeilenga-ldap-readentry-04    10 February 2005
 340
 341
 342                 Telecommunication Standardization Sector, "Specification
 343                 of ASN.1 encoding rules: Basic Encoding Rules (BER),
 344                 Canonical Encoding Rules (CER), and Distinguished
 345                 Encoding Rules (DER)", X.690(1997) (also ISO/IEC
 346                 8825-1:1998).
 347
 348
 349 8.2. Informative References
 350
 351   [BCP64bis]    Zeilenga, K., "IANA Considerations for LDAP",
 352                 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
 353
 354   [EntryUUID]   Zeilenga, K., "The LDAP EntryUUID Operational
 355                 Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
 356                 progress.
 357
 358   [X.511]       International Telecommunication Union -
 359                 Telecommunication Standardization Sector, "The
 360                 Directory: Abstract Service Definition", X.511(1993)
 361                 (also ISO/IEC 9594-3:1993).
 362
 363
 364 10. Author's Address
 365
 366   Kurt D. Zeilenga
 367   OpenLDAP Foundation
 368
 369   Email: Kurt@OpenLDAP.org
 370
 371
 372
 373 Intellectual Property Rights
 374
 375   The IETF takes no position regarding the validity or scope of any
 376   Intellectual Property Rights or other rights that might be claimed to
 377   pertain to the implementation or use of the technology described in
 378   this document or the extent to which any license under such rights
 379   might or might not be available; nor does it represent that it has
 380   made any independent effort to identify any such rights.  Information
 381   on the procedures with respect to rights in RFC documents can be found
 382   in BCP 78 and BCP 79.
 383
 384   Copies of IPR disclosures made to the IETF Secretariat and any
 385   assurances of licenses to be made available, or the result of an
 386   attempt made to obtain a general license or permission for the use of
 387   such proprietary rights by implementers or users of this specification
 388   can be obtained from the IETF on-line IPR repository at
 389   http://www.ietf.org/ipr.
 390
 391
 392
 393 Zeilenga                LDAP Read Entry Controls                [Page 7]
 394 \f
 395 INTERNET-DRAFT      draft-zeilenga-ldap-readentry-04    10 February 2005
 396
 397
 398   The IETF invites any interested party to bring to its attention any
 399   copyrights, patents or patent applications, or other proprietary
 400   rights that may cover technology that may be required to implement
 401   this standard.  Please address the information to the IETF at
 402   ietf-ipr@ietf.org.
 403
 404
 405
 406 Full Copyright
 407
 408   Copyright (C) The Internet Society (2005).  This document is subject
 409   to the rights, licenses and restrictions contained in BCP 78, and
 410   except as set forth therein, the authors retain all their rights.
 411
 412   This document and the information contained herein are provided on an
 413   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 414   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 415   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 416   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 417   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 418   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449 Zeilenga                LDAP Read Entry Controls                [Page 8]
 450 \f
 451
 452