Re: ListMatch Clarification

[Steven Legg <steven.legg@adacel.com.au>]

Kurt,

Kurt D. Zeilenga wrote:
> I think the syntax I-D note regarding LDAP-string encoding
> handling is causing some confusion here.  I would instead
> say that caseIgnoreSubstringsListMatch(substrings,list) is,

caseIgnoreListSubstringsMatch

The function notation you are using hasn't been defined anywhere.

> in terms of the LDAP-specific encodings, acts like
> caseIgnoreMatch(escape(substrings),list) where escape()

caseIgnoreSubstringsMatch

> escapes "\" and "$" appearing in substrings so that they
> will properly match like characters appearing in list
> strings (but not list separators).

I prefer to be replacing escapes in the concatenated string rather
than adding escapes to the substrings of the substring assertion because
the latter is heading down the direction of comparing LDAP-specific
encodings rather than comparing abstract values.

The syntax definition for SubstringAssertion currently only allows
escapes for "\" and "*". It would need to be extended to allow for "$"
as well.

There is also the problem that the concatenated string, which is notionally
of the Directory String syntax, or similar, would contain escaped "$" but
the Directory String syntax does not have a defined escaping mechanism in
either RFC 2252 or the syntaxes draft. If we regard "\24" as literal text
then we have a weird situation where caseIgnoreSubstringsMatch matches "\24"
with "\24" but not "$", while "\2A" matches "*" but not "\2A". Yikes!

Regards,
Steven