As per Relevance of the word implementation, we have this rfc below:
Network Working Group M.
Request for Comments: 3045 Novell Inc
Category: Informational January 2001
Storing Vendor Information in the LDAP root
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document specifies two Lightweight Directory Access
(LDAP) attributes, vendorName and vendorVersion that MAY be
in the root DSA-specific Entry (DSE) to advertise vendor-
information. These two attributes supplement the attributes
in section 3.4 of RFC 2251.
The information held in these attributes MAY be used for display
informational purposes and MUST NOT be used for feature
or discovery
Conventions used in this
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2219]
1.
LDAP clients discover server-specific data--such as
controls, extensions, etc.--by reading the root DSE. See section 3.4
of [RFC2251] for details
For display, information, and limited function discovery, it
desirable to be able to query an LDAP server to determine the
name of that server and also to see what version of that vendor'
code is currently installed
Meredith Informational [Page 1]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
1.1 Function
There are many ways in which a particular version of a vendor's
server implementation may be functionally incomplete, or may
software anomalies. It is impossible to identify every
shortcoming of an LDAP server with the given set of server
advertisement attributes. Furthermore, often times, the anomalies
an implementation are not found until after the implementation
been distributed, deployed, and is in use
The attributes defined in this document MAY be used by
implementations in order to identify a particular
implementation so that it can 'work around' such anomalies
The attributes defined in this document MUST NOT be used to
information related to supported features of an LDAP implementation
All LDAP features, mechanisms, and capabilities--if advertised--
be advertised through other mechanisms, preferably
mechanisms defined in concert with said features, mechanisms,
capabilities
2. Attribute
These attributes are an addition to the Server-specific
Requirements defined in section 3.4 of [RFC2251]. The
syntaxes are defined in section 4 of [RFC2252].
Servers MAY restrict access to vendorName or vendorVersion
clients MUST NOT expect these attributes to be available
2.1
This attribute contains a single string, which represents the name
the LDAP server implementer
All LDAP server implementations SHOULD maintain a vendorName,
is generally the name of the company that wrote the LDAP Server
like "Novell, Inc."
( 1.3.6.1.1.4 NAME 'vendorName'
1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
2.2
This attribute contains a string which represents the version of
LDAP server implementation
Meredith Informational [Page 2]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
All LDAP server implementations SHOULD maintain a vendorVersion
Note that this value is typically a release value--comprised of
string and/or a string of numbers--used by the developer of the
server product (as opposed to the supportedLDAPVersion,
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
other syntactic restrictions on the value or the way it is formatted
( 1.3.6.1.1.5 NAME 'vendorVersion'
1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
The intent behind the equality match on vendorVersion is to not
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
the mean time there is also an update release say version "LDAPv
8.01" that fixes the problem. This will hopefully stop the
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
the client would have to exactly match what it is looking for
3. Notes to Server
Server implementers may consider tying the vendorVersion
value to the build mechanism so that it is automatically updated
the version value changes
4. Notes to Client
As mentioned in section 2.1, the use of vendorName and
MUST NOT be used to discover features
It should be noted that an anomalies often on affect subset
implementations reporting the same version information.
implementations support multiple platforms, have
configuration options, and often support plug-ins
Client implementations SHOULD be written in such a way as to
any value in the vendorName and vendorVersion attributes. If
client implementation does not recognize the specific vendorName
vendorVersion as one it recognizes, then for the purposes of '
around' anomalies, the client MUST assume that the server is
and correct. The client MUST work with implementations that do
publish these attributes
Meredith Informational [Page 3]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
5. Security
The vendorName and vendorVersion attributes are provided only
display or informational mechanisms, or as anomaly
mechanisms. Client and application implementers must consider
the existence of a given value in the vendorName or
attribute is no guarantee that the server was actually built by
asserted vendor or that its version is the asserted version
should act accordingly
Server implementers should be aware that this information could
used to exploit a security hole a server provides either by
or flaw
6. IANA
This document seeks to create two attributes, vendorName
vendorVersion, which the IANA will primarily be responsible. This
a one time effort; there is no need for any recurring
after this stage
7.
[RFC2219] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille
"Lightweight Directory Access Protocol (v3):
Syntax Definitions", RFC 2252, December 1997.
8.
The author would like to thank the generous input and review
individuals at Novell including but not limited to Jim Sermersheim
Mark Hinckley, Renea Campbell, and Roger Harrison. Also
contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong
Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers
Meredith Informational [Page 4]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
9. Author's
Mark
Novell Inc
1800 S. Novell
Provo, UT 84606
Phone: 801-861-2645
EMail: mark_meredith@novell.
Meredith Informational [Page 5]
RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
10. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Meredith Informational [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
