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

["Al Sutton" <al@alsutton.com>]

I think we should state that version numbers should only be of the form
X.Y.Z.

I know that it is a vendor specific field and will vary from implementation
to implementation, but hopefully having the X.Y.Z format help to persuade
vendors to put patch levels as well as major/minor version numbers into this
field to ensure we can check for specific versions & patches. 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.

Maybe we should say;

ldapai_vendor_version
An implementation-specific version number which, in
combination with ldapai_vendor_name, uniquely describes
this version of the implementation.  The number MAY
or MAY NOT relate to the any version number used elsewhere
by the vendor.  The value SHOULD match the value of
LDAP_VENDOR_VERSION described earier in this document.

<new bit>
Vendors use the format (X * 6400) + (Y*64) + Z to calculate
this field. X should be used to represent the major version number, Y should
represent the minor version number, and Z should represent a patch level. Z
should be treated either  as a number, or as a 6 bit binary set for
situations where
it is possible for seperate patches can be applied without preceeding
patches
being installed).
</new bit>

The reason I've included the binary set section is for situations where
vendors use
third party underlying software to handle replication, datastorage, etc. It
will allow them to subdivide
the field up into bit sets for various patches. An example could be if, say,
Informix is used
as the datastore the lowest three bits of Z could represent informix
patches, and the
highest three bits could represent directory server patches. That way the
vendor could distribute patches
for problems with datastorage seperately from problems to do with the
directory interface and still be able to keep track.

It also gives us the advantage of allowing for more major version numbers.

How does it sound?

Al.
> For vendors with software versions of the form X.Y, it is
> suggested a value of X*10000+Y and for the form X.Y.Z,
> (X*100+Y)+100+Z.  That is, 4.1 would be 40001 and
> 4.1.2 would be 40102.   For dated releases, version number
> derived from the date such as 20000519.  Other schemes
> (or no scheme) may be used.


Al.

----- Original Message -----
From: Kurt D. Zeilenga <Kurt@OpenLDAP.org>
To: Mark Smith <mcs@netscape.com>
Cc: <ietf-ldapext@netscape.com>
Sent: Friday, May 19, 2000 9:41 PM
Subject: Re: vendor name - draft-ietf-ldapext-ldap-c-api-04.txt


> I suggest the following change to resolve a couple of knits.
> It reduces the requirements to to bare minimun needed to allow
> applications to verify they have linked in what they compiled with.
> It also explicitly allows for alternative version numbering schemes.
>
> ldapai_vendor_version
> An implementation-specific version number which, in
> combination with ldapai_vendor_name, uniquely describes
> this version of the implementation.  The number MAY
> or MAY NOT relate to the any version number used elsewhere
> by the vendor.  The value SHOULD match the value of
> LDAP_VENDOR_VERSION described earier in this document.
>
> For vendors with software versions of the form X.Y, it is
> suggested a value of X*10000+Y and for the form X.Y.Z,
> (X*100+Y)+100+Z.  That is, 4.1 would be 40001 and
> 4.1.2 would be 40102.   For dated releases, version number
> derived from the date such as 20000519.  Other schemes
> (or no scheme) may be used.
>
> (with similiar changes to the earlier section also being updated).
>
>