wdiff draft-mmeredith-rootdse-vendor-info-01.txt draft-mmeredith-rootdse-vendor-info-02.txt

Individual Submission to the LDAPExt Working Group Mark Meredith
Internet Draft Novell Inc.
Document: draft-mmeredith-rootdse-vendor-info-01.txt draft-mmeredith-rootdse-vendor-info-02.txt February 7, 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 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. Abstraction Abstract

This document specifies two new LDAP attributes, vendorName and
vendorVersion that can MAY be included in the root DSE to contain 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

The root DSE query is a mechanism used by

LDAP clients to find out what discover server-specific data--such as available
controls, extensions, etc. is available from a given etc.-- by reading the root DSE. See section
3.4 of [RFC-2251] for details.

M. Meredith Expires June-2000 1
LDAP server. It root DSE to display vendor information December 1999

For display, information, and limited function discovery, it is useful
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 vendor's
code is currently installed. Since vendors can implement X- options for
attributes, classes, and syntaxes (described

3.1 Function discovery

There are many ways in section 4 of
[RFC2251] and section 4 which a particular version of [RFC2252] ) that may or a vendor's LDAP
server implementation may not be
published, this would allow users functionally incomplete, or applications to be able to
determine if these features are available from a given server. may contain
software anomalies. It is also possible for vendors impossible to have 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 to be incomplete in some respect or to have

M. Meredith Expires August-2000 1
LDAP root DSE to display vendor information February 2000

implementation quirks that must be worked around are not found until they can be
fixed in after the subsequent release. The vendorName implementation has
been distributed, deployed, and vendorVersion
allow is in use.

The attributes defined in this document MAY be used by client developers
implementations in order to identify a specific 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 work around any shortcomings of that implementation as
needed. capabilities--if advertised--MUST
be advertised through other mechanisms, preferably advertisement
mechanisms defined in concert with said features, mechanisms, and
capabilities.

4. Vendor specific information

This is Attribute Types

These attributes are an addition to the Server-specific Data
Requirements defined in section 3.4 of [RFC-2251] and the [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." This is single-valued so that it
will only have one vendor.

( 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,
which vendorVersion.
Note that this value is the typically a release number value--comprised of a
string and/or a string of numbers--used by the developer of the LDAP
server product, product (as opposed to the supportedLDAPVersion, which
specifies the version of the LDAP protocol supported by this
server). This is single-
valued single-valued so that it will only have one version number.
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

Implementers

Server implementers may want to consider tying the vendorVersion attribute
value to the build mechanism so that it is automatically updated
when the version number value changes.

6. Notes to Client Developers

The

As mentioned in section 3.1, the use of vendorName and vendorVersion SHOULD
MUST NOT be used to discover features. It is just an informational attribute.

Client implementations SHOULD be written in such a way as to accept
any value in the vendorName and vendorVersion attributes. If a
client relies on a implementation does not recognize the specific vendorName or
vendorVersion number as one it recognizes, then that for the purposes of
'working around' anomalies, the client MUST
be coded to assume that the server
is complete and correct. The client SHOULD work with later versions and implementations
that do not just one version and
no other. publish these attributes.

7. Security Considerations

The vendorName and vendorVersion attributes are provided only as an
aid to help client implementers assess what features may
display or may not
exist in a given server implementation. Server informational mechanisms, or as anomaly identifying
mechanisms. Client and application implementers should realize 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.

M. Meredith Expires August-2000 2
LDAP root DSE to display vendor

Server implementers should be aware that this information February 2000 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 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 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 August-2000 3 June-2000 4