Re: Comments: draft-mmeredith-rootdse-vendor-info-03.txt

["Mark Meredith" <MMEREDIT@novell.com>]

Kurt,

This is now being done on the Informational track. I have been working with Patrk Faltstrom on this.

For section 4.1, I understand what you are saying, but I think it is reasonable to have something like
OpenLDAP, XYZ Inc.
To state that XYZ Inc. did this version of OpenLDAP. This way the application developers would know that OpenLDAP was the base and XYZ was the company that was ultimatly responsible for the possible differences from the OpenLDAP code if any.

For section 4.2, It is up to the vendor to determine what and how his versions are done. this is only to state that the version MUST change between releases so version 1.0 and version 1.1, or "OpenLDAP 2.0.6   XYZ Inc. 3.1"

For section 5, I understand what you are saying, but I feel, that if these attributes are able to be modified then the clients and applications, are no better off than today in not knowing what server they are talking to.

For section 6, I like your addition. I think that most LDAP servers should support plug-ins and that could change the behavior for that extension, or control, etc.

I will add that to my copy of the draft.

-Mark



Mark Meredith
Software Engineer
Novell Inc
1800 Novell Place, Provo UT 84606
mark_meredith@novell.com
801-861-2645

Novell, Inc., the leading provider of Net service software
www.novell.com

---------------------
A boat in the harbor is safe, 
but that is not what boats are for.
--John A. Shed
---------------------

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/21/00 05:24PM >>>
Mark,

Here are some comments...

	Kurt


The abstract says: "MUST NOT be used for feature advertisement or
discovery" yet section 3.1 describes exactly this.  

4.1 vendorName
   This attribute contains a single string, which represents the name
   of the LDAP server implementer.

I suggest the specification allow the vendorName to contain any
string representing the name of the vendor.  In the world of
OEM'ed software, the name of the implementor may not be the
most appropriate name to place here.

4.2 vendorVersion

4.2 states "This string MUST be unique between two versions".
I assume it's up to the vendor to determine what constitutes
a version.

5. Notes to Server Implementors

I suggest, like HTTP vendor version strings, the I-D state that
server implementors may make the vendorName and vendorVersion
strings configuration items.  The reality is that clients will
abuse these values and servers need to support spoofing.

6. Notes to Client Developers

It should be noted that an anomalies often on affect subset
of implementations reporting the same version information.
Most implementations support multiple platforms, have numerous
configuration options, and often support plugins.

Lastly, I believe Informational would be a more suitable category
for this proposal.