[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Vendor Info
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 2/14/00 2:48:50 PM >>>
>What is the intent of this statement:
> These attributes are an addition to the Server-specific Data
> Requirements defined in section 3.4 of [RFC-2251].
>
>Do you mean to imply that servers MUST provide these values? You
>later say SHOULD maintain these attributes types. As noted previously,
>I believe the publication of these attributes should be elective.
>That is, a server MAY provide these attributes.
I think the intention was to simply point out that these are attributes in the root DSE, much like those found in section 3.4 of RFC 2251. I don't think there's any implication that these are mandatory.
>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?
>Section 6.
>
>A client must not assume that all servers advertising a particular
>version string behave in a like manner. The apparent flaw may
>only be exhibited in a subset of the servers advertising a
>particular version. This may be due to any number of environmental
>factors.
Good point.
>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.
> 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."?
Jim