git.sur5r.net Git - openldap/blob - doc/drafts/draft-zeilenga-ldapv3bis-opattrs-xx.txt

   1 INTERNET-DRAFT                                      Kurt D. Zeilenga
   2 Intended Category: Standard Track                   OpenLDAP Foundation
   3 Expires: 29 December 2000                           29 June 2000
   4
   5
   6                     LDAPv3: All Operational Attributes
   7                 <draft-zeilenga-ldapv3bis-opattrs-00.txt>
   8
   9
  10 1.      Status of this Memo
  11
  12   This document is an Internet-Draft and is in full conformance with all
  13   provisions of Section 10 of RFC2026.
  14
  15   This document is intended to be, after appropriate review and
  16   revision, submitted to the RFC Editor as a Standard Track document.
  17   Distribution of this memo is unlimited.  Technical discussion of this
  18   document will take place on the IETF LDAP Extension Working Group
  19   mailing list <ietf-ldapext@netscape.com>.  Please send editorial
  20   comments directly to the author <Kurt@OpenLDAP.org>.
  21
  22   Internet-Drafts are working documents of the Internet Engineering Task
  23   Force (IETF), its areas, and its working groups.  Note that other
  24   groups may also distribute working documents as Internet-Drafts.
  25   Internet-Drafts are draft documents valid for a maximum of six months
  26   and may be updated, replaced, or obsoleted by other documents at any
  27   time.  It is inappropriate to use Internet-Drafts as reference
  28   material or to cite them other than as ``work in progress.''
  29
  30   The list of current Internet-Drafts can be accessed at
  31   http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
  32   Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
  33
  34   Copyright 2000, The Internet Society.  All Rights Reserved.
  35
  36   Please see the Copyright section near the end of this document for
  37   more information.
  38
  39
  40 2.      Overview
  41
  42   X.500 provides a mechanism for clients to request all operational
  43   attributes be returned with entries provided in response to a search
  44   operation.   LDAP [RFC2251] does not provide a similar mechanism to
  45   clients to request the return of operational attributes.  The lack of
  46   such a mechanisms hinders discovery of operational attributes present
  47   in an entry.
  48
  49
  50
  51
  52 Zeilenga                                                        [Page 1]
  53 \f
  54 INTERNET-DRAFT     draft-zeilenga-ldapv3bis-opattrs-00      13 June 2000
  55
  56
  57   This document defines a simple mechanism which clients may use to
  58   request all operation attributes.  This document updates RFC 2251 as
  59   detailed below.
  60
  61   The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
  62   NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'',  and ``MAY'' in
  63   this document are to be interpreted as described in RFC 2119
  64   [RFC2119].
  65
  66
  67 3.      Changes to RFC 2251
  68
  69   This document updates RFC 2251 as follows:
  70
  71   In Section 3.2.1, Attributes of Entries, the paragraph:
  72       Some attributes, termed operational attributes, are used by
  73       servers for administering the directory system itself.  They are
  74       not returned in search results unless explicitly requested by
  75       name.  Attributes which are not operational, such as "mail", will
  76       have their schema and syntax constraints enforced by servers, but
  77       servers will generally not make use of their values.
  78
  79   is replaced with:
  80       Some attributes, termed operational attributes, are used by
  81       servers for administering the directory system itself.  They are
  82       not returned in search results unless explicitly requested.
  83       Attributes which are not operational, such as "mail", will have
  84       their schema and syntax constraints enforced by servers, but
  85       servers will generally not make use of their values.
  86
  87   In Section 4.5.1, Search Request, the paragraph:
  88       - attributes: A list of the attributes to be returned from each
  89       entry which matches the search filter. There are two special
  90       values which may be used: an empty list with no attributes, and
  91       the attribute description string "*".  Both of these signify that
  92       all user attributes are to be returned.  (The "*" allows the
  93       client to request all user attributes in addition to specific
  94       operational attributes).
  95
  96   is replaced with:
  97       - attributes: A list of the attributes to be returned from each
  98       entry which matches the search filter. There are three special
  99       values which may be used.  An empty list with no attributes
 100       signifies that all user attributes are to be returned.  An
 101       attribute list containing the attribute description string "*"
 102       signifies that all user attributes are to be returned.   An
 103       attribute list containing the attribute description string "+"
 104       signifies that all operational attributes are to be returned.
 105
 106
 107
 108 Zeilenga                                                        [Page 2]
 109 \f
 110 INTERNET-DRAFT     draft-zeilenga-ldapv3bis-opattrs-00      13 June 2000
 111
 112
 113       (The "*" allows the client to request all user attributes in
 114       addition to any requested operational attributes.  The "+" allows
 115       the client to request all operational attributes in addition to
 116       requested user attributes.  A client may list both "*" and "+" to
 117       request all attributes.)
 118
 119   and the paragraph:
 120       Client implementors should note that even if all user attributes
 121       are requested, some attributes of the entry may not be included in
 122       search results due to access control or other restrictions.
 123       Furthermore, servers will not return operational attributes, such
 124       as objectClasses or attributeTypes, unless they are listed by
 125       name, since there may be extremely large number of values for
 126       certain operational attributes. (A list of operational attributes
 127       for use in LDAP is given in [5].)
 128
 129   is replaced with:
 130       Client implementors should note that results may not include all
 131       requested attributes due to access controls or other restrictions.
 132       In addition, client implementors should request types only be
 133       returned when discovering operational attributes as certain
 134       operational attributes may have extremely large number of values.
 135       Furthermore, servers will not return operational attributes, such
 136       as objectClasses or attributeTypes, unless they are requested,
 137       since there may be extremely large number of values for certain
 138       operational attributes. (A list of operational attributes for use
 139       in LDAP is given in [5].)
 140
 141
 142 5.      Interoperability Considerations
 143
 144   The addition of this mechanism to LDAPv3 is not believed to cause
 145   significant interoperability problems.  A server which does not
 146   support the "+" should ignore the attribute description per RFC 2251,
 147   section 4.5.1 and only return the attributes for the attribute
 148   descriptions strings they do recognize.   From the client's
 149   perspective, this is one possible "other restriction" noted above.
 150
 151
 152 5.      Security Considerations
 153
 154   This document provides a mechanism which clients may use to discover
 155   operational attributes.  Access controls should be used to restrict
 156   access to operational attributes per local policy.
 157
 158
 159 6.      Copyright
 160
 161
 162
 163
 164 Zeilenga                                                        [Page 3]
 165 \f
 166 INTERNET-DRAFT     draft-zeilenga-ldapv3bis-opattrs-00      13 June 2000
 167
 168
 169   Copyright 2000, The Internet Society.  All Rights Reserved.
 170
 171   This document and translations of it may be copied and furnished to
 172   others, and derivative works that comment on or otherwise explain it
 173   or assist in its implementation may be prepared, copied, published and
 174   distributed, in whole or in part, without restriction of any kind,
 175   provided that the above copyright notice and this paragraph are
 176   included on all such copies and derivative works.  However, this
 177   document itself may not be modified in any way, such as by removing
 178   the copyright notice or references to the Internet Society or other
 179   Internet organizations, except as needed for the  purpose of
 180   developing Internet standards in which case the procedures for
 181   copyrights defined in the Internet Standards process must be followed,
 182   or as required to translate it into languages other than English.
 183
 184   The limited permissions granted above are perpetual and will not be
 185   revoked by the Internet Society or its successors or assigns.
 186
 187   This document and the information contained herein is provided on an
 188   "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
 189   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
 190   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 191   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 192   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 193
 194 7.      Bibliography
 195
 196   [RFC2219]       S. Bradner, "Key words for use in RFCs to Indicate
 197                   Requirement Levels", RFC 2119, March 1997.
 198
 199   [RFC2251]       M. Wahl, T. Howes, S. Kille, "Lightweight
 200                   Directory Access Protocol (v3)", RFC 2251,
 201                   December 1997.
 202
 203   [X.500]         ITU-T Rec. X.500, "The Directory: Overview of
 204                   Concepts, Models and Service",  1993.
 205
 206
 207 8.     Author's Address
 208
 209   Kurt D. Zeilenga
 210   OpenLDAP Foundation
 211   <Kurt@OpenLDAP.org>
 212
 213
 214
 215
 216
 217
 218
 219
 220 Zeilenga                                                        [Page 4]
 221 \f