Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt

[Mark Wahl <M.Wahl@INNOSOFT.COM>]

> Sometimes this works, and sometimes it doesn't. If a vendor introduces an 
> incredible new feature that I want to take advantage of, but the feature 
> gets held up in the standards process or not standardized at all, I don't 
> want to be hamstrung.

A control, extension, attribute type or object class does not need to be 
standardized to have an OID assigned to it.  

> But, it has a flaw - and that has to do with the "quirks" you mention below.
> Although the Netscape/Novell/ActiveDirectory products support the "standard"
> subschema definition mechanism, they all have their own quirks as to the
> contents of the attribute/class definitions. This is a gigantic pain in the
> ass!

By quirks, do you mean bugs?  Or something else?


> ...and the quirks we shall always have with us! If not in your product, then
> in someone elses.

I am not sure how clients can use vendor version information, since the checks
on this information is presumably hard coded in the client binary.  When the
client binary is run in a different environment, it frequently would encounter
a different set of servers, perhaps those which it has never communicated 
with before.  However if these servers have the same functionality, the 
deployer would expect them to work together.  Furthermore if server X is 
bug-for-bug compatible with servers Y and Z, then X would need to advertise
three different vendors, even if it was not related to two of them.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.