[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3707) An unknown attribute in presence filter evaluates to (?=false) instead of (?=undefined)
At 11:43 PM 5/5/2005, ando@sys-net.it wrote:
>Kurt@OpenLDAP.org wrote:
>
>>At 02:51 AM 5/5/2005, ando@sys-net.it wrote:
>>
>>
>>>Full_Name: Pierangelo Masarati
>>>Version: HEAD/2.3/2.2
>>>OS: Linux
>>>URL: ftp://ftp.openldap.org/incoming/
>>>Submission from: (NULL) (131.175.154.56)
>>>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;
That will work until someone defines an attribute called "undefined".
>let's say "(1.1=*)" vs. "(1.1=something)". I
>missed that bit in RFC2251, but I suspected a rationale behind the
>current implementation.
>
>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.
(&) and (|) are, with draft-zeilenga-ldap-t-f, valid filter
strings. But what filter2bv produces is not a filter string,
it's a filter diagnostic string.
>I can work this issue around as in slapo-rwm and back-meta, but this
>would require yet another filter2bv conversion.
For back-ldap/back-meta, it seems one really needs access to
filter encoding as it appeared in the request so that it can
be forwarded intact (it would be nice if we had an ldap_search()
call where the filter was passed as BER value). But given
that filter massaging would be a nice feature, you actually
need both access to filter encoding and another filter2bv
function.
>p.
>
>
> SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497