Storing Vendor Information in the LDAP root DSE
The information below is for an old version of the document that is already published as an RFC.
This is an older version of an Internet-Draft that was ultimately published as RFC 3045.
|Last updated||2013-03-02 (Latest revision 2000-02-14)|
|RFC stream||Legacy stream|
|RFC Editor Note||(None)|
|IESG||IESG state||RFC 3045 (Informational)|
|Send notices to||(None)|
Individual Submission to the LDAPExt Working Group Mark Meredith Internet Draft Novell Inc. Document: draft-mmeredith-rootdse-vendor-info-02.txt February 11, 2000 Category: Proposed Standard Storing Vendor Information in the LDAP root DSE Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list firstname.lastname@example.org or the author. 1. Abstract This document specifies two LDAP attributes, vendorName and vendorVersion that MAY be included in the root 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. 2. 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 [RFC-2219] 3. Overview LDAP clients discover server-specific data--such as available controls, extensions, etc.-- by reading the root DSE. See section 3.4 of [RFC-2251] for details. M. Meredith Expires June-2000 1 LDAP root DSE to display vendor information December 1999 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. 3.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. 4. Attribute Types These attributes are an addition to the Server-specific Data Requirements defined in section 3.4 of [RFC-2251]. The associated syntaxes are defined in section 4 of [RFC-2252]. Servers MAY restrict access to vendorName or vendorVersion and clients MUST NOT expect these attributes to be available. 4.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." ( 2.16.840.1.113718.104.22.168.43 NAME 'vendorName' EQUALITY 22.214.171.124.4.1.14126.96.36.199 SYNTAX 188.8.131.52.4.1.14184.108.40.206.15 NO-USER-MODIFICATION SINGLE-VALUE USAGE dSAOperation ) 4.2 vendorVersion This attribute contains a string which represents the version of the LDAP server implementation. M. Meredith Expires June-2000 2 LDAP root DSE to display vendor information December 1999 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. ( 2.16.840.1.1137220.127.116.11.44 NAME 'vendorVersion' EQUALITY 18.104.22.168.4.1.1422.214.171.124 SYNTAX 126.96.36.199.4.1.14188.8.131.52.15 NO-USER-MODIFICATION SINGLE-VALUE USAGE dSAOperation ) 5. 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. 6. Notes to Client Developers As mentioned in section 3.1, the use of vendorName and vendorVersion MUST NOT be used to discover features. 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 SHOULD work with implementations that do not publish these attributes. 7. 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. 8. References RFC-2219 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 RFC-2026 M. Meredith Expires June-2000 3 LDAP root DSE to display vendor information December 1999 Bradner, S., "The Internet Standards ProcessùRevision 3", BCP 9, RFC 2026, October 1996. RFC-2251 Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997 RFC-2252 Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997 9. 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. 10. Author's Addresses Mark Meredith Novell Inc. 122 E. 1700 S. Provo, UT 84606 Phone: 801-861-2645 Email: email@example.com Full Copyright Statement Copyright (c) The Internet Society (1999). 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 MER-CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. M. Meredith Expires June-2000 4