RE: Last Call Comment: LDAP & X.500 Component Matching Rules toProposed Standard

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I'm glad I got dragged in to this thread.

With regard to discovery of matching rule support, today in LDAP
and X.500 there is NO discovery mechanism that a client can use for
determining whether a server supports a particular rule, any rule!

And, even if it were, it would be of significant value given the
distributed nature of LDAP/X.500 directories.  That is, what good
is the discovery answer at the first server chains the subsequent
request using the feature to a second server?

These problems are generally address by a) having tri-state
filter logic (unsupported matching rules evaluate to Undefined,
which is not an error) and, in X.500, assertion relaxation
(or tightening).

And it's not like clients actually do feature discovery.

Anyways, we're only talking about Proposed Standard here.  If
feature discovery becomes an issue in actual deployments (it
hasn't become a significant issue with regard to matching rules
in general), then let's deal with it later.

Kurt

At 12:52 AM 5/12/2003, Harald Tveit Alvestrand wrote:


>--On mandag, mai 12, 2003 17:29:44 +1000 Steven Legg <steven.legg@adacel.com.au> wrote:
>
>>
>>Hi Harald,
>
>Hi Steve!
>
>(Kurt - you have been dragged into this thread because of draft-zeilenga-ldap-features - see section at the end...)
>>
>>Harald Tveit Alvestrand wrote:
>>>Last Call comment on this document:
>>>
>>>The document fails to describe how a client can determine
>>>whether or not an
>>>LDAP server implements the componentFilterMatch matching rule.
>>
>>Which is normal practice for matching rule definitions, and various
>>other things in LDAP. LDAP and X.500 don't have a standardized
>>mechanism for determining what a server can or can't support,
>>and LDAP specifications rarely address this question.
>>draft-zeilenga-ldap-features-xx.txt is attempting to rectify this
>>situation, though it is not clear to me what the current status
>>of this draft is.
>>
>>One way to deal with the varying capabilities of LDAP servers
>>is for directory-using application specifications to include an
>>application profile that lists all the features, matching rules included,
>>that an LDAP server must support in order to claim conformance with the
>>application. This is the approach PKIX has taken.
>
>so instead of specifying a ways to find out runtime, you have a way to
>specify it at procurement time..... I wouldn't call it invalid, but it
>seems unpleasant to me....
>
>>
>>>
>>>Since the extension is complex, and presently unsupported,
>>
>>There is one implementation.
>
>good. I was thinking "unsupported in the presently fielded LDAP servers".
>>
>>>it
>>>will likely
>>>be critical for interoperability (and proper error messages)
>>>that a client
>>>know how to check whether this extension is present or not in
>>>a server.
>>>(It's possible, albeit expensive, for a client to have
>>>fallback in some
>>>situations by pulling large sets of objects to the client and
>>>doing the
>>>required matching client-side. Unless he knows whether or not it is
>>>supported, this becomes more complex.)
>>>
>>>It is not clear to this reader whether this should be indicated via
>>>"supportedControl", "supportedExtension",
>>>"supportedLDAPVersion"
>>
>>None of the above apply. The best fit is "supportedFeatures" from
>>draft-zeilenga-ldap-features-xx.txt, though it is debatable whether
>>a simple yes/no indication is adequate for expressing support for
>>something as expansive as component matching. I expect at least some
>>implementors will support component matching incrementally, thus
>>application profiles would appear to be more appropriate. I leave it to
>>the IESG to decide.
>
>ouch - you're saying that you expect clients to have to deal with not only implemented/unimplemented, but with partial implementations?????
>
>that gets VERY thorny to deal with client-side... if you specify one or two subsets, I could live with it, but "random subset of functionality implemented" is something I do not like to say is conformant to any IETF protocol.....
>
>but in an ideal world, that would be decided by an LDAP WG, not by the IESG.
>
>fyi, the present situation with draft-zeilenga-ldap-features is that it was looked at by the IESG in November of last year, but was returned to the author with comments, and hasn't been updated since. I'm CCing Kurt on this mail too, so that he gets a heads-up.... if that document makes it through quickly, I'd be a LOT happier if you specified an OID for use with "supportedFeatures"....
>
>                  Harald