At 01:37 AM 11/19/2006, michael@stroeder.com wrote:

Full_Name: Michael Ströder Version: not relevant OS: not relevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.27.203)

HI!

I'd like to see support for RFC 3045 in slapd.

The only reasonably decent use of such attributes is for administrators to determine whether they need to upgrade some software or not (though use of a protocol attribute for this purpose is somewhat problematic). We provide cn=monitor for this purpose.

The primary use (or I should say misuse) of such strings is for server behavior discovery (whether the behavior is due to a feature or a bug). As this use leads to interoperability problems (as illustrated by the HTTP "mozilla" compatibility problems), we must allow spoofing and should discourage this use. We support the former via the rootdse configuration option. We support the latter by not providing any values by default.

While it certainly is possible for a client to abuse cn=monitor version information, the very fact that the version information is in cn=monitor, which generally requires special authorization to read, instead of the root dse, which generally is readable by most every client, is effective in discouraging this abuse. I think it reasonable to assume any administrative tool for determining whether an OpenLDAP server is up to date would have appropriate authorization to read the cn=monitor values.

I note that such tools should not assume a server needs not be upgraded simply because the version is high enough. There easily could be dependent software whose version is not high enough. It would be good for cn=monitor to not only expose the OpenLDAP version information, but to expose version information for dependent software. Of course, as there is an endless number of dependent software, this upgrade detection approach problematic. Seems it would be better to use tools that ran directly on the box to determine whether a server's software needed to be upgraded. But I digresss.

In the past we have rejected submissions to extend slapd(8) to generate these values, hence I think this feature request should be closed.

However, such closure certainly doesn't preclude someone from implementing **additional** vendorName/Version functionality and submitting it for consideration. There is one aspect of our current vendorName/Version support that is lacking is in dealing with multiple broken clients requiring different vendorName/Version strings. An overlay which spoofed these strings on a configurable basis, whether by authorization identity and/or IP address and/or other authorization factor, would be an interesting functionality addition.

Kurt