< draft-mmeredith-rootdse-vendor-info-01.txt   draft-mmeredith-rootdse-vendor-info-02.txt >
Individual Submission to the LDAPExt Working Group Mark Meredith Individual Submission to the LDAPExt Working Group Mark Meredith
Internet Draft Novell Inc. Internet Draft Novell Inc.
Document: draft-mmeredith-rootdse-vendor-info-01.txt February 7, 2000 Document: draft-mmeredith-rootdse-vendor-info-02.txt February 11, 2000
Category: Proposed Standard Category: Proposed Standard
Storing Vendor Information in the root DSE Storing Vendor Information in the LDAP root DSE
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or made obsolete by other six months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet-Drafts as
as reference material or to cite them other than as "work in reference material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Comments and suggestions on this document are encouraged. Comments and suggestions on this document are encouraged.
Comments on this document should be sent to the LDAPEXT working Comments on this document should be sent to the LDAPEXT working
group discussion list ietf-ldapext@netscape.com or the author. group discussion list ietf-ldapext@netscape.com or the author.
1. Abstraction 1. Abstract
This document specifies two new attributes, vendorName and This document specifies two LDAP attributes, vendorName and
vendorVersion that can be included in the root DSE to contain vendorVersion that MAY be included in the root DSE to advertise
vendor-specific information. 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 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2219] this document are to be interpreted as described in [RFC-2219]
3. Overview 3. Overview
The root DSE query is a mechanism used by clients to find out what LDAP clients discover server-specific data--such as available
controls, extensions, etc. is available from a given LDAP server. It controls, extensions, etc.-- by reading the root DSE. See section
is useful to be able to query an LDAP server to determine the vendor 3.4 of [RFC-2251] for details.
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 M. Meredith Expires June-2000 1
LDAP root DSE to display vendor information February 2000 LDAP root DSE to display vendor information December 1999
implementation quirks that must be worked around until they can be For display, information, and limited function discovery, it is
fixed in the subsequent release. The vendorName and vendorVersion desirable to be able to query an LDAP server to determine the vendor
allow client developers to identify a specific implementation of name of that server and also to see what version of that vendor's
LDAP and work around any shortcomings of that implementation as code is currently installed.
needed.
4. Vendor specific information 3.1 Function discovery
This is an addition to the Server-specific Data Requirements defined There are many ways in which a particular version of a vendor's LDAP
in section 3.4 of [RFC-2251] and the associated syntaxes defined in server implementation may be functionally incomplete, or may contain
section 4 of [RFC-2252]. 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.
- vendorName 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.
All LDAP server implementations SHOULD maintain a vendorName, The attributes defined in this document MUST NOT be used to gather
which is generally the name of the company that wrote the LDAP information related to supported features of an LDAP implementation.
Server code like "Novell, Inc." This is single-valued so that it All LDAP features, mechanisms, and capabilities--if advertised--MUST
will only have one vendor. be advertised through other mechanisms, preferably advertisement
mechanisms defined in concert with said features, mechanisms, and
capabilities.
( 2.16.840.1.113719.1.27.4.43 NAME 'vendorName' SYNTAX 4. Attribute Types
1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION SINGLE-VALUE
USAGE dSAOperation )
- vendorVersion 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].
All LDAP server implementations SHOULD maintain a vendorVersion, Servers MAY restrict access to vendorName or vendorVersion and
which is the release number of the LDAP server product, (as clients MUST NOT expect these attributes to be available.
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 4.1 vendorName
1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION SINGLE-VALUE
USAGE dSAOperation )
5. Notes to Implementers This attribute contains a single string, which represents the name
of the LDAP server implementer.
Implementers may want to consider tying the vendorVersion All LDAP server implementations SHOULD maintain a vendorName, which
attribute value to the build mechanism so that it is automatically is generally the name of the company that wrote the LDAP Server code
updated when the version number changes. 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 6. Notes to Client Developers
The use of vendorName and vendorVersion SHOULD NOT be used to As mentioned in section 3.1, the use of vendorName and vendorVersion
discover features. It is just an informational attribute. If a MUST NOT be used to discover features.
client relies on a vendorVersion number then that client MUST
be coded to work with later versions and not just one version and Client implementations SHOULD be written in such a way as to accept
no other. 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 7. Security Considerations
The vendorName and vendorVersion attributes are provided only as an The vendorName and vendorVersion attributes are provided only as
aid to help client implementers assess what features may or may not display or informational mechanisms, or as anomaly identifying
exist in a given server implementation. Server and application mechanisms. Client and application implementers must consider that
implementers should realize that the existence of a given value in the existence of a given value in the vendorName or vendorVersion
the vendorName or vendorVersion attribute is no guarantee that the attribute is no guarantee that the server was actually built by the
server was actually built by the asserted vendor or that its version asserted vendor or that its version is the asserted version and
is the asserted version and should act accordingly. should act accordingly.
M. Meredith Expires August-2000 2 Server implementers should be aware that this information could be
LDAP root DSE to display vendor information February 2000 used to exploit a security hole a server provides either by feature
or flaw.
8. References 8. References
RFC-2219 RFC-2219
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate Requirement
Requirement Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
RFC-2026 RFC-2026
Bradner, S., "The Internet Standards Process-Revision 3", BCP
9, RFC 2026, October 1996. 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 RFC-2251
Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997 Protocol (v3)", RFC 2251, December 1997
RFC-2252 RFC-2252
Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions", Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
RFC 2252, December 1997 2252, December 1997
9. Acknowledgments 9. Acknowledgments
The author would like to thank the generous input and review by The author would like to thank the generous input and review by
individuals at Novell including but not limited to Jim Sermersheim, individuals at Novell including but not limited to Jim Sermersheim,
Mark Hinckley, Renea Campbell, and Roger Harrison. 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 10. Author's Addresses
Mark Meredith Mark Meredith
Novell Inc. Novell Inc.
122 E. 1700 S. Provo, UT 84606 122 E. 1700 S. Provo, UT 84606
Phone: 801-861-2645 Phone: 801-861-2645
Email: mark_meredith@novell.com Email: mark_meredith@novell.com
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (1999). All Rights Reserved. This Copyright (c) The Internet Society (1999). All Rights Reserved. This
document and translations of it may be copied and furnished to document and translations of it may be copied and furnished to
skipping to change at line 182 skipping to change at line 223
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MER-CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MER-CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
M. Meredith Expires August-2000 3 M. Meredith Expires June-2000 4
 End of changes. 30 change blocks. 
80 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/