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

[Peter Strong <pestrong@nortelnetworks.com>]

Mark,

>
> But it is a slippery slope to provide a vendor name and version.  The
> danger is that people will start to rely on that rather than encouraging
> development of appropriate standards.

I'm all for standards. However, I am also a realist. Standards tend to arise
from vendors adding new features to a product and then lobbying to get their
approach recognized as a standard. 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. If the feature
eventually becomes a standard, it will take time to be implemented by other
vendors. During the catch up period, differences will exist between the
various vendor products.

I do like Kurt's suggestion:

> I'm thinking we just need to define an operational attribute for the
> root DSE:
>
> supportedFeature
>
>    The values of this attribute are OBJECT IDENTIFIERs identifying the
>    supported optional or vendor-defined features which the server
supports.
>
>     ( supportedFeatureOID NAME 'supportedFeature'
>      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
>
> The key is that it lists features directly and eliminates the
> need to maintain out of band feature lists for each vendor version.

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! And, it's one that I, as a designer of products that use different
directories need to be able to anticipate and work around. The easiest way
to do this is to know, up front, what flavour of directory I'm talking to.

> I don't know how to reconcile the short term need for clients to identify
> what server they are talking to with the long term need to rely on
standard
> compliance to achieve interoperability.

That's just it, I don't believe that this is a short term need. As I
indicated previously, there will always be differences between directory
implementations from different vendors, even if they do all implement the
same
"standards".

> The two examples you cite above are interesting. LDAPv3 includes a
standard
> for schema updates (although I know some implementations -- including ours
> -- have quirks in this area that we are working to fix).

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

> For change notification, all the mechanisms I know of rely on an LDAPv3
> control which you can test support for by reading a server's rootDSE
> supportedControl attribute.

On this point, I conceed, we should just look at the supportedControls
attribute. Again, however, it comes down to the quirks. If there are subtle
differences between the ways that the "standard" is implemented, clients
still need to be able to distinguish.


The other thing to consider - beyond just the implementation of standard
features - is alterations in behaviour between one product release and
another. Having the vendor name and version is just simple/useful
information to have. It may be difficult (read impossible) to characterize
all aspects of a product's behaviour via mechanisms such as a
supportedFeatures list.

Regards,

  Peter

------------------------------------------------------------------------
Peter Strong
Software Architect
Nortel Networks - Optivity Policy Services (OPS) and NetID
pestrong@nortelnetworks.com
(613) 831-6615