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

From: "Mark Meredith" <[email-masked]>
Date: Thu, 18 Nov 1999 11:16:32 -0700

Sorry for the duplicate mailings, my email would not send it correctly.

Please review the attached draft on vendor information to be added to the root DSE.

This document specifies two new attributes, vendorName and vendorVersion, that can be included in the root DSE to contain vendor-specific information.

Any comments can be sent through [email-masked] or directly to me [email-masked]

---

From: "Mark Meredith" <[email-masked]>
Date: Thu, 18 Nov 1999 15:39:38 PST

I don't think the other messages had the attachment.

Please review the attached draft on vendor information to be added to the 
root DSE.

This document specifies two new attributes, vendorName and vendorVersion, 
that can be included in the root DSE to contain vendor-specific information.

Any comments can be sent through [email-masked] or directly to me 
[email-masked]

Mark Meredith
Novell Inc
122 E. 1700 S. Provo UT 84606
[email-masked]
801-861-2645
---------------------
A boat in the harbor is safe,
but that is not what boats are for.
--John A. Shed
---------------------

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: Mark Wahl <[email-masked]>
Date: Fri, 19 Nov 1999 10:50:21 -0600

If there is a capability X which is optional (not mandatory to implement) in 
RFC 2251-2256, is not advertised through existing root DSE or subentry
mechanisms, is implemented by some servers but not others, and its absence 
causes a client request to be rejected or incorrectly performed by some 
servers but not others, then I will want to add a way of advertising the 
presence/absence of X in the root DSE, a subentry or other suitable place.
I will want to do so in a way that allows for a client from implementor Y and
a server from implementor Z to interoperate even if Y and Z are unaware of 
each other.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "Mark Meredith" <[email-masked]>
Date: Fri, 19 Nov 1999 13:36:26 -0700

I can see what you are saying about having the version numbers hard coded in the client library, but I was thinking more along the line that version 1.0 did not have a certain feature (or bug) that version 1.5 has, if I want to make use of that feature (say it is not a bug) then on versions greater than 1.5 I know I can do it one way, and on versions lower than 1.5 I need to do it another way.

I waned the version and name to be single valued, so that the vendor X would not decide since they are bug compatible with vendor Y they can advertise both......

I also liked Paul's idea to be able to use the version information to look up bug reports from the vendor web site, he also talked about having a vendorWebSite that would hold an http address.

Kurt's idea about supported feature is also good, but I thought something like that was being proposed by Mark Wahl in the rewrite of 2251 or 2252?

-Mark

>>> Mark Wahl <[email-masked]> 11/19/99 10:37AM >>>

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

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 19 Nov 1999 12:52:21 -0800

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 8:32 AM
> To: [email-masked]
> Cc: Mark Smith; Peter Strong; Paul Leach (Exchange); Mark Meredith;
> ietf-ldapext
> Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt
> 
> 
> At 07:26 AM 11/19/99 -0800, Kurt D. Zeilenga wrote:
> >I'm thinking we just need to define an operational attribute for the
> >root DSE:
> 
> 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.

Me, too.

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

Note that "features" can be declared post-facto. And even agreed to without
the server vendors cooperation.

Paul