Re: Protocol: present filter behavior

[John McMeeking <jmcmeek@us.ibm.com>]

So you are thinking of something like (hassubordinates=*)?

- (hassubordinates=*):   shouldn't be true if server can't evaluate it
- (!(hassubordinates=*)):  shouldn't be true if the server can't evaluate
it

That says undefined is right outcome.

4.5.1.7 says:
   A filter item evaluates to Undefined when the server would not be
   able to determine whether the assertion value matches an entry.

I believe that applies to all filters, so I think the draft already
addresses this case and nothing further needs to be added.

BTW, the entire section on search is missing from the TOC in the published
draft.


John  McMeeking


"Jim Sermersheim" <jimse@novell.com> wrote on 02/08/2005 03:50:07 PM:

> One specific example is where the DSA supports the notion of dynamic
> or synthetic attributes. These don't actually exist in the database,
> rather they are generated as entries are returned or as those
> attributes are queried. Some servers may, for some attributes, not
> implement a presence rule.
>
> Jim
>
> >>> John McMeeking <jmcmeek@us.ibm.com> 2/8/05 2:02:40 PM >>>
>
>
>
>
> You lost me. How can "presence" be undefined or not implemented for an
> attribute description?
>
> John McMeeking
>
>
> owner-ietf-ldapbis@OpenLDAP.org wrote on 02/08/2005 01:11:41 PM:
>
> > In Protocol Section 4.5.1.7.5 (SearchRequest.filter.present) it says
> > that a present match evaluates to "FALSE ... including a presence
> > test with an unrecognized attribute description".
> >
> > It doesn't mention the case where the attribute description is
> > recognized, but the present match is not implemented for it.
> >
> > Section 4.5.1.7 indicates that this would result in an "Undefined"
> > filter item, but I'm not sure if this is the intent for present
matches.
> >
> > So, two questions: 1) Is this case treated as Undefined? (My read
> > says yes). 2) Does this need to be clarified in the I-D?
> >
> > Jim
> >
> >
> >