external/bsd/openldap/dist/doc/rfc/rfc3045.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        M. Meredith
   8 Request for Comments: 3045                                   Novell Inc.
   9 Category: Informational                                     January 2001
  10
  11
  12             Storing Vendor Information in the LDAP root DSE
  13
  14 Status of this Memo
  15
  16    This memo provides information for the Internet community.  It does
  17    not specify an Internet standard of any kind.  Distribution of this
  18    memo is unlimited.
  19
  20 Copyright Notice
  21
  22    Copyright (C) The Internet Society (2001).  All Rights Reserved.
  23
  24 Abstract
  25
  26    This document specifies two Lightweight Directory Access Protocol
  27    (LDAP) attributes, vendorName and vendorVersion that MAY be included
  28    in the root DSA-specific Entry (DSE) to advertise vendor-specific
  29    information.  These two attributes supplement the attributes defined
  30    in section 3.4 of RFC 2251.
  31
  32    The information held in these attributes MAY be used for display and
  33    informational purposes and MUST NOT be used for feature advertisement
  34    or discovery.
  35
  36 Conventions used in this document
  37
  38    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  39    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  40    document are to be interpreted as described in [RFC2219]
  41
  42 1. Overview
  43
  44    LDAP clients discover server-specific data--such as available
  45    controls, extensions, etc.--by reading the root DSE.  See section 3.4
  46    of [RFC2251] for details.
  47
  48    For display, information, and limited function discovery, it is
  49    desirable to be able to query an LDAP server to determine the vendor
  50    name of that server and also to see what version of that vendor's
  51    code is currently installed.
  52
  53
  54
  55
  56
  57
  58 Meredith                     Informational                      [Page 1]
  59 \f
  60 RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
  61
  62
  63 1.1 Function discovery
  64
  65    There are many ways in which a particular version of a vendor's LDAP
  66    server implementation may be functionally incomplete, or may contain
  67    software anomalies.  It is impossible to identify every known
  68    shortcoming of an LDAP server with the given set of server data
  69    advertisement attributes.  Furthermore, often times, the anomalies of
  70    an implementation are not found until after the implementation has
  71    been distributed, deployed, and is in use.
  72
  73    The attributes defined in this document MAY be used by client
  74    implementations in order to identify a particular server
  75    implementation so that it can 'work around' such anomalies.
  76
  77    The attributes defined in this document MUST NOT be used to gather
  78    information related to supported features of an LDAP implementation.
  79    All LDAP features, mechanisms, and capabilities--if advertised--MUST
  80    be advertised through other mechanisms, preferably advertisement
  81    mechanisms defined in concert with said features, mechanisms, and
  82    capabilities.
  83
  84 2. Attribute Types
  85
  86    These attributes are an addition to the Server-specific Data
  87    Requirements defined in section 3.4 of [RFC2251].  The associated
  88    syntaxes are defined in section 4 of [RFC2252].
  89
  90    Servers MAY restrict access to vendorName or vendorVersion and
  91    clients MUST NOT expect these attributes to be available.
  92
  93 2.1 vendorName
  94
  95    This attribute contains a single string, which represents the name of
  96    the LDAP server implementer.
  97
  98    All LDAP server implementations SHOULD maintain a vendorName, which
  99    is generally the name of the company that wrote the LDAP Server code
 100    like "Novell, Inc."
 101
 102       ( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY
 103         1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 104         SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
 105
 106 2.2 vendorVersion
 107
 108    This attribute contains a string which represents the version of the
 109    LDAP server implementation.
 110
 111
 112
 113
 114 Meredith                     Informational                      [Page 2]
 115 \f
 116 RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
 117
 118
 119    All LDAP server implementations SHOULD maintain a vendorVersion.
 120    Note that this value is typically a release value--comprised of a
 121    string and/or a string of numbers--used by the developer of the LDAP
 122    server product (as opposed to the supportedLDAPVersion, which
 123    specifies the version of the LDAP protocol supported by this server).
 124    This is single-valued so that it will only have one version value.
 125    This string MUST be unique between two versions, but there are no
 126    other syntactic restrictions on the value or the way it is formatted.
 127
 128       ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY
 129         1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 130         SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
 131
 132    The intent behind the equality match on vendorVersion is to not allow
 133    a less than or greater than type of query.  Say release "LDAPv3 8.0"
 134    has a problem that is fixed in the next release "LDAPv3 8.5", but in
 135    the mean time there is also an update release say version "LDAPv3
 136    8.01" that fixes the problem.  This will hopefully stop the client
 137    from saying it will not work with a version less than "LDAPv3 8.5"
 138    when it would also work with "LDAPv3 8.01".  With the equality match
 139    the client would have to exactly match what it is looking for.
 140
 141 3. Notes to Server Implementers
 142
 143    Server implementers may consider tying the vendorVersion attribute
 144    value to the build mechanism so that it is automatically updated when
 145    the version value changes.
 146
 147 4. Notes to Client Developers
 148
 149    As mentioned in section 2.1, the use of vendorName and vendorVersion
 150    MUST NOT be used to discover features.
 151
 152    It should be noted that an anomalies often on affect subset of
 153    implementations reporting the same version information.  Most
 154    implementations support multiple platforms, have numerous
 155    configuration options, and often support plug-ins.
 156
 157    Client implementations SHOULD be written in such a way as to accept
 158    any value in the vendorName and vendorVersion attributes.  If a
 159    client implementation does not recognize the specific vendorName or
 160    vendorVersion as one it recognizes, then for the purposes of 'working
 161    around' anomalies, the client MUST assume that the server is complete
 162    and correct.  The client MUST work with implementations that do not
 163    publish these attributes.
 164
 165
 166
 167
 168
 169
 170 Meredith                     Informational                      [Page 3]
 171 \f
 172 RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
 173
 174
 175 5. Security Considerations
 176
 177    The vendorName and vendorVersion attributes are provided only as
 178    display or informational mechanisms, or as anomaly identifying
 179    mechanisms.  Client and application implementers must consider that
 180    the existence of a given value in the vendorName or vendorVersion
 181    attribute is no guarantee that the server was actually built by the
 182    asserted vendor or that its version is the asserted version and
 183    should act accordingly.
 184
 185    Server implementers should be aware that this information could be
 186    used to exploit a security hole a server provides either by feature
 187    or flaw.
 188
 189 6. IANA Considerations
 190
 191    This document seeks to create two attributes, vendorName and
 192    vendorVersion, which the IANA will primarily be responsible.  This is
 193    a one time effort; there is no need for any recurring assignment
 194    after this stage.
 195
 196 7. References
 197
 198    [RFC2219]  Bradner, S., "Key words for use in RFCs to Indicate
 199               Requirement Levels", BCP 14, RFC 2119, March 1997.
 200
 201    [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
 202               3", BCP 9, RFC 2026, October 1996.
 203
 204    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
 205               Access Protocol (v3)", RFC 2251, December 1997.
 206
 207    [RFC2252]  Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
 208               "Lightweight Directory Access Protocol (v3): Attribute
 209               Syntax Definitions", RFC 2252, December 1997.
 210
 211 8. Acknowledgments
 212
 213    The author would like to thank the generous input and review by
 214    individuals at Novell including but not limited to Jim Sermersheim,
 215    Mark Hinckley, Renea Campbell, and Roger Harrison.  Also IETF
 216    contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong,
 217    Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers.
 218
 219
 220
 221
 222
 223
 224
 225
 226 Meredith                     Informational                      [Page 4]
 227 \f
 228 RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
 229
 230
 231 9. Author's Address
 232
 233    Mark Meredith
 234    Novell Inc.
 235    1800 S. Novell Place
 236    Provo, UT 84606
 237
 238    Phone: 801-861-2645
 239    EMail: mark_meredith@novell.com
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 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 Meredith                     Informational                      [Page 5]
 283 \f
 284 RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
 285
 286
 287 10. Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (2001).  All Rights Reserved.
 290
 291    This document and translations of it may be copied and furnished to
 292    others, and derivative works that comment on or otherwise explain it
 293    or assist in its implementation may be prepared, copied, published
 294    and distributed, in whole or in part, without restriction of any
 295    kind, provided that the above copyright notice and this paragraph are
 296    included on all such copies and derivative works.  However, this
 297    document itself may not be modified in any way, such as by removing
 298    the copyright notice or references to the Internet Society or other
 299    Internet organizations, except as needed for the purpose of
 300    developing Internet standards in which case the procedures for
 301    copyrights defined in the Internet Standards process must be
 302    followed, or as required to translate it into languages other than
 303    English.
 304
 305    The limited permissions granted above are perpetual and will not be
 306    revoked by the Internet Society or its successors or assigns.
 307
 308    This document and the information contained herein is provided on an
 309    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 310    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 311    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 312    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 313    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 314
 315 Acknowledgement
 316
 317    Funding for the RFC Editor function is currently provided by the
 318    Internet Society.
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Meredith                     Informational                      [Page 6]
 339 \f