Re: Vendor Info

[Mark Meredith <MMEREDIT@novell.com>]

I had intended these to only be set by the developer of the server on compile time. I feel that if you are able to change the values then there is really not any better than not having the values, I would like to have some confidence that the information if provided is accurate according to what the developer put there is valid.

As for changing the wording . "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, ..."
What word would you recomend to clarify recognize? Or how would you re-word it to take recognize out or make it more solid (clear).

-Mark

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 02/14/00 08:03PM >>>
At 07:12 PM 2/14/00 -0700, Jim Sermersheim wrote:
>>Section 5.
>>
>>If a server supports these attribute types, the values should
>>be overwritable by configuration.  This allows a server to
>>"spoof" clients to obtain desired behavior.
>
>Are you requesting that this wording be added to the draft? If so, why? Perhaps your should should've been a shouldn't?

I suggest using wording similiar to that found in the RFC 2616 (HTTP 1.1):
  Server implementors are encouraged to make the values of these
  attributes configurable options.

Note, they encourage suggest for security reasons.  Though quite valid,
I suggest it primarily for interoperability.  I've already seen folks
hack OpenLDAP to spoof other servers so that they could use some client
which inappropriately depended provided vendor information.  [In
believe the vendor ended up hacking their own server to spoof the
old version so that their client would work].

>>Clients should not attempt fuzzy matching.  They must only
>>enable workarounds when the server presents a vendor strings
>>known to evident of specific flaws.
>
>While this may be good advise, I don't see it as a requirement. If a client writer knows that versions 5.0 thru 5.x all exhibited a certain bug, and it was fixed in 6.0, it's reasonable for them to assume that a version substring of 5. will exhibit the bug.

No, because the vendor may, even after producing 6.0, produce a 5.y which fixes
the behavior.  This sometimes occurs because a large customer of the vendor
specifically requests a patch for the older version and the vendor complies.
It is not uncommon for a vendor to support and revise multiple versions
for significant time.

>>  They must assume that all
>>unknown vendor strings behavior per standard track specifications.
>
>Are you requesting that this wording be included in addition to, or in lieu of: "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, then for the purposes of 'working around' anomalies, the client MUST assume that the server is complete and correct."?

I would prefer to clarify the term "recognize".