[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ListMatch Clarification
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