1
2
3
4
5
6
7Network Working Group                                        M. Meredith
8Request for Comments: 3045                                   Novell Inc.
9Category: Informational                                     January 2001
10
11
12            Storing Vendor Information in the LDAP root DSE
13
14Status of this Memo
15
16   This memo provides information for the Internet community.  It does
17   not specify an Internet standard of any kind.  Distribution of this
18   memo is unlimited.
19
20Copyright Notice
21
22   Copyright (C) The Internet Society (2001).  All Rights Reserved.
23
24Abstract
25
26   This document specifies two Lightweight Directory Access Protocol
27   (LDAP) attributes, vendorName and vendorVersion that MAY be included
28   in the root DSA-specific Entry (DSE) to advertise vendor-specific
29   information.  These two attributes supplement the attributes defined
30   in section 3.4 of RFC 2251.
31
32   The information held in these attributes MAY be used for display and
33   informational purposes and MUST NOT be used for feature advertisement
34   or discovery.
35
36Conventions used in this document
37
38   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
39   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
40   document are to be interpreted as described in [RFC2219]
41
421. Overview
43
44   LDAP clients discover server-specific data--such as available
45   controls, extensions, etc.--by reading the root DSE.  See section 3.4
46   of [RFC2251] for details.
47
48   For display, information, and limited function discovery, it is
49   desirable to be able to query an LDAP server to determine the vendor
50   name of that server and also to see what version of that vendor's
51   code is currently installed.
52
53
54
55
56
57
58Meredith                     Informational                      [Page 1]
59
60RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
61
62
631.1 Function discovery
64
65   There are many ways in which a particular version of a vendor's LDAP
66   server implementation may be functionally incomplete, or may contain
67   software anomalies.  It is impossible to identify every known
68   shortcoming of an LDAP server with the given set of server data
69   advertisement attributes.  Furthermore, often times, the anomalies of
70   an implementation are not found until after the implementation has
71   been distributed, deployed, and is in use.
72
73   The attributes defined in this document MAY be used by client
74   implementations in order to identify a particular server
75   implementation so that it can 'work around' such anomalies.
76
77   The attributes defined in this document MUST NOT be used to gather
78   information related to supported features of an LDAP implementation.
79   All LDAP features, mechanisms, and capabilities--if advertised--MUST
80   be advertised through other mechanisms, preferably advertisement
81   mechanisms defined in concert with said features, mechanisms, and
82   capabilities.
83
842. Attribute Types
85
86   These attributes are an addition to the Server-specific Data
87   Requirements defined in section 3.4 of [RFC2251].  The associated
88   syntaxes are defined in section 4 of [RFC2252].
89
90   Servers MAY restrict access to vendorName or vendorVersion and
91   clients MUST NOT expect these attributes to be available.
92
932.1 vendorName
94
95   This attribute contains a single string, which represents the name of
96   the LDAP server implementer.
97
98   All LDAP server implementations SHOULD maintain a vendorName, which
99   is generally the name of the company that wrote the LDAP Server code
100   like "Novell, Inc."
101
102      ( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY
103        1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
104        SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
105
1062.2 vendorVersion
107
108   This attribute contains a string which represents the version of the
109   LDAP server implementation.
110
111
112
113
114Meredith                     Informational                      [Page 2]
115
116RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
117
118
119   All LDAP server implementations SHOULD maintain a vendorVersion.
120   Note that this value is typically a release value--comprised of a
121   string and/or a string of numbers--used by the developer of the LDAP
122   server product (as opposed to the supportedLDAPVersion, which
123   specifies the version of the LDAP protocol supported by this server).
124   This is single-valued so that it will only have one version value.
125   This string MUST be unique between two versions, but there are no
126   other syntactic restrictions on the value or the way it is formatted.
127
128      ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY
129        1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
130        SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
131
132   The intent behind the equality match on vendorVersion is to not allow
133   a less than or greater than type of query.  Say release "LDAPv3 8.0"
134   has a problem that is fixed in the next release "LDAPv3 8.5", but in
135   the mean time there is also an update release say version "LDAPv3
136   8.01" that fixes the problem.  This will hopefully stop the client
137   from saying it will not work with a version less than "LDAPv3 8.5"
138   when it would also work with "LDAPv3 8.01".  With the equality match
139   the client would have to exactly match what it is looking for.
140
1413. Notes to Server Implementers
142
143   Server implementers may consider tying the vendorVersion attribute
144   value to the build mechanism so that it is automatically updated when
145   the version value changes.
146
1474. Notes to Client Developers
148
149   As mentioned in section 2.1, the use of vendorName and vendorVersion
150   MUST NOT be used to discover features.
151
152   It should be noted that an anomalies often on affect subset of
153   implementations reporting the same version information.  Most
154   implementations support multiple platforms, have numerous
155   configuration options, and often support plug-ins.
156
157   Client implementations SHOULD be written in such a way as to accept
158   any value in the vendorName and vendorVersion attributes.  If a
159   client implementation does not recognize the specific vendorName or
160   vendorVersion as one it recognizes, then for the purposes of 'working
161   around' anomalies, the client MUST assume that the server is complete
162   and correct.  The client MUST work with implementations that do not
163   publish these attributes.
164
165
166
167
168
169
170Meredith                     Informational                      [Page 3]
171
172RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
173
174
1755. Security Considerations
176
177   The vendorName and vendorVersion attributes are provided only as
178   display or informational mechanisms, or as anomaly identifying
179   mechanisms.  Client and application implementers must consider that
180   the existence of a given value in the vendorName or vendorVersion
181   attribute is no guarantee that the server was actually built by the
182   asserted vendor or that its version is the asserted version and
183   should act accordingly.
184
185   Server implementers should be aware that this information could be
186   used to exploit a security hole a server provides either by feature
187   or flaw.
188
1896. IANA Considerations
190
191   This document seeks to create two attributes, vendorName and
192   vendorVersion, which the IANA will primarily be responsible.  This is
193   a one time effort; there is no need for any recurring assignment
194   after this stage.
195
1967. References
197
198   [RFC2219]  Bradner, S., "Key words for use in RFCs to Indicate
199              Requirement Levels", BCP 14, RFC 2119, March 1997.
200
201   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
202              3", BCP 9, RFC 2026, October 1996.
203
204   [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
205              Access Protocol (v3)", RFC 2251, December 1997.
206
207   [RFC2252]  Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
208              "Lightweight Directory Access Protocol (v3): Attribute
209              Syntax Definitions", RFC 2252, December 1997.
210
2118. Acknowledgments
212
213   The author would like to thank the generous input and review by
214   individuals at Novell including but not limited to Jim Sermersheim,
215   Mark Hinckley, Renea Campbell, and Roger Harrison.  Also IETF
216   contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong,
217   Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers.
218
219
220
221
222
223
224
225
226Meredith                     Informational                      [Page 4]
227
228RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
229
230
2319. Author's Address
232
233   Mark Meredith
234   Novell Inc.
235   1800 S. Novell Place
236   Provo, UT 84606
237
238   Phone: 801-861-2645
239   EMail: mark_meredith@novell.com
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Meredith                     Informational                      [Page 5]
283
284RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001
285
286
28710. Full Copyright Statement
288
289   Copyright (C) The Internet Society (2001).  All Rights Reserved.
290
291   This document and translations of it may be copied and furnished to
292   others, and derivative works that comment on or otherwise explain it
293   or assist in its implementation may be prepared, copied, published
294   and distributed, in whole or in part, without restriction of any
295   kind, provided that the above copyright notice and this paragraph are
296   included on all such copies and derivative works.  However, this
297   document itself may not be modified in any way, such as by removing
298   the copyright notice or references to the Internet Society or other
299   Internet organizations, except as needed for the purpose of
300   developing Internet standards in which case the procedures for
301   copyrights defined in the Internet Standards process must be
302   followed, or as required to translate it into languages other than
303   English.
304
305   The limited permissions granted above are perpetual and will not be
306   revoked by the Internet Society or its successors or assigns.
307
308   This document and the information contained herein is provided on an
309   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
310   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
311   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
312   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
313   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
314
315Acknowledgement
316
317   Funding for the RFC Editor function is currently provided by the
318   Internet Society.
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338Meredith                     Informational                      [Page 6]
339
340