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

Re: Vendor Info

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