#$@%#$%!

Ngiler SH3LL 360
: / opt / alt / openldap11 / share / doc / alt-openldap11-devel / rfc /

Information Server
MySQL : OFF Perl : OFF CURL : ON WGET : OFF PKEXEC : OFF

Directive	Local Value
IP Address	162.0.209.101
System	Linux premium169.web-hosting.com 4.18.0-553.50.1.lve.el8.x86_64 #1 SMP Thu Apr 17 19:10:24 UTC 2025 x86_64
User	luxeelil
PHP Version	8.0.30
Software	LiteSpeed
Doc root	Writable

Edit File : rfc3045.txt \| Size : 10.27 KB
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. Abstract This 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] 1. Overview LDAP clients discover server-specific data--such as available controls, extensions, etc.--by reading the root DSE. See 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. Meredith Informational [Page 1] RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 1.1 Function discovery There are many ways in which a particular version of a vendor's LDAP server implementation may be functionally incomplete, or may contain 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. 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. 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 capabilities--if advertised--MUST be advertised through other mechanisms, preferably advertisement mechanisms defined in concert with said features, mechanisms, and capabilities. 2. Attribute Types These attributes are an addition to the Server-specific Data Requirements defined in 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. 2.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." ( 1.3.6.1.1.4 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 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 2.2 vendorVersion This attribute contains a string which represents the version of the 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 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. ( 1.3.6.1.1.5 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 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. 3. 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. 4. Notes to Client Developers As mentioned in 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. Meredith Informational [Page 3] RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 5. Security Considerations The vendorName and vendorVersion attributes are provided only as display or informational mechanisms, or as anomaly identifying mechanisms. Client and application implementers 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. Server implementers should be aware that this information could be used to exploit a security hole a server provides either by feature or flaw. 6. IANA Considerations This document seeks to create two attributes, vendorName and vendorVersion, which the IANA will primarily be responsible. This is a one time effort; there is no need for any recurring assignment after this stage. 7. References [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. 8. 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. Meredith Informational [Page 4] RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 9. Author's Address Mark Meredith Novell Inc. 1800 S. Novell Place Provo, UT 84606 Phone: 801-861-2645 EMail: mark_meredith@novell.com Meredith Informational [Page 5] RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 10. Full Copyright Statement Copyright (C) The Internet Society (2001). 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Meredith Informational [Page 6] Back

Edit File : rfc3045.txt | Size : 10.27 KB

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.

Abstract

This 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]

1. Overview

LDAP clients discover server-specific data--such as available
   controls, extensions, etc.--by reading the root DSE.  See 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.

Meredith                     Informational                      [Page 1]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

1.1 Function discovery

There are many ways in which a particular version of a vendor's LDAP
   server implementation may be functionally incomplete, or may contain
   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.

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.

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 capabilities--if advertised--MUST
   be advertised through other mechanisms, preferably advertisement
   mechanisms defined in concert with said features, mechanisms, and
   capabilities.

2. Attribute Types

These attributes are an addition to the Server-specific Data
   Requirements defined in 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.

2.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."

( 1.3.6.1.1.4 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
        SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )

2.2 vendorVersion

This attribute contains a string which represents the version of the
   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 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.

( 1.3.6.1.1.5 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
        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.

3. 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.

4. Notes to Client Developers

As mentioned in 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.

Meredith                     Informational                      [Page 3]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

5. Security Considerations

The vendorName and vendorVersion attributes are provided only as
   display or informational mechanisms, or as anomaly identifying
   mechanisms.  Client and application implementers 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.

Server implementers should be aware that this information could be
   used to exploit a security hole a server provides either by feature
   or flaw.

6. IANA Considerations

This document seeks to create two attributes, vendorName and
   vendorVersion, which the IANA will primarily be responsible.  This is
   a one time effort; there is no need for any recurring assignment
   after this stage.

7. References

[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.

8. 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.

Meredith                     Informational                      [Page 4]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

9. Author's Address

Mark Meredith
   Novell Inc.
   1800 S. Novell Place
   Provo, UT 84606

Phone: 801-861-2645
   EMail: mark_meredith@novell.com

Meredith                     Informational                      [Page 5]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

10. Full Copyright Statement

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
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
   Internet Society.

Meredith                     Informational                      [Page 6]

Back