[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
please publish draft-mmeredith-rootdse-vendor-info-01.txt
Please publish - this reflects the changes requested via feed back on draft-00.
Please review this draft and submit comments.
-Mark
Mark Meredith
Novell Inc
122 E. 1700 S. Provo UT 84606
mark_meredith@novell.com
801-861-2645
---------------------
A boat in the harbor is safe,
but that is not what boats are for.
--John A. Shed
---------------------
Individual Submission to the LDAPExt Working Group Mark Meredith
Internet Draft Novell Inc.
Document: draft-mmeredith-rootdse-vendor-info-01.txt February 7, 2000
Category: Proposed Standard
Storing Vendor Information in the 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. Abstraction
This document specifies two new attributes, vendorName and
vendorVersion that can be included in the root DSE to contain
vendor-specific information.
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 clients to find out what
controls, extensions, etc. is available from a given LDAP server. It
is useful to be able to query an LDAP server to determine the vendor
of that server and see what version of that vendor?s code is
currently installed. Since vendors can implement X- options for
attributes, classes, and syntaxes (described in section 4 of
[RFC2251] and section 4 of [RFC2252] ) that may or may not be
published, this would allow users or applications to be able to
determine if these features are available from a given server.
It is also possible for vendors to have an LDAP server
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 until they can be
fixed in the subsequent release. The vendorName and vendorVersion
allow client developers to identify a specific implementation of
LDAP and work around any shortcomings of that implementation as
needed.
4. Vendor specific information
This is an addition to the Server-specific Data Requirements defined
in section 3.4 of [RFC-2251] and the associated syntaxes defined in
section 4 of [RFC-2252].
- vendorName
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' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION SINGLE-VALUE
USAGE dSAOperation )
- vendorVersion
All LDAP server implementations SHOULD maintain a vendorVersion,
which is the release number 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 number.
( 2.16.840.1.113719.1.27.4.44 NAME 'vendorVersion' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION SINGLE-VALUE
USAGE dSAOperation )
5. Notes to Implementers
Implementers may want to consider tying the vendorVersion
attribute value to the build mechanism so that it is automatically
updated when the version number changes.
6. Notes to Client Developers
The use of vendorName and vendorVersion SHOULD NOT be used to
discover features. It is just an informational attribute. If a
client relies on a vendorVersion number then that client MUST
be coded to work with later versions and not just one version and
no other.
7. Security Considerations
The vendorName and vendorVersion attributes are provided only as an
aid to help client implementers assess what features may or may not
exist in a given server implementation. Server and application
implementers should realize 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 information February 2000
8. References
RFC-2219
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
RFC-2026
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.
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 August-2000 3