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>
///
"""--------------------------------------------------------------"""