Subject: Substrings any match on an empty string

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 8 Jul 2003 15:04:23 +1000

Hi all,

Does anyone have an answer to this question:

If I specify a filter of type 'substrings' where the substrings contain only an 'any' with a zero-length value, should I return all entries containing the attribute?

It seems to me that the empty string is a substring of all strings.

I've looked in RFC 2251, X.511 and X.520 but have not seen a statement which I could interpret as answering this question.

Thanks for your help,

Ron

---

From: "Vithalprasad Gaitonde" <[email-masked]>
Date: Mon, 07 Jul 2003 23:23:11 -0600

Wouldn't this just be equivalent to a presence filter on that
attribute.
We should have a statement in the LDAP protocols draft saying that the
filter that you describe is equivalent to a presence match.
Prasad

>>> "Ramsay, Ron" <[email-masked]> 7/8/2003 10:34:23 AM >>>
Hi all,

If I specify a filter of type 'substrings' where the substrings contain
only an 'any' with a zero-length value, should I return all entries
containing the attribute?

I've looked in RFC 2251, X.511 and X.520 but have not seen a statement
which I could interpret as answering this question.

Thanks for your help,

Ron

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 08 Jul 2003 00:34:36 -0600

What if the assertion syntax requires >0 octets? And/or what if the
substring matching rule has a special provision for the empty value?

Jim

>>> "Vithalprasad Gaitonde" <[email-masked]> 7/7/03 11:23:11
PM >>>

Hi all,

If I specify a filter of type 'substrings' where the substrings
contain
only an 'any' with a zero-length value, should I return all entries
containing the attribute?

Thanks for your help,

Ron

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 08 Jul 2003 02:10:17 -0600

Ok, after re-reading the [Protocol] statement, it only says:
     The matching rule for AssertionValues in a substrings filter item

     is defined by the SUBSTR matching rule for the attribute type. 
(nothing about the syntax of those AssertionValues)

And after reading Section 5.1 of [Syntaxes] further, I see:
   The entire
   SubstringFilter is converted into an assertion value of the
   substrings matching rule prior to applying the rule.

So, I see a few issues:

1) [Protocol] should likely specify the bit about which syntax is to be
used in SubstringFilter AssertionValues.
2) [Protocol] should likely talk about the conversion into the
substrings matching rule syntax (as [Syntaxes] does).
3) The answer to Ron's original question is that it's *always* invalid
to have an empty _any_ part--correct? This is because even though an
equality assertion syntax might allow zero octets, the Substring
Assertion syntax (which we need to convert to) never allows a
zero-length substring.

Jim

>>> "Steven Legg" <[email-masked]> 7/8/03 1:29:42 AM >>>

Jim,

Jim Sermersheim wrote:
> It depends on the Assertion Value for the matching rule being used.
> 
> Which brings up an issue:
> In Section 5.1 of [Syntaxes], there is a statement 
>    "Note that the AssertionValue in a SubstringFilter
>    [PROT] MUST conform to the assertion syntax of the equality
> matching
>    rule for the attribute type rather than the assertion syntax of
the
>    substrings matching rule for the attribute type.  "
> 
> This does not align with [Protocol]. Steven, is this a historical
> artifact, or did I screw the protocol up?

Well it's historical in the sense that it is analogous to
what X.500 defines, but it remains appropriate. If an AssertionValue
in a SubstringFilter were of the Substring Assertion syntax then we
would have something which contains initial, any and final substrings
embedded in something (the SubstringFilter) which also has initial,
any and final parts. That would be silly. For example, what would be
the point of the Substring Assertion syntax value "*foo" in the
initial
AssertionValue ?

Given that the AssertionValue conforms to the assertion syntax of
the equality matching rule then for most attributes an "any" with
a zero-length string would be an invalid syntax. For those where
it is valid the result depends on the way string prep deals with empty
strings (each substring is prepared in isolation by the substring
matching rules).

Regards,
Steven
 
> 
> Jim
> 
> >>> "Ramsay, Ron" <[email-masked]> 7/7/03 11:04:23 PM >>>
> Hi all,
>