--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Meredith
+Request for Comments: 3045 Novell Inc.
+Category: Informational January 2001
+
+
+ Storing Vendor Information in the LDAP root DSE
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document specifies two Lightweight Directory Access Protocol
+ (LDAP) attributes, vendorName and vendorVersion that MAY be included
+ in the root DSA-specific Entry (DSE) to advertise vendor-specific
+ information. These two attributes supplement the attributes defined
+ in section 3.4 of RFC 2251.
+
+ The information held in these attributes MAY be used for display and
+ informational purposes and MUST NOT be used for feature advertisement
+ or discovery.
+
+Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2219]
+
+1. Overview
+
+ LDAP clients discover server-specific data--such as available
+ controls, extensions, etc.--by reading the root DSE. See section 3.4
+ of [RFC2251] for details.
+
+ For display, information, and limited function discovery, it is
+ desirable to be able to query an LDAP server to determine the vendor
+ name of that server and also to see what version of that vendor's
+ code is currently installed.
+
+
+
+
+
+
+Meredith Informational [Page 1]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+1.1 Function discovery
+
+ There are many ways in which a particular version of a vendor's LDAP
+ server implementation may be functionally incomplete, or may contain
+ software anomalies. It is impossible to identify every known
+ shortcoming of an LDAP server with the given set of server data
+ advertisement attributes. Furthermore, often times, the anomalies of
+ an implementation are not found until after the implementation has
+ been distributed, deployed, and is in use.
+
+ The attributes defined in this document MAY be used by client
+ implementations in order to identify a particular server
+ implementation so that it can 'work around' such anomalies.
+
+ The attributes defined in this document MUST NOT be used to gather
+ information related to supported features of an LDAP implementation.
+ All LDAP features, mechanisms, and capabilities--if advertised--MUST
+ be advertised through other mechanisms, preferably advertisement
+ mechanisms defined in concert with said features, mechanisms, and
+ capabilities.
+
+2. Attribute Types
+
+ These attributes are an addition to the Server-specific Data
+ Requirements defined in section 3.4 of [RFC2251]. The associated
+ syntaxes are defined in section 4 of [RFC2252].
+
+ Servers MAY restrict access to vendorName or vendorVersion and
+ clients MUST NOT expect these attributes to be available.
+
+2.1 vendorName
+
+ This attribute contains a single string, which represents the name of
+ the LDAP server implementer.
+
+ All LDAP server implementations SHOULD maintain a vendorName, which
+ is generally the name of the company that wrote the LDAP Server code
+ like "Novell, Inc."
+
+ ( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY
+ 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
+
+2.2 vendorVersion
+
+ This attribute contains a string which represents the version of the
+ LDAP server implementation.
+
+
+
+
+Meredith Informational [Page 2]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+ All LDAP server implementations SHOULD maintain a vendorVersion.
+ Note that this value is typically a release value--comprised of a
+ string and/or a string of numbers--used by the developer of the LDAP
+ server product (as opposed to the supportedLDAPVersion, which
+ specifies the version of the LDAP protocol supported by this server).
+ This is single-valued so that it will only have one version value.
+ This string MUST be unique between two versions, but there are no
+ other syntactic restrictions on the value or the way it is formatted.
+
+ ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY
+ 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
+
+ The intent behind the equality match on vendorVersion is to not allow
+ a less than or greater than type of query. Say release "LDAPv3 8.0"
+ has a problem that is fixed in the next release "LDAPv3 8.5", but in
+ the mean time there is also an update release say version "LDAPv3
+ 8.01" that fixes the problem. This will hopefully stop the client
+ from saying it will not work with a version less than "LDAPv3 8.5"
+ when it would also work with "LDAPv3 8.01". With the equality match
+ the client would have to exactly match what it is looking for.
+
+3. Notes to Server Implementers
+
+ Server implementers may consider tying the vendorVersion attribute
+ value to the build mechanism so that it is automatically updated when
+ the version value changes.
+
+4. Notes to Client Developers
+
+ As mentioned in section 2.1, the use of vendorName and vendorVersion
+ MUST NOT be used to discover features.
+
+ It should be noted that an anomalies often on affect subset of
+ implementations reporting the same version information. Most
+ implementations support multiple platforms, have numerous
+ configuration options, and often support plug-ins.
+
+ Client implementations SHOULD be written in such a way as to accept
+ any value in the vendorName and vendorVersion attributes. If a
+ client implementation does not recognize the specific vendorName or
+ vendorVersion as one it recognizes, then for the purposes of 'working
+ around' anomalies, the client MUST assume that the server is complete
+ and correct. The client MUST work with implementations that do not
+ publish these attributes.
+
+
+
+
+
+
+Meredith Informational [Page 3]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+5. Security Considerations
+
+ The vendorName and vendorVersion attributes are provided only as
+ display or informational mechanisms, or as anomaly identifying
+ mechanisms. Client and application implementers must consider that
+ the existence of a given value in the vendorName or vendorVersion
+ attribute is no guarantee that the server was actually built by the
+ asserted vendor or that its version is the asserted version and
+ should act accordingly.
+
+ Server implementers should be aware that this information could be
+ used to exploit a security hole a server provides either by feature
+ or flaw.
+
+6. IANA Considerations
+
+ This document seeks to create two attributes, vendorName and
+ vendorVersion, which the IANA will primarily be responsible. This is
+ a one time effort; there is no need for any recurring assignment
+ after this stage.
+
+7. References
+
+ [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+8. Acknowledgments
+
+ The author would like to thank the generous input and review by
+ individuals at Novell including but not limited to Jim Sermersheim,
+ Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF
+ contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong,
+ Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers.
+
+
+
+
+
+
+
+
+Meredith Informational [Page 4]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+9. Author's Address
+
+ Mark Meredith
+ Novell Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+
+ Phone: 801-861-2645
+ EMail: mark_meredith@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meredith Informational [Page 5]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meredith Informational [Page 6]
+\f
projects / openldap / commitdiff