git.sur5r.net Git - openldap/blob - doc/rfc/rfc3673.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        K. Zeilenga
   8 Request for Comments: 3673                           OpenLDAP Foundation
   9 Category: Standards Track                                  December 2003
  10
  11
  12        Lightweight Directory Access Protocol version 3 (LDAPv3):
  13                        All Operational Attributes
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  26
  27 Abstract
  28
  29    The Lightweight Directory Access Protocol (LDAP) supports a mechanism
  30    for requesting the return of all user attributes but not all
  31    operational attributes.  This document describes an LDAP extension
  32    which clients may use to request the return of all operational
  33    attributes.
  34
  35 1.  Overview
  36
  37    X.500 [X.500] provides a mechanism for clients to request all
  38    operational attributes be returned with entries provided in response
  39    to a search operation.  This mechanism is often used by clients to
  40    discover which operational attributes are present in an entry.
  41
  42    This documents extends the Lightweight Directory Access Protocol
  43    (LDAP) [RFC3377] to provide a simple mechanism which clients may use
  44    to request the return of all operational attributes.  The mechanism
  45    is designed for use with existing general purpose LDAP clients
  46    (including web browsers which support LDAP URLs) and existing LDAP
  47    APIs.
  48
  49    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  50    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  51    document are to be interpreted as described in BCP 14 [RFC2119].
  52
  53
  54
  55
  56
  57
  58 Zeilenga                    Standards Track                     [Page 1]
  59 \f
  60 RFC 3673           LDAPv3: All Operational Attributes      December 2003
  61
  62
  63 2.  All Operational Attributes
  64
  65    The presence of the attribute description "+" (ASCII 43) in the list
  66    of attributes in a Search Request [RFC2251] SHALL signify a request
  67    for the return of all operational attributes.
  68
  69    As with all search requests, client implementors should note that
  70    results may not include all requested attributes due to access
  71    controls or other restrictions.  Client implementors should also note
  72    that certain operational attributes may be returned only if requested
  73    by name even when "+" is present.  This is because some operational
  74    attributes are very expensive to return.
  75
  76    Servers supporting this feature SHOULD publish the Object Identifier
  77    1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures'
  78    [RFC3674] attribute in the root DSE.
  79
  80 3.  Interoperability Considerations
  81
  82    This mechanism is specifically designed to allow users to request all
  83    operational attributes using existing LDAP clients.  In particular,
  84    the mechanism is designed to be compatible with existing general
  85    purpose LDAP clients including those supporting LDAP URLs [RFC2255].
  86
  87    The addition of this mechanism to LDAP is not believed to cause any
  88    significant interoperability issues (this has been confirmed through
  89    testing).  Servers which have yet to implement this specification
  90    should ignore the "+" as an unrecognized attribute description per
  91    [RFC2251, Section 4.5.1].  From the client's perspective, a server
  92    which does not return all operational attributes when "+" is
  93    requested should be viewed as having other restrictions.
  94
  95    It is also noted that this mechanism is believed to require no
  96    modification of existing LDAP APIs.
  97
  98 4.  Security Considerations
  99
 100    This document provides a general mechanism which clients may use to
 101    discover operational attributes.  Prior to the introduction of this
 102    mechanism, operational attributes were only returned when requested
 103    by name.  Some might have viewed this as obscurity feature.  However,
 104    this feature offers a false sense of security as the attributes were
 105    still transferable.
 106
 107    Implementations SHOULD implement appropriate access controls
 108    mechanisms to restricts access to operational attributes.
 109
 110
 111
 112
 113
 114 Zeilenga                    Standards Track                     [Page 2]
 115 \f
 116 RFC 3673           LDAPv3: All Operational Attributes      December 2003
 117
 118
 119 5.  IANA Considerations
 120
 121    This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
 122    feature described above.  This OID was assigned [ASSIGN] by OpenLDAP
 123    Foundation, under its IANA-assigned private enterprise allocation
 124    [PRIVATE], for use in this specification.
 125
 126    Registration of this feature has been completed by IANA [RFC3674],
 127    [RFC3383].
 128
 129    Subject: Request for LDAP Protocol Mechanism Registration
 130
 131    Object Identifier: 1.3.6.1.4.1.4203.1.5.1
 132
 133    Description: All Op Attrs
 134
 135    Person & email address to contact for further information:
 136         Kurt Zeilenga <kurt@openldap.org>
 137
 138    Usage: Feature
 139
 140    Specification: RFC3673
 141
 142    Author/Change Controller: IESG
 143
 144    Comments: none
 145
 146 6.  Acknowledgment
 147
 148    The "+" mechanism is believed to have been first suggested by Bruce
 149    Greenblatt in a November 1998 post to the IETF LDAPext Working Group
 150    mailing list.
 151
 152 7.  Intellectual Property Statement
 153
 154    The IETF takes no position regarding the validity or scope of any
 155    intellectual property or other rights that might be claimed to
 156    pertain to the implementation or use of the technology described in
 157    this document or the extent to which any license under such rights
 158    might or might not be available; neither does it represent that it
 159    has made any effort to identify any such rights.  Information on the
 160    IETF's procedures with respect to rights in standards-track and
 161    standards-related documentation can be found in BCP-11.  Copies of
 162    claims of rights made available for publication and any assurances of
 163    licenses to be made available, or the result of an attempt made to
 164    obtain a general license or permission for the use of such
 165    proprietary rights by implementors or users of this specification can
 166    be obtained from the IETF Secretariat.
 167
 168
 169
 170 Zeilenga                    Standards Track                     [Page 3]
 171 \f
 172 RFC 3673           LDAPv3: All Operational Attributes      December 2003
 173
 174
 175    The IETF invites any interested party to bring to its attention any
 176    copyrights, patents or patent applications, or other proprietary
 177    rights which may cover technology that may be required to practice
 178    this standard.  Please address the information to the IETF Executive
 179    Director.
 180
 181 8.  References
 182
 183 8.1.  Normative References
 184
 185    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 186               Requirement Levels", BCP 14, RFC 2119, March 1997.
 187
 188    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
 189               Access Protocol (v3)", RFC 2251, December 1997.
 190
 191    [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
 192               Protocol (v3): Technical Specification", RFC 3377,
 193               September 2002.
 194
 195    [RFC3674]  Zeilenga, K., "Feature Discovery in Lightweight Directory
 196               Access Protocol (LDAP)", RFC 3674, December 2003.
 197
 198 8.2.  Informative References
 199
 200    [RFC2255]  Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
 201               December 1997.
 202
 203    [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
 204               Considerations for the Lightweight Directory Access
 205               Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
 206
 207    [X.500]    ITU-T Rec.  X.500, "The Directory: Overview of Concepts,
 208               Models and Service", 1993.
 209
 210    [ASSIGN]   OpenLDAP Foundation, "OpenLDAP OID Delegations",
 211               http://www.openldap.org/foundation/oid-delegate.txt.
 212
 213    [PRIVATE]  IANA, "Private Enterprise Numbers",
 214               http://www.iana.org/assignments/enterprise-numbers.
 215
 216 9.  Author's Address
 217
 218    Kurt D. Zeilenga
 219    OpenLDAP Foundation
 220
 221    EMail: Kurt@OpenLDAP.org
 222
 223
 224
 225
 226 Zeilenga                    Standards Track                     [Page 4]
 227 \f
 228 RFC 3673           LDAPv3: All Operational Attributes      December 2003
 229
 230
 231 10.  Full Copyright Statement
 232
 233    Copyright (C) The Internet Society (2003).  All Rights Reserved.
 234
 235    This document and translations of it may be copied and furnished to
 236    others, and derivative works that comment on or otherwise explain it
 237    or assist in its implementation may be prepared, copied, published
 238    and distributed, in whole or in part, without restriction of any
 239    kind, provided that the above copyright notice and this paragraph are
 240    included on all such copies and derivative works.  However, this
 241    document itself may not be modified in any way, such as by removing
 242    the copyright notice or references to the Internet Society or other
 243    Internet organizations, except as needed for the purpose of
 244    developing Internet standards in which case the procedures for
 245    copyrights defined in the Internet Standards process must be
 246    followed, or as required to translate it into languages other than
 247    English.
 248
 249    The limited permissions granted above are perpetual and will not be
 250    revoked by the Internet Society or its successors or assignees.
 251
 252    This document and the information contained herein is provided on an
 253    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 254    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 255    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 256    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 257    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 258
 259 Acknowledgement
 260
 261    Funding for the RFC Editor function is currently provided by the
 262    Internet Society.
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Zeilenga                    Standards Track                     [Page 5]
 283 \f