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

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                      Kurt D. Zeilenga
   8 Intended Category: Informational                    OpenLDAP Foundation
   9 Expires in six months                               20 December 2002
  10
  11
  12                LDAP: Requesting Attributes by Object Class
  13                    <draft-zeilenga-ldap-adlist-04.txt>
  14
  15
  16 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 an Informational document.
  23   Distribution of this memo is unlimited.  Technical discussion of this
  24   document will take place on the IETF LDAP Extensions Working Group
  25   mailing list <ldapext@ietf.org>.  Please send editorial comments
  26   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   The Lightweight Directory Access Protocol (LDAP) search operation
  50   provides mechanisms for clients to request all user application
  51   attributes, all operational attributes, or attributes selected by
  52   their description.  This document extends LDAP to provide a mechanism
  53   for LDAP clients to request the return of all attributes of an object
  54   class.
  55
  56
  57
  58 Zeilenga          Requesting Attributes by Object Class         [Page 1]
  59 \f
  60 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-04     20 December 2002
  61
  62
  63 1.  Overview
  64
  65   In the Lightweight Directory Access Protocol (LDAP) [RFC3377], the
  66   search operation [RFC2251] support requesting a sets of attributes.
  67   This set is determined by a list of attribute descriptions.  Two
  68   special descriptors are defined to request all user attributes ("*")
  69   [RFC2251] and all operational attributes ("+") [OPATTRS].  However,
  70   there is no convenient mechanism for requesting pre-defined sets of
  71   attributes.
  72
  73   This document extends LDAP to allow an object class identifier to be
  74   specified in search request attributes list to request the return all
  75   attributes allowed by object class.  A plus sign ("+", U+002B) is used
  76   to distinguish an object class identifier from an attribute
  77   descriptions.
  78
  79   For example, the attribute list of "+country" is equivalent to the
  80   attribute list of 'c', 'searchGuide', 'description', and
  81   'objectClass'.  This object class and its attributes are described in
  82   [RFC2256].
  83
  84   This extension is intended to be used where the user is in direct
  85   control of the parameters of the LDAP search operation.
  86
  87   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  88   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  89   document are to be interpreted as described in BCP 14 [RFC2119].
  90
  91
  92 2.  Return of all Attributes of an Object Class
  93
  94   This extension allows object class identifiers is to be provided in
  95   the attributes field of the LDAP SearchRequest [RFC2251].  For each
  96   object class identified in the attributes field, the request is to be
  97   treated as if each attribute allowed by that class (by "MUST" or
  98   "MAY", directly or by SUPerior) was itself listed.
  99
 100   If the object class identifier is unrecognized, it is be treated an an
 101   unrecognized attribute description.
 102
 103   This extension redefines the attributes field of the SearchRequest to
 104   be a DescriptionList described by the following ASN.1 [X.680] data
 105   type:
 106
 107        DescriptionList ::= SEQUENCE OF Description
 108        Description ::= LDAPString
 109
 110   The Description is string conforming to the ABNF [RFC2234]:
 111
 112
 113
 114 Zeilenga          Requesting Attributes by Object Class         [Page 2]
 115 \f
 116 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-04     20 December 2002
 117
 118
 119        Description = AttributeDescription | ObjectClassDescription.
 120        ObjectClassDescription = "+" ObjectClass *( ";" options )
 121
 122   where <AttributeDescription> and <options> productions are as defined
 123   in Section 4.1.5 of [RFC2251] and an <ObjectClass> is an object
 124   identifier, in either <numericoid> or <descr> form [RFC2252], of an
 125   object class.
 126
 127   <ObjectClassDescription> <options> are provided for extensibility.
 128   This document only defines semantics of <ObjectClassDescription>s with
 129   zero options in the attributes field of a SearchRequest.  Other uses
 130   may be defined in future specifications.
 131
 132   Servers supporting this feature SHOULD publish the Object Identifier
 133   1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
 134   [FEATURES] attribute in the root DSE.
 135
 136
 137 3.  Security Considerations
 138
 139   This extension provides a shorthand for requesting all attributes of
 140   an object class.  As these attributes which could have been listed
 141   individually, this short hand is not believed to raise additional
 142   security considerations.
 143
 144   Implementors of this (or any) LDAP extension should be familiar with
 145   general LDAP security considerations [RFC3377].
 146
 147
 148 4.  IANA Considerations
 149
 150   This OID 1.3.6.1.4.1.4203.1.11.2 to identify the LDAP "OC AD List?
 151   feature.  This OID was assigned [ASSIGN] by OpenLDAP Foundation, under
 152   its IANA-assigned private enterprise allocation [PRIVATE], for use in
 153   this specification.
 154
 155   Registration of this protocol mechansism is requested per BCP 64
 156   [RFC3383].
 157
 158       Subject: Request for LDAP Protocol Mechansism Registration
 159       Object Identifier: 1.3.6.1.4.1.4203.1.5.2
 160       Description: OC AD Lists
 161       Person & email address to contact for further information:
 162            Kurt Zeilenga <kurt@openldap.org>
 163       Usage: Feature
 164       Specification: RFCxxxx
 165       Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
 166       Comments: none
 167
 168
 169
 170 Zeilenga          Requesting Attributes by Object Class         [Page 3]
 171 \f
 172 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-04     20 December 2002
 173
 174
 175 5.  Author's Address
 176
 177   Kurt D. Zeilenga
 178   OpenLDAP Foundation
 179   <Kurt@OpenLDAP.org>
 180
 181
 182 6. Normative References
 183
 184   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate
 185              Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 186
 187   [RFC2234]  D. Crocker, P. Overell, "Augmented BNF for Syntax
 188              Specifications: ABNF", RFC 2234, November 1997.
 189
 190   [RFC2251]  M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
 191              Protocol (v3)", RFC 2251, December 1997.
 192
 193   [RFC2252]  M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
 194              Directory Access Protocol (v3):  Attribute Syntax
 195              Definitions", RFC 2252, December 1997.
 196
 197   [RFC3377]  J. Hodges, R. Morgan, "Lightweight Directory Access
 198              Protocol (v3): Technical Specification", RFC 3377,
 199              September 2002.
 200
 201   [FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
 202              draft-zeilenga-ldap-features-xx.txt (a work in progress).
 203
 204   [X.680]    ITU-T, "Abstract Syntax Notation One (ASN.1) -
 205              Specification of Basic Notation", X.680, 1994.
 206
 207
 208 7. Informative References
 209
 210   [RFC2256]  M. Wahl, "A Summary of the X.500(96) User Schema for use
 211              with LDAPv3", RFC 2256, December 1997.
 212
 213   [RFC3383]  K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
 214              September 2002.
 215
 216   [ASSIGN]   OpenLDAP Foundation, "OpenLDAP OID Delegations",
 217              http://www.openldap.org/foundation/oid-delegate.txt.
 218
 219   [PRIVATE]  IANA, "Private Enterprise Numbers",
 220              http://www.iana.org/assignments/enterprise-numbers.
 221
 222
 223
 224
 225
 226 Zeilenga          Requesting Attributes by Object Class         [Page 4]
 227 \f
 228 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-04     20 December 2002
 229
 230
 231 Copyright 2002, The Internet Society.  All Rights Reserved.
 232
 233   This document and translations of it may be copied and furnished to
 234   others, and derivative works that comment on or otherwise explain it
 235   or assist in its implementation may be prepared, copied, published and
 236   distributed, in whole or in part, without restriction of any kind,
 237   provided that the above copyright notice and this paragraph are
 238   included on all such copies and derivative works.  However, this
 239   document itself may not be modified in any way, such as by removing
 240   the copyright notice or references to the Internet Society or other
 241   Internet organizations, except as needed for the  purpose of
 242   developing Internet standards in which case the procedures for
 243   copyrights defined in the Internet Standards process must be followed,
 244   or as required to translate it into languages other than English.
 245
 246   The limited permissions granted above are perpetual and will not be
 247   revoked by the Internet Society or its successors or assigns.
 248
 249   This document and the information contained herein is provided on an
 250   "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
 251   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
 252   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 253   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 254   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Zeilenga          Requesting Attributes by Object Class         [Page 5]
 283 \f