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

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 16:04:07 -0800

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 3:29 PM
> To: Mark Meredith
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt
> 
> 
> If published at all, I would suggest it be published as
> informational.
> 
> I would rather see us define attribute types to document
> existence on specific features instead of relying on vendor
> naming/version information.  Otherwise, as vendors start implementing
> each others features, we'll end up with same ( xxx compatible )
> crap that has plagued HTTP services.

I agree. If it is to be used to determine if certain features are supported,
that would be bad.

As a result, I'd rather not see it published as informational, either.

Paul

---

From: "Peter Strong" <[email-masked]>
Date: Fri, 19 Nov 1999 09:26:40 -0500

> From: Paul Leach (Exchange) [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 7:04 PM
> To: 'Kurt D. Zeilenga'; Mark Meredith
> Subject: RE: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt
>
>
> I agree. If it is to be used to determine if certain features are
supported, > that would be bad.
> As a result, I'd rather not see it published as informational, either.

As a user of multiple directory products, I think that some manner of
determining the type of directory I'm connected to is crucial! We currently
support Netscape, Novell and (soon) Active Directory as the storage
repository for our product. We need to know which directory we're talking to
because
of the differences that exist in such things as schema update mechanisms and
change notification strategys.

Our architectural approach hides differences in repository implementations
by providing an abstraction of the repository being used and we often have
to connect to multiple data repositories simultaneously. Having a standard
way of determining the vendor of the directory we're talking to would make
it much easier for us to instantiate the correct "flavour" of LDAP
interface.

In an ideal world, all directories would align to standards and client
software wouldn't have to worry about which one they were accessing.

However, this isn't an ideal world, it's the real world.

There will ALWAYS be differences in the way vendors build their products. In
fact, that's usually how new standards come into existence.

We're not looking for an exhaustive indication of the features supported by
the directory, but we could definitely use a basic hint about whose
directory we're talking to!

This is a very simple, very useful proposal that doesn't require a huge
development effort and I support it!

------------------------------------------------------------------------
Peter Strong
Software Architect
Nortel Networks - Optivity Policy Services (OPS) and NetID
[email-masked]
(613) 831-6615

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Nov 1999 09:55:12 -0500

Peter Strong wrote:
> ...
> ...

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 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.  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).  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.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Nov 1999 07:26:37 -0800

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.

Kurt

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Nov 1999 08:31:40 -0800

>I'm thinking we just need to define an operational attribute for the

On second thought, I'd like to remove the 'just' out of the above
statement.

I believe a mechanism to allow vendors to describe arbitrary features
is needed.   However, often vendors ship products only then to release
that they have included unexpected features (ie: bugs).  The only
way to avoid such features is to use some out-of-band knowledge.

Hence, I would support progressing a common mechanism for
describing the vendor name and version IF we also provide a
common mechanism for listing arbitrary vendor features with
a "vendors SHOULD list features" statement.

This allows clients to utilize vendor versioning information
to address any feature to which the vendor as mistakenly
delivered an unlisted feature.

----

---

From: "Peter Strong" <[email-masked]>
Date: Fri, 19 Nov 1999 12:06:10 -0500

Mark,

> 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.

> 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

---

From: Mark Wahl <[email-masked]>
Date: Fri, 19 Nov 1999 11:37:05 -0600

> 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.  

> 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

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.