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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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.


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.

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

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

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

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.