Re: LDAPprep: mapping of " " values

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

I wonder if I should pretend I never wrote that message...
OTOH, I still wonder if something like it does make the best sense.

Kurt D. Zeilenga writes:
> 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:

Yuck.  That was _not_ the introductory statement which should have been
there.  Add "...plus a reasonable way to treat spaces differently next
to the '*' in substrings, plus not treating empty strings as an error in
this context":-(

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

The _prepared_ substrings are matched with the _prepared_ attribute
value.  E.g. in [Syntaxes] 4.2.6 (caseExactSubstringsMatch).  That one,
at least, seems clear to me with the present drafts if one is to take
the spaces as significant at all.  It would certainly be useful to have
it match "foo bar" but not "foobar", but I can't justify such a result
in a way I can approve of.

Skipping a few now-irrelevant points - but it all made sense until I got
to...

>>- "* *" matches all values containing a space.
>
> If " *" matches "foo" then "* *" should match "foo" because
> the ANY substring has even less restrictions on it than an
> INITIAL (or FINAL) substring.  That is, basically by definition,
> if (l=X*) matches, (l=*X*) MUST match for all X.  Likewise for
> (l=*X).

Oops.  Forgot that one.  I arrived by the other cases by similar logic.
E.g. (l= x*) matches "x", so (l= *) should also match "x".  (l= )
matches " ", so (l= *) should also match " ".  Oh well.

>>- So " * * " matches <anything non-space spaces non-space anything>.
>>  (Collapse multiple spaces, then combine the two rules above.)
>
> I disagree.  It should match "foo".  This because the INITIAL
> substring can match a leading space in an equivalent value,
> the ANY string can match a subsequent leading space in an
> equivalent value, and the FINAL can match a trailing space
> in the an equivalent value.

That's one I disagree with.  And I don't get the explanation, either
in terms of the current draft nor in terms of changing spaces to be
different in substrings.

-- 
Hallvard