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

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        K. Zeilenga
   8 Request for Comments: 3674                           OpenLDAP Foundation
   9 Category: Standards Track                                  December 2003
  10
  11
  12    Feature Discovery in Lightweight Directory Access Protocol (LDAP)
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  25
  26 Abstract
  27
  28    The Lightweight Directory Access Protocol (LDAP) is an extensible
  29    protocol with numerous elective features.  This document introduces a
  30    general mechanism for discovery of elective features and extensions
  31    which cannot be discovered using existing mechanisms.
  32
  33 1.  Background and Intended Use
  34
  35    The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
  36    extensible protocol with numerous elective features.  LDAP provides
  37    mechanisms for a client to discover supported protocol versions,
  38    controls, extended operations, Simple Authentication and Security
  39    Layer (SASL) mechanisms, and subschema information.  However, these
  40    mechanisms are not designed to support general feature discovery.
  41
  42    This document describes a simple, general-purpose mechanism which
  43    clients may use to discover the set of elective features supported by
  44    a server.  For example, this mechanism could be used by a client to
  45    discover whether or not the server supports requests for all
  46    operational attributes, e.g., "+" [RFC3673].  As another example,
  47    this mechanism could be used to discover absolute true, e.g., "(&)"
  48    and false, e.g., "(|)", search filters [T-F] support.
  49
  50    This document extends the LDAP Protocol Mechanism registry [RFC3383]
  51    to support registration of values of the supportedFeatures attribute.
  52    This registry is managed by the Internet Assigned Numbers Authority
  53    (IANA).
  54
  55
  56
  57
  58 Zeilenga                    Standards Track                     [Page 1]
  59 \f
  60 RFC 3674               Feature Discovery in LDAP           December 2003
  61
  62
  63    Schema definitions are provided using LDAP description formats
  64    [RFC2252].  Definitions provided here are formatted (line wrapped)
  65    for readability.
  66
  67    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  68    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  69    document are to be interpreted as described in BCP 14 [RFC2119].
  70
  71 2.  Discovery of supported features
  72
  73    Each elective feature whose support may be discovered SHALL be
  74    identified by an Object Identifier (OID).  A server advertises its
  75    support for a given feature by providing the OID associated with the
  76    feature as a value of the 'supportedFeatures' attribute held in the
  77    root DSE.  A client may examine the values of this attribute to
  78    determine if a particular feature is supported by the server.  A
  79    client MUST ignore values it doesn't recognize as they refer to
  80    elective features it doesn't implement.
  81
  82    Features associated with Standard Track protocol mechanisms MUST be
  83    registered.  Features associated with other protocol mechanisms
  84    SHOULD be registered.  Procedures for registering protocol mechanisms
  85    are described in BCP 64 [RFC3383].  The word "Feature" should be
  86    placed in the usage field of the submitted LDAP Protocol Mechanism
  87    template.
  88
  89    The 'supportedFeatures' attribute type is described as follows:
  90
  91       ( 1.3.6.1.4.1.4203.1.3.5
  92         NAME 'supportedFeatures'
  93         DESC 'features supported by the server'
  94         EQUALITY objectIdentifierMatch
  95         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
  96         USAGE dSAOperation )
  97
  98    Servers MUST be capable of recognizing this attribute type by the
  99    name 'supportedFeatures'.  Servers MAY recognize the attribute type
 100    by other names.
 101
 102 3.  Security Considerations
 103
 104    As rogue clients can discover features of a server by other means
 105    (such as by trial and error), this feature discovery mechanism is not
 106    believed to introduce any new security risk to LDAP.
 107
 108
 109
 110
 111
 112
 113
 114 Zeilenga                    Standards Track                     [Page 2]
 115 \f
 116 RFC 3674               Feature Discovery in LDAP           December 2003
 117
 118
 119 4.  IANA Considerations
 120
 121 4.1.  Registration of Features as Protocol Mechanisms
 122
 123    Future specifications detailing LDAP features are to register each
 124    feature as a LDAP Protocol Mechanism per guidance given in BCP 64
 125    [RFC3383].  A usage of "Feature" in a Protocol Mechanism registration
 126    template indicates that the value to be registered is associated with
 127    an LDAP feature.
 128
 129 4.2.  Registration of the supportedFeatures descriptor
 130
 131    The IANA has registered the LDAP 'supportedFeatures' descriptor.  The
 132    following registration template is suggested:
 133
 134       Subject: Request for LDAP Descriptor Registration
 135       Descriptor (short name): supportedFeatures
 136       Object Identifier: 1.3.6.1.4.1.4203.1.3.5
 137       Person & email address to contact for further information:
 138           Kurt Zeilenga <kurt@OpenLDAP.org>
 139       Usage: Attribute Type
 140       Specification: RFC 3674
 141       Author/Change Controller: IESG
 142
 143    This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
 144    assigned private enterprise allocation [PRIVATE] for use in this
 145    specification.
 146
 147 5.  Acknowledgment
 148
 149    This document is based upon input from the IETF LDAPEXT working
 150    group.
 151
 152 6.  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 3674               Feature Discovery in LDAP           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 7.  References
 182
 183 7.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    [RFC2252]     Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
 189                  "Lightweight Directory Access Protocol (v3):  Attribute
 190                  Syntax Definitions", RFC 2252, December 1997.
 191
 192    [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
 193                  Protocol (v3): Technical Specification", RFC 3377,
 194                  September 2002.
 195
 196    [RFC3383]     Zeilenga, K., "Internet Assigned Numbers Authority
 197                  (IANA) Considerations for Lightweight Directory Access
 198                  Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
 199
 200 7.2.  Informative References
 201
 202    [RFC3673]     Zeilenga, K., "Lightweight Directory Access Protocol
 203                  version 3 (LDAPv3): All Operational Attributes", RFC
 204                  3673, December 2003.
 205
 206    [T-F]         Zeilenga, K., "LDAP True/False Filters", Work in
 207                  Progress.
 208
 209    [ASSIGN]      OpenLDAP Foundation, "OpenLDAP OID Delegations",
 210                  http://www.openldap.org/foundation/oid-delegate.txt.
 211
 212    [PRIVATE]     IANA, "Private Enterprise Numbers",
 213                  http://www.iana.org/assignments/enterprise-numbers.
 214
 215 8.  Author's Address
 216
 217    Kurt D. Zeilenga
 218    OpenLDAP Foundation
 219
 220    EMail: Kurt@OpenLDAP.org
 221
 222
 223
 224
 225
 226 Zeilenga                    Standards Track                     [Page 4]
 227 \f
 228 RFC 3674               Feature Discovery in LDAP           December 2003
 229
 230
 231 9.  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