Re: ListMatch Clarification

[John McMeeking <jmcmeek@us.ibm.com>]

I'm responding to test my understanding.

As I understand it, matching applies to the entire address as a
concatinated string, excluding the $ separators, except that * --
<initial>, <any>, or <final> -- does not span lines in an attribute value.
That is, * matches a substring of a line or the entire line, but not parts
of two lines.

Applying this to your later examples:

> Hrm.  Ok, let me see if I understand this correctly.  The address query
is
> matched on lines, not the string as a whole?  Given address:
> 123 Foo Street
> Raleigh, NC 12345
> aka: 123 Foo Street $ Raleigh, NC 12345

Matching will be applied to the concatinated string "123 Foo Street
Raleigh, NC 12345" with a hidden separator replacing the $.

>
> If I did a query of *Raleigh*, I would expect it to:
> 123 Foo Street      no match
> Raleigh, NC 12345   match
>    address matches

Matches:
Initial * matches "123 Foo Street", "Raleigh" matches Raleigh, final *
matches ", NC 12345"

>
> If I did a query of *Foo*, I would expect it to:
> 123 Foo Street      match
> Raleigh, NC 12345   no match
>    address matches

No match:
Initial * matches either a) the entire first line or b) "123"
a) "Foo *" does not match second line
b) "Foo *" matches "Foo Street" but does not include the next line of the
address.

>
> But what if I did *Foo Street*Raleigh*, I would expect it to:
> 123 Foo Street      no match
> Raleigh, NC 12345   no match
>    address doesn't match

Matches:
Initial "*Foo Street" matches 1st line, 2nd "*" matches empty string,
"Raleigh*" matches 2nd line.

Personal observations:
- Since the middle * is matching an empty string, "*Foo Street Raleigh*"
should also match.
- "*Foo Street*Raleigh*" could also match addresses like:
   123 Foo Street NW
   Raleigh, NC 12345
or
   123 Foo Street
   North Raleigh, NC 12345

>
> Is this a correct interpretation of how it should work?  If you wanted to
> make sure it was Foo Street in Raleigh, NC, how would you go about doing
> that?  (&(postalAddress=*Foo Street*)(postalAddress=*Raleigh*)) ?

Is my interpretation any better?

John  McMeeking


owner-ietf-ldapbis@OpenLDAP.org wrote on 06/21/2004 06:55:08 AM:

> > > 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.
>
> Hrm.  Ok, let me see if I understand this correctly.  The address query
is
> matched on lines, not the string as a whole?  Given address:
> 123 Foo Street
> Raleigh, NC 12345
> aka: 123 Foo Street $ Raleigh, NC 12345
>
> If I did a query of *Raleigh*, I would expect it to:
> 123 Foo Street      no match
> Raleigh, NC 12345   match
>    address matches
>
> If I did a query of *Foo*, I would expect it to:
> 123 Foo Street      match
> Raleigh, NC 12345   no match
>    address matches
>
> But what if I did *Foo Street*Raleigh*, I would expect it to:
> 123 Foo Street      no match
> Raleigh, NC 12345   no match
>    address doesn't match
>
> Is this a correct interpretation of how it should work?  If you wanted to
> make sure it was Foo Street in Raleigh, NC, how would you go about doing
> that?  (&(postalAddress=*Foo Street*)(postalAddress=*Raleigh*)) ?
>
> Thanks!
>
> Daniel
>
> >
> > >
> > > 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
> > >
> >
> >
>
> --
>
/\\\----------------------------------------------------------------------///\

> \ \\\      Daniel Henninger           http://www.vorpalcloud.org/
/// /
>  \_\\\      North Carolina State University - Systems Programmer
///_/
>     \\\                   Information Technology <IT>
///
>      """--------------------------------------------------------------"""