Subject: Re: Protocol: present filter behavior

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 08 Feb 2005 14:50:07 -0700

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 <[email-masked]> 2/8/05 2:02:40 PM >>>

You lost me. How can "presence" be undefined or not implemented for an
attribute description?

John McMeeking

[email-masked] 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
>
>
>

---

From: John McMeeking <[email-masked]>
Date: Tue, 8 Feb 2005 23:03:44 -0600

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" <[email-masked]> 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
>
matches.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 09 Feb 2005 10:33:41 -0700

I'll leave it alone unless anyone else thinks the wording in 4.5.1.7.5
leads people into wondering what the prescribed behavior is.
 
Regarding the TOC, I've submitted a new revision to fix that, and to
also keep paragraphs from splitting across pages (not content changes).

Jim

>>> John McMeeking <[email-masked]> 2/8/05 10:03:44 PM >>>

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

4.5.1.7 says:

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

John McMeeking

"Jim Sermersheim" < [email-masked] > wrote on 02/08/2005 03:50:07
PM:

> >>> John McMeeking < [email-masked] > 2/8/05 2:02:40 PM >>>
>
>
>
>
matches.