Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt

From: "Mark Meredith" <[email-masked]>
Date: Wed, 09 Feb 2000 10:46:56 -0700

I will add your suggestion to section 6  Notes to Client Developers. To read something like this.

6. Notes to Client Developers

     The use of vendorName and vendorVersion SHOULD NOT be used to
     discover features. It is just an informational attribute. If a
     client relies on a vendorVersion number then that client MUST
     be coded to work with later versions and not just one version and
     no other.

     If the client does not recognize the specific vendorName/vendorVersion as 
     one it has for its 'bug workaround needed' table, then the client MUST 
     assume that the server it is talking to is complete and correct. 

Does this look ok?

-Mark

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

>>> Mark Wahl <[email-masked]> 02/09/00 09:45AM >>>

> However, every server implementation has "quirks" (also sometimes known as 
> bugs), which may not be known in advance of shipping the server. 

Correct.  My concern is primarily that the draft is proposing also doing 
feature selection with this.  I don't have a problem in general with using 
version names and numbers for bug detection though, so long as the client 
behavior is specified along the lines of

If the client does not recognize the specific vendor/version as one it has
its 'bug workaround needed' table, then the client must assume that the 
server it is talking to is complete and correct. 

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Feb 2000 15:37:08 -0500

>       assume that the server it is talking to is complete and correct. 

I think this text is an improvement.  But the "Overview" text also
implies that these attributes should be used for discovering some
features:

3. Overview

   The root DSE query is a mechanism used by clients to find out what
   controls, extensions, etc. is available from a given LDAP server. It
   is useful to be able to query an LDAP server to determine the vendor
   of that server and see what version of that vendor's code is
   currently installed. Since vendors can implement X- options for
   attributes, classes, and syntaxes (described in section 4 of
   [RFC2251] and section 4 of [RFC2252] ) that may or may not be
   published, this would allow users or applications to be able to
   determine if these features are available from a given server.

I feel strongly that this document should consistently say that the
vendorName and vendorVersion attribute values must only be used to work
around bugs and shortcomings of a server and for purely informational
(e.g., display) purposes.  If others agree, the overview should be
revised as well.

If there are X- options that are adding real value to subschema values,
let's start a discussion about them (and a document if appropriate).  I
suspect there are, given that several vendors (including
iPlanet/Sun/netscape) are using various X- options today in their
products.

Also, the format for vendorVersion should be more fully specified.  It
is specified as an integer.  But what if I need to publish version
4.11?  I suggest making the value "version multiplied times 100" or
using a string format.

I also wonder if there should be a vendorProductName attribute as well,
given that some vendors produce more than one product that processes
LDAP requests.  I suppose the vendorName field can be overloaded for
that purpose, e.g.,

    vendorName: OpenLDAP / slapd
    vendorName: OpenLDAP / ldapd
    ...

but a separate attribute might be better.

A minor formatting comment: the draft includes at least two non-ASCII
characters (one in the "Overview" section and one in the "Author's
Addresses" section).  I think both were intended to be apostrophes (').

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 10 Feb 2000 12:51:06 -0800

At 03:37 PM 2/10/00 -0500, Mark Smith wrote:
>Also, the format for vendorVersion should be more fully specified.

I disagree.  Since you state that this should be for
display purposes and/or for working around known bugs specific
to this version, the only match that makes sense is EQUALITY.
I suggest the values of this attribute type have syntax DirectoryString
and that an equality rule of CaseExactMatch be provided.  No
ordering or substrings match, IMO, should be provided these
would promote uses beyond that which is intended.  (this doesn't
disallow some vendor from support such via extended search filters)

>LDAP requests.

Or some products might be comprised of software from multiple vendors...
many server implementations support plugin architectures after all.
In many cases, the vendor providing the core implementation is not
the primary vendor providing the end "product".  This is a rat hole.

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Feb 2000 16:39:03 -0500

> disallow some vendor from support such via extended search filters)

But your comment seems to be in conflict with this text from the

>       be coded to work with later versions and not just one version and

I'd be happy to see the last sentence removed.  Clients that rely on
this attribute do so at their own risk and they should code the behavior
that they think is best for them.  This draft can't stipulate that an
older client will work correctly with a newer server which, for example,
includes a bug fix that introduces incompatibilities with older clients.

> the primary vendor providing the end "product".  This is a rat hole.

Good point.  I agree.  So we might as well just stick with one value
(vendorName).

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 10 Feb 2000 15:22:03 -0800

My basic option on this proposal as a whole:

