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

[Peter Strong <pestrong@nortelnetworks.com>]

Hi,

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Thursday, February 10, 2000 6:22 PM
> To: Mark Smith
> Cc: Mark Meredith; M.Wahl@INNOSOFT.COM; Roger Harrison;
> ietf-ldapext@netscape.com
> Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt
>
>
> My basic option on this proposal as a whole:
>
> I think implementations that needs such specific vendor/version
> 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
> 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).

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.

> As such, I can only support such attributes if their use is
> 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.

> At 04:39 PM 2/10/00 -0500, Mark Smith wrote:
> >But your comment seems to be in conflict with this text from the
> >document:
>
> 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.

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.

> >
> >>  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.
>
> >Clients that rely on this attribute do so at their own risk
>
> I concur with this statement.
>

As do I.

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

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.

> >
> >
> >
> >>
> >> >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.
> >>
> >> 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.
> >
> >Good point.  I agree.  So we might as well just stick with one value
> >(vendorName).
>

Sounds fine.

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

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
pestrong@nortelnetworks.com <mailto:pestrong@nortelnetworks.com>
(613) 831-6615