Storing Vendor Information in the LDAP root DSE
draft-mmeredith-rootdse-vendor-info-02

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 ietf-ldapext@netscape.com 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.113719.1.27.4.43 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
     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.113719.1.27.4.44 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
     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: mark_meredith@novell.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