[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: vendor name - draft-ietf-ldapext-ldap-c-api-04.txt

Again, my comment on this was pointing out what I consider
to be a minor knit.  We should attempt not to get wrapped
around the axle on this.

At 11:44 AM 5/20/00 +0100, Al Sutton wrote:
> There are a
>number of situations where version x.y of a Directory servers, OS's, web
>servers, etc. is a bit flakey, but apply patch z to it and it fixes a
>problem that causes your application to suffer.

Bug/feature detection is not the purpose of this value.

IIRC, the intented use of the this value is to allow an
application to detect a simple header/library mismatch.

I note that provide such, in the days of dynamically linked
libraries, such can backfire.  A vendor needs to be able to distribute
a patch in a manner which doesn't require applications to be
rebuilt.  This is normally done by incrementing the minor
number of the dynamic link library.  However, if this library
as a imbedded version number which is exposed to applications,
the application could detect a change that it should ignore.
As such, the value of such a varible is limited.  It's
likely cause more problems than it's worth.

I also note that this specification is written at the
"source level."  Hence, we should not attempt to resolve
"link level" issues.  These are better left to implementations
and the platforms they support.  (This is an argument for
removing vendor_version altogehter).

I believe that this value can only be made useful to
applications by the vendor as versioning issues are
platform and/or implementation specific.  We must not
overspecify the value as this would limit the vendor's
ability to make this value useful.

As such, I like to replace the second paragraph from my
suggestion which describes X.Y, X.Y.Z, etc. with a
description of the intented use of this value (header/library
mismatch).  In fact, I'd just add "Applications may use
vendor name/version information to detection header/library
mismatches."  Maybe even add to the example code how this
should be done.  I also suggest adding some sort of warning
that this information should not be used for feature detection,
other mechanisms for this are provided.

Kurt