I think implementations that needs such specific vendor/version
information are fundamentally broken.  That is, a client should
be liberal enough to workaround any reasonable non-strict behavior
of the servers (and vice versa).  Clients SHOULD NOT be modified
to support servers who's behavior is not reasonable (and vice
versa).

As such, I can only support such attributes if their use is
is restricted to DISPLAY PURPOSES ONLY.

>But your comment seems to be in conflict with this text from the

That might be true.  My point is that if the intent is to
work around bugs in a specific version, then only an equality
test for specific versions (known by the client to have bugs)
is needed.  All other versions should be considered to properly
implement specifications.

>Clients that rely on this attribute do so at their own risk

I concur with this statement.

>and they should code the behavior that they think is best for them.

>This draft can't stipulate that an

Right... so next folks will ask that we extend the protocol
so that servers will know the vendorName/vendorVersion of
CLIENTS so servers can adapt to clients.

One-off workarounds lead to future inoperability problems.

>Good point.  I agree.  So we might as well just stick with one value

Again, who's the vendor?  Is the implementor core server the vendor?
Is the packager who screwed their build the vendor?  Is the
implementor of the buggy syntax plugin the vendor?  Is the OS
vendor who shipped a buggy support library?  Is the support
contractor the vendor?

This is a rat hole.

---

From: "Peter Strong" <[email-masked]>
Date: Thu, 10 Feb 2000 23:25:58 -0500

Hi,

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Thursday, February 10, 2000 6:22 PM
> To: Mark Smith
> Cc: Mark Meredith; [email-masked]; Roger Harrison;
> [email-masked]
> Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt
>
>
> information are fundamentally broken.

My basic opinion is that you are not living in the real world!

I challenge you to modify the schema of a Netscape directory server,
a Novell directory server and an MS Active Directory server without
knowing the type of server to which you are connected.

When we install our products against different directory implementations,
we need to know the vendor - they all have quirks and irregularities
that make such things as schema modification tricky.

It would be ideal if this weren't the case, but it is, and probably
always will be.

> That is, a client should

For most basic operations, clients shouldn't experience difficulties.
However, for things like schema modification, access control specification,
creation of new naming roots or subtrees, I know that significant
differences exist and that these differences won't go away any time
soon.

> is restricted to DISPLAY PURPOSES ONLY.

Again, I have to disagree - we'll have to use this information to make
appropriate choices in how to deal with particular server implementations.
If we screw something up while doing this, well, that's our fault. But
at least these small scraps of information give us a small chance of
overcoming implementation descrepancies.

> implement specifications.

Actually, the instances that I mentioned above don't appear to bugs. They
appear to be cases where vendors have knowingly strayed from the standards
(for whatever reason). More than likely, they haven't made these decisions
without reason, and, when confronted about it, will likely indicate that
they will "probably fix it in a future release". Yeah, right!

In the mean time, I have to get product out the door.

> I concur with this statement.

As do I.

> One-off workarounds lead to future inoperability problems.

Yes, but lack of any workaround leads to products that don't work AT ALL!

We will always have interoperability problems. That's not being pessimistic,
that's being realistic. I'm all for promoting as much interoperability and
adherence to standards as possible, but I'm under no delusions that we'll
ever achieve 100% interoperability for all directory implementations all
the time.

> >Good point.  I agree.  So we might as well just stick with one value

Sounds fine.

> vendor who shipped a buggy support library?  Is the support

The only rat hole appears to be the argument against having a couple
of simple attributes available to the poor bastards who have to actually
build products on top of directory technology as it exists today!

Regards,

  Peter

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 11 Feb 2000 09:20:29 -0800

At 10:46 AM 2/9/00 -0700, Mark Meredith wrote: 
>discover features. It is just an informational attribute. 
 
Mark,

I believe you should clarify the intented use of these attributes.
I recommend you state your intent in your abstract, or add
a "Background and Intended Use" section.  Then rework rest
of document to be consistent with this intent.

In particular, you state that may be used discover X- features
in the overview.  And in the security section:
   The vendorName and vendorVersion attributes are provided only as an
   aid to help client implementers assess what features may or may not
   exist in a given server implementation.

This in inconsistent with Section 6.  If this section is
consistent with your intent, I suggest the following wording
be added someone early on in the document:
	Attributes defined by this specification are intended
	for informational purposes only and SHOULD NOT be
	used for feature discovery.

You also note that you intend that these attributes be used
to allow clients to workaround implementation bugs based
upon vendor specific information.  Though I believe it quite
appropriate to encourage clients to be "liberal in what they
accept", I believe we must be very careful not to encourage
one peer to violate the specification because they assume
the other has.  We must be very careful in the wording which
allows any non-informational use of these attributes.

Kurt