[Date Prev][Date Next]
Re: (ITS#3707) An unknown attribute in presence filter evaluates to (?=false) instead of (?=undefined)
>At 02:51 AM 5/5/2005, email@example.com wrote:
>>Full_Name: Pierangelo Masarati
>>Submission from: (NULL) (126.96.36.199)
>>Submitted by: ando
>>An undefined attribute in a presence filter, e.g. "(undefined=*)", evaluates to
>>"(?=false)", while in other filters, e.g. equality "(undefined=something)" it
>>evaluates to "(?=undefined)". If there isn't any rationale behind it, I'd
>>evaluate it to "(?=undefined)" as well, at least for consistency.
>Though I disagree with the rationale behind the RFC 2251
>requirement, the rationale for this slapd(8) behavior is
>the RFC 2251 requirement.
> The present match evaluates to TRUE where there is an attribute or
> subtype of the specified attribute description present in an entry,
> and FALSE otherwise (including a presence test with an unrecognized
> attribute description.)
>I disagree as 'undefined' may be an unknown alias for a
>present attribute description.
My intention was to use "undefined" as a placeholder for an undefined
attributeDescription; let's say "(1.1=*)" vs. "(1.1=something)". I
missed that bit in RFC2251, but I suspected a rationale behind the
This is making forwarding of absolute filters by back-ldap a bit more
tricky. As such, I suggest the strings "(?=true)" and "(?=false)" in
slapd's internal filter representation be replaced by the corresponding
absoluteFilter representations "(&)" and "(|)", assuming they're simply
an internal string representation, since I didn0t find any mention of
them in <draft-zeilenga-ldap-t-f>. "(?=undefined)" and "(?=error)" do
not require modifications.
I can work this issue around as in slapo-rwm and back-meta, but this
would require yet another filter2bv conversion.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497