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.
AbstractThis 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] 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.
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.
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. ( 188.8.131.52.1.5 NAME 'vendorVersion' EQUALITY 184.108.40.206.4.1.14220.127.116.11 SYNTAX 18.104.22.168.4.1.1422.214.171.124.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. 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.
[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.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.