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

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

Harald,

Just for clarification, the discovery issue is not specific to
the component matching rule specification.  It applies to all
elective LDAP/X.500 matching rules.  That is, PKIX has the same
problems when using certificateExactMatch or any other non-mandatory
to implement matching rule they would need for "LDAP/X.500
certificate lookup and retrieval".  If they need discovery
capabilities, they will need them regardless of which matching
rules they choose to use.

As this is a general issue, it is not something which this
I-D should attempt to address.  We should instead ask LDAPBIS
to consider the general issue in its revision process.

Kurt

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


>--On mandag, mai 12, 2003 07:15:47 -0700 "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:
>
>>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).
>
>Thanks, I am much relieved.
>
>Russ, Steve - the pkix folks will have to say if the searches they want to perform work (fail?) the right way when "undefined" is returned.....
>
>                  Harald