At 12:36 AM 11/20/2006, michael@stroeder.com wrote:

Kurt D. Zeilenga wrote:

...

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

...

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

Yes, that's what I'm after.

This purpose is, I think, somewhat beyond the intended purpose of the vendorName/Version attributes. These attributes appear to be intended to be used by general LDAP clients, not just administrative clients, for "limited feature discovery".

The vendorName/Version you might want reported for "limited feature discovery" might be quite different than what you want reported for "need to upgrade" purposes.

And for "need to upgrade" purposes, one needs to know not only the version of the protocol engine (slapd(8)), but version of backend codes, overlay codes, underlying libraries, etc..

...

We provide cn=monitor for this purpose.

This is proprietary. Think of vendor-independent management/monitoring software which just gives an terse overview.

Generally speaking, DSA administrative interfaces are not standardized. (Which is, to some degree, why I think use of vendorName/Version for administrative purposes is beyond the intentions of these attributes.)

...

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.

The server admin can easily define access control for vendor information in root DSE. The sample slapd.conf could endorse this. Or another value for configuration directive 'allow'.

Yes, but...

Kurt