Re: ListMatch Clarification

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

Daniel,

Daniel Henninger wrote:
> Folk,
>
> I'm looking into implementing the ListMatch style matches and submitting a
> patch.  I am having some trouble understanding part of the specification.
> I understand that $ is effectively a newline.  The draft seems to indicate
> that you ignore $ (ie, pull it out) and escape (\).  That said, the part
> I'm not clear on is the actual search string.  Does the $ get handled in
> the search string as well?  For example, lets say I want to find someone
> on Foo Street, in Raleigh, NC.  Would I do a search along the lines of:
> postalAddress=*Foo Street $ Raleigh, NC*
> or
> postalAddress=*Foo Street * Raleigh, NC*
> or both?

The second assertion value is the one that applies. The assertion syntax for
caseIgnoreListSubstringsMatch is Substring Assertion, for which $ is an
ordinary character (only * and \ are special). The first assertion value
would only match if there were an escaped $ (i.e. not a line separator)
in a line of the address (where only $ and \ are special).

The unescaped $ line separators in a Postal Address value are an artefact
of the LDAP-specific encoding and are not matchable character data.

> Also is there supposed to be a space on both sides of the $, similar to
> how $'s are used in schema, or would there be no spaces?

There is no requirement either way, and for caseIgnoreListMatch it makes no
difference since each line of the address is matched according to
caseIgnoreMatch which ignores leading and trailing space on each line.
It makes no difference for caseIgnoreListSubstringsMatch as well
because of the interaction of stringprep and the requirement that
a substring in an assertion value for caseIgnoreListSubstringsMatch
does not match characters across multiple lines.

Regards,
Steven

> Daniel