Movatterモバイル変換

Network Working Group                                        M. MeredithRequest for Comments: 3045                                   Novell Inc.Category: Informational                                     January 2001Storing Vendor Information in the LDAP root DSEStatus 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   insection 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.  Seesection 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 20011.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 insection 3.4 of [RFC2251].  The associated   syntaxes are defined insection 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 insection 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 20015. 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 20019. Author's Address   Mark Meredith   Novell Inc.   1800 S. Novell Place   Provo, UT 84606   Phone: 801-861-2645   EMail: mark_meredith@novell.comMeredith                     Informational                      [Page 5]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 200110. 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]