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                               18 July 2005
  10
  11
  12
  13                Requesting Attributes by Object Class in the
  14                   Lightweight Directory Access Protocol
  15                    <draft-zeilenga-ldap-adlist-11.txt>
  16
  17
  18 Status of this Memo
  19
  20   This document is intended to be, after appropriate review and
  21   revision, submitted to the RFC Editor as an Informational document.
  22   Distribution of this memo is unlimited.  Technical discussion of this
  23   document will take place on the IETF LDAP Extensions mailing list
  24   <ldapext@ietf.org>.  Please send editorial comments directly to the
  25   author <Kurt@OpenLDAP.org>.
  26
  27   By submitting this Internet-Draft, each author represents that any
  28   applicable patent or other IPR claims of which he or she is aware have
  29   been or will be disclosed, and any of which he or she becomes aware
  30   will be disclosed, in accordance with Section 6 of BCP 79.
  31
  32   Internet-Drafts are working documents of the Internet Engineering Task
  33   Force (IETF), its areas, and its working groups. Note that other
  34   groups may also distribute working documents as Internet-Drafts.
  35
  36   Internet-Drafts are draft documents valid for a maximum of six months
  37   and may be updated, replaced, or obsoleted by other documents at any
  38   time. It is inappropriate to use Internet-Drafts as reference material
  39   or to cite them other than as "work in progress."
  40
  41   The list of current Internet-Drafts can be accessed at
  42   http://www.ietf.org/1id-abstracts.html
  43
  44   The list of Internet-Draft Shadow Directories can be accessed at
  45   http://www.ietf.org/shadow.html
  46
  47
  48   Copyright (C) The Internet Society (2005).  All Rights Reserved.
  49
  50   Please see the Full Copyright section near the end of this document
  51   for more information.
  52
  53
  54
  55
  56
  57
  58 Zeilenga          Requesting Attributes by Object Class         [Page 1]
  59 \f
  60 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-11         18 July 2005
  61
  62
  63 Abstract
  64
  65   The Lightweight Directory Access Protocol (LDAP) search operation
  66   provides mechanisms for clients to request all user application
  67   attributes, all operational attributes, and/or attributes selected by
  68   their description.  This document extends LDAP to support a mechanism
  69   that LDAP clients may use to request the return of all attributes of
  70   an object class.
  71
  72
  73 1.  Background and Intended Use
  74
  75   In the Lightweight Directory Access Protocol (LDAP) [Roadmap], the
  76   search operation [Protocol] support requesting the return of a set of
  77   attributes.  This set is determined by a list of attribute
  78   descriptions.  Two special descriptors are defined to request all user
  79   attributes ("*") [Protocol] and all operational attributes ("+")
  80   [RFC3673].  However, there is no convenient mechanism for requesting
  81   pre-defined sets of attributes such as the set of attributes used to
  82   represent a particular class of object.
  83
  84   This document extends LDAP to allow an object class identifier to be
  85   specified in attributes lists, such as in Search requests, to request
  86   the return all attributes belonging to an object class.  The
  87   COMMERCIAL AT ("@", U+0040) character is used to distinguish an object
  88   class identifier from an attribute descriptions.
  89
  90   For example, the attribute list of "@country" is equivalent to the
  91   attribute list of 'c', 'searchGuide', 'description', and
  92   'objectClass'.  This object class is described in [Schema].
  93
  94   This extension is intended primarily to be used where the user is in
  95   direct control of the parameters of the LDAP search operation, for
  96   instance when entering a LDAP URL [LDAPURL] into a web browser.  For
  97   example,      <ldap:///dc=example,dc=com?@organization?base>.
  98
  99 2. Terminology
 100
 101   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 102   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 103   document are to be interpreted as described in BCP 14 [RFC2119].
 104
 105   DSA stands for Directory System Agent (or server).
 106   DSE stands for DSA-specific Entry.
 107
 108
 109 3.  Return of all Attributes of an Object Class
 110
 111
 112
 113
 114 Zeilenga          Requesting Attributes by Object Class         [Page 2]
 115 \f
 116 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-11         18 July 2005
 117
 118
 119   This extension allows object class identifiers is to be provided in
 120   the attributes field of the LDAP SearchRequest [Protocol] or other
 121   request values of the AttributeSelection data type (e.g., attributes
 122   field in pre/post read controls [ReadEntry]) and/or
 123   <attributeSelector> production (e.g., attributes of an LDAP URL
 124   [LDAPURL]).  For each object class identified in the attributes field,
 125   the request is to be treated as if each attribute allowed by that
 126   class (by "MUST" or "MAY", directly or by "SUP"erior) [Models] was
 127   itself listed.
 128
 129   This extension extends attributeSelector [Protocol] production as
 130   indicated by the following ABNF [ABNF]:
 131
 132        attributeSelector /= objectclassdescription
 133        objectclassdescription = ATSIGN oid options
 134        ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
 135
 136   where <oid> and <options> productions are as defined in [Models].
 137
 138   The <oid> component of an <objectclassdescription> production
 139   identifies the object class by short name (descr) or object identifier
 140   (numericoid).  If the value of the <oid> component is unrecognized or
 141   does not refer to an object class, the object class description is be
 142   treated an an unrecognized attribute description.
 143
 144   The <options> production is included in the grammar for extensibility
 145   purposes.  An object class description with an unrecognized or
 146   inappropriate option is to be treated as an unrecognized.
 147
 148   While object class description options and attribute description
 149   options share the same syntax, they are not semantically related.
 150   This document does not define any object description option.
 151
 152   Servers supporting this feature SHOULD publish the object identifier
 153   (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
 154   [Models] attribute in the root DSE.  Clients supporting this feature
 155   SHOULD NOT use the feature unless they have knowledge the server
 156   supports it.
 157
 158
 159 3.  Security Considerations
 160
 161   This extension provides a shorthand for requesting all attributes of
 162   an object class.  As these attributes which could have been listed
 163   individually, introduction of this shorthand is not believed to raise
 164   additional security considerations.
 165
 166   Implementors of this LDAP extension should be familiar with security
 167
 168
 169
 170 Zeilenga          Requesting Attributes by Object Class         [Page 3]
 171 \f
 172 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-11         18 July 2005
 173
 174
 175   considerations applicable to the LDAP search operation [Protocol], as
 176   well as general LDAP security considerations [Roadmap].
 177
 178
 179 4.  IANA Considerations
 180
 181   Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
 182   document is requested.
 183
 184       Subject: Request for LDAP Protocol Mechanism Registration
 185       Object Identifier: 1.3.6.1.4.1.4203.1.5.2
 186       Description: OC AD Lists
 187       Person & email address to contact for further information:
 188            Kurt Zeilenga <kurt@openldap.org>
 189       Usage: Feature
 190       Specification: RFC XXXX
 191       Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
 192       Comments: none
 193
 194   This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
 195   IANA-assigned private enterprise allocation [PRIVATE], for use in this
 196   specification.
 197
 198
 199 5.  Author's Address
 200
 201   Kurt D. Zeilenga
 202   OpenLDAP Foundation
 203
 204   Email: Kurt@OpenLDAP.org
 205
 206
 207 6. References
 208
 209   [[Note to the RFC Editor: please replace the citation tags used in
 210   referencing Internet-Drafts with tags of the form RFCnnnn where
 211   possible.]]
 212
 213
 214 6.1. Normative References
 215
 216   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 217                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 218
 219   [ABNF]        Crocker, D. and P. Overell, "Augmented BNF for Syntax
 220                 Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
 221                 work in progress.
 222
 223
 224
 225
 226 Zeilenga          Requesting Attributes by Object Class         [Page 4]
 227 \f
 228 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-11         18 July 2005
 229
 230
 231   [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
 232                 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
 233                 progress.
 234
 235   [Protocol]    Sermersheim, J. (editor), "LDAP: The Protocol",
 236                 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
 237
 238   [Models]      Zeilenga, K. (editor), "LDAP: Directory Information
 239                 Models", draft-ietf-ldapbis-models-xx.txt, a work in
 240                 progress.
 241
 242   [LDAPURL]     Smith, M. (editor), "LDAP: Uniform Resource Locator",
 243                 draft-ietf-ldapbis-url-xx.txt, a work in progress.
 244
 245   [X.680]       International Telecommunication Union -
 246                 Telecommunication Standardization Sector, "Abstract
 247                 Syntax Notation One (ASN.1) - Specification of Basic
 248                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
 249
 250
 251 6.2. Informative References
 252
 253   [RFC3673]     Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
 254                 3673, December 2003.
 255
 256   [Schema]      Dally, K. (editor), "LDAP: User Schema",
 257                 draft-ietf-ldapbis-user-schema-xx.txt, a work in
 258                 progress.
 259
 260   [BCP64bis]    Zeilenga, K., "IANA Considerations for LDAP",
 261                 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
 262
 263   [ReadEntry]   Zeilenga, K., "LDAP Read Entry Controls",
 264                 draft-zeilenga-ldap-readentry-xx.txt, a work in
 265                 progress.
 266
 267   [ASSIGN]      OpenLDAP Foundation, "OpenLDAP OID Delegations",
 268                 http://www.openldap.org/foundation/oid-delegate.txt.
 269
 270   [PRIVATE]     IANA, "Private Enterprise Numbers",
 271                 http://www.iana.org/assignments/enterprise-numbers.
 272
 273
 274
 275 Full Copyright
 276
 277   Copyright (C) The Internet Society (2005).
 278
 279
 280
 281
 282 Zeilenga          Requesting Attributes by Object Class         [Page 5]
 283 \f
 284 INTERNET-DRAFT        draft-zeilenga-ldap-adlist-11         18 July 2005
 285
 286
 287   This document is subject to the rights, licenses and restrictions
 288   contained in BCP 78, and except as set forth therein, the authors
 289   retain all their rights.
 290
 291   This document and the information contained herein are provided on an
 292   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 293   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 294   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 295   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 296   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 297   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 298
 299
 300
 301 Intellectual Property Rights
 302
 303   The IETF takes no position regarding the validity or scope of any
 304   Intellectual Property Rights or other rights that might be claimed to
 305   pertain to the implementation or use of the technology described in
 306   this document or the extent to which any license under such rights
 307   might or might not be available; nor does it represent that it has
 308   made any independent effort to identify any such rights.  Information
 309   on the procedures with respect to rights in RFC documents can be found
 310   in BCP 78 and BCP 79.
 311
 312   Copies of IPR disclosures made to the IETF Secretariat and any
 313   assurances of licenses to be made available, or the result of an
 314   attempt made to obtain a general license or permission for the use of
 315   such proprietary rights by implementers or users of this specification
 316   can be obtained from the IETF on-line IPR repository at
 317   http://www.ietf.org/ipr.
 318
 319   The IETF invites any interested party to bring to its attention any
 320   copyrights, patents or patent applications, or other proprietary
 321   rights that may cover technology that may be required to implement
 322   this standard.  Please address the information to the IETF at
 323   ietf-ipr@ietf.org.
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Zeilenga          Requesting Attributes by Object Class         [Page 6]
 339 \f