[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: ListMatch Clarification

To: daniel@ncsu.edu
Subject: Re: ListMatch Clarification
From: John McMeeking <jmcmeek@us.ibm.com>
Date: Mon, 21 Jun 2004 10:54:11 -0500
Cc: ietf-ldapbis@OpenLDAP.org
In-reply-to: <Pine.GSO.4.58.0406211059580.17557@ghidora.unity.ncsu.edu>



I think you've got it right, assuming someone else doesn't correct me.

Would it help to have some examples in the ldapbis syntaxes draft
illustrating some of these cases?

John  McMeeking


Daniel Henninger <daniel@unity.ncsu.edu> wrote on 06/21/2004 10:12:00 AM:

> > 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.
>
> So if I'm understanding that correctly, one would have to do:
> *Foo**NC* to match my example below?  I'll get to that.

That's how I understand it.

>
> > 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 $.
>
> but the hidden seperator "stops dead" the *?  is that correct?

I believe so.  Both X.520 and ldapbis [SYNTAXES] say:

   ... none of the <initial>, <any>, or <final> substrings of the
   assertion value are considered to match a substring of the
   concatenated string which spans more than one of the original strings
   of the attribute value.

>
> > > 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"
>
> And it only matches Raleigh because Raleigh is right at the beginning of
> the line.  Correct?  If it were *NC*, it would -not- match?

Correct, (postaladdress=*NC*) would not match this address.

>
> > > 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.
>
> Ok, that makes sense based off my understanding from above.  =)
>
> > > 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
>
> Because the first line would match *Foo Street* and the second line
> would match the Raleigh* portion.
>
>
> > or
> >    123 Foo Street
> >    North Raleigh, NC 12345
>
> And because the first line would match *Foo Street and the second line
> would match *Raleigh*.
>
> > Is my interpretation any better?
>
> Yes, that makes sense.  Makes it a lot harder to parse, but hey.  =)
> Thanks!
>
> Daniel
>
> >
> > 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>
> > ///
> > >
"""--------------------------------------------------------------"""
> >
> >
>
> --
>
/\\\----------------------------------------------------------------------///\

> \ \\\      Daniel Henninger           http://www.vorpalcloud.org/
/// /
>  \_\\\      North Carolina State University - Systems Programmer
///_/
>     \\\                   Information Technology <IT>
///
>      """--------------------------------------------------------------"""
Follow-Ups:
- Re: ListMatch Clarification
  - From: Daniel Henninger <daniel@unity.ncsu.edu>
References:
- Re: ListMatch Clarification
  - From: Daniel Henninger <daniel@unity.ncsu.edu>
Prev by Date: Re: ListMatch Clarification
Next by Date: Re: ListMatch Clarification
Index(es):
- Chronological
- Thread