"space" handling in "case ignore match" string matching rule?

[Jeff Hodges <Jeff.Hodges@Stanford.edu>]

This question has to do specifically with the handling of spaces in "case
ignore match" string matching rule as applied in the context of a substring
filter (i.e. a filter assertion string containing wildcards and space
character(s))...


In RFC2251, filter processing is discussed as a blurb towards the end of
section "4.5.1. Search Request". At the end of that blurb, there's this
reference..

     "More details of filter processing are given in section 7.8 of X.511
      [8]."


In section "7.8.2	Filter item", ITU-T Rec. X.511 (1993 E) sez..

A FilterItem may be undefined (as described above). Otherwise, where the
FilterItem asserts:
a)	equality - It is TRUE if and only if there is a value of the attribute or
one of its subtypes for which the equality matching rule applied to that value
and the presented value returns TRUE.
 b)	substrings - It is TRUE if and only if there is a value of the attribute
or one of its subtypes for which the substring matching rule applied to that
value and the presented value in strings returns TRUE. See ITU-T Rec. X.520 |
ISO/IEC 9594-6 for a description of the semantics of the presented value.


ITU-T Rec. X.520 (1993 E)  sez...

6.1	String matching rules
In the matching rules specified in 7.1.1 through 7.1.11, the following spaces
are regarded as not significant:
---	leading spaces (i.e. those preceding the first printing character);
-	trailing spaces (i.e. those following the last printing character);
-	multiple consecutive internal spaces (these are taken as equivalent to a
single space character).
In the matching rules to which these apply, the strings to be matched shall be
matched as if the insignificant spaces were not present in either string.


(besides the "7.1.1 through 7.1.11" actually meaning "6.1.1 through 6.1.11", I
suspect)


..so, the above taken together implies to me that if I have a set of entries
like so..


  cn=afs a test
  cn=afs b test
  cn=afs c test
  cn=afs d test
  cn=afs e test
  cn=afs f test
  cn=afs g test
  cn=afs h test
	:

Then a filter of "(cn=* f* test)" ought to find ~only~ "cn=afs f test", unless
the space in the leading "* " portion of the filter is evaluated as being
equivalent to a "leading space" and the filter is conflated to "(cn=*f* test)"
prior to actual application. 

If the latter occurs, then the results of such a search against the test
entries above simply returns all the test entries (which isn't exactly what
I/we were expecting). 

Is this behavior "correct" according to other's interpretation of RFC2251 (+
X.511 & X.520, as referenced by RFC2251)?  I.e. I'm wondering if the
particular directory server implementation we're using is handling this filter
assertion string correctly or not. 

thanks,

Jeff


--
Jeff Hodges                                   Jeff.Hodges@Stanford.edu
Senior Technical Staff                          voice: +1 650 723 2452
Directory Services and PKI                        fax: +1 650 723 0908
Stanford University                   http://www.stanford.edu/~hodges/