Re: LDAPprep: mapping of " " values

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

Buried in a previous post, was my view that (l= * ) matches everything
(presence filter the hard way), following these steps:
1) (l = * *) becomes
    initial " ", any "*", final " "
2) preparation of the filter substrings converts this to
   initial "", any "*", final "" (empty substrings)
which is basically a presence filter.

Or it matches nothing because the leading and trailing spaces in "l" values
are not significant.  I think it would not be acceptable to change the
existing string matching rules to state that leading and trailing spaces in
an entry value are significant (or treat consecutive spaces like anything
other than a single space).

And I suggested that if we want a filter like (l = * ) to match " foo " but
not "foo", we should define additional matching rules.

Furthermore, even with such additional matching rules, I'd expect that (l=
* ) would not match " " (single space), as that requires the same character
to be simultaneously matched by all three filter substrings (or at least
the initial and final substrings).

I think I've said enough on this now and will let the working group get on
with their business.


John  McMeeking


owner-ietf-ldapbis@OpenLDAP.org wrote on 11/19/2004 09:01:57 AM:

> At 06:30 AM 11/19/2004, John McMeeking wrote:
> >"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote on 11/18/2004 09:15:52 AM:
> >> At 10:44 PM 11/17/2004, Hallvard B Furuseth wrote:
> >> >I need to read up on X.520, but:  The behaviour which seems most
> >> >consistent with the current ldapbis documents seems to me to be:
> >> >
> >> >- "foo * bar" does not match "foo bar" - the two spaces in the
> >> >  substrings do not match _disjoint_ portions of "foo bar".
> >> >  Nor does it match "foo  bar", which is equivalent to "foo bar".
> >>
> >> My view is that (l=foo * bar) since "foo X bar" without
> >> consuming any portion of X, it should match "foo  bar"
> >> (which passes your disjoint concern), and since "foo bar"
> >> is equivalent, that too.
> >
> >I don't see how (l=foo * bar) can match "foo bar" (single space).
Doesn't
> >that require that the trailing and leading spaces in the filter
substring
> >match the same character?  The * is supposed to match zero or more
> >characters between two substrings, not allow the substrings to overlap.
>
> It's matching the same trailing/space space in the same sense
> that (l= * ) matches " ".
>
> >I'd also argue that (l=foo * bar) does NOT match "foo  bar" because "foo
> >bar" is equivalent to "foo bar".  I know it seems like it ought to
match,
> >and I wouldn't complain if it did match, but I think it is reasonable to
> >say that for matching purposes, the server compares filter substrings to
> >the equivalent prepared string (according to the matching rule) "foo
bar",
> >which (l=foo * bar) does not match (or so I believe).  I think that
would
> >be far easier to describe than, and has a consistency that I find
lacking
> >in, these examples where sometimes a given space is insignificant, and
> >sometimes the same space in the same string (entry value or filter
> >substring) is significant.
>
> Here's the question, can spaces in the asserted value match
> insignificant spaces in the attribute value?  If we say no,
> then (l= * ) must not match any string.  If we say yes,
> then (l= * ) matches every string.  And, as I've shown above,
> the choice impacts other matching behavior.
>
> Kurt
>