Subject: Re: Another Persistent Search question

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 05 Feb 2001 17:44:20 -0700

One more issue regarding the delete operation. I'd like to propose that the entry being returned due to a delete operation MAY only include the DN and no attributes. The client doesn't care about the attribute values when an entry is deleted, and in some cases the implementation work is much simpler if only the DN is to be returned.

Jim

>>> Mark Smith <[email-masked]> 2/2/01 1:44:04 PM >>>
Gordon Good wrote:
> 
> In the Netscape implementation, I'm fairly sure that an entry is only returned
> to the client if it matched the query after mods were applied.
> 
> So, for example, if the psearch used a filter of "foo=bar" and the modification
> changes the "foo" attribute from "bar" to "baz" then no entry would be returned.
> 
> However, for the delete operation, the entry that was deleted is returned.
> 
> To summarize:
> If optype is ADD, a result is returned to the client iff the new entry matches the psearch criteria
> If optype is MODIFY, a result is returned to the client iff the entry matches the psearch criteria after modifications have been applied
> If optype is DELETE, a result is returned to the client iff the entry matches the psearch criteria prior to removal
> If optype is MODRDN, a result is returned to the client iff the entry matches the psearch criteria after being renamed
> 
> That's from memory, but I'm pretty certain it reflects reality.

Yes, I agree.  This should be documented in the psearch document so
people who choose to use it or implement it do so the same way.  I will
add this to the psearch draft soon.

> 
> There's an inconsistency there: you can detect when an entry leaves the result
> set for delete operations, but not for modify or modrdn operations. I'm not sure
> it's worth fixing that in the psearch document, but it should definitely be
> addressed by the LCUP work (and I'll bet LCUP addresses this already).

It is being looked at.  See section 5.1 of
http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcup-02.txt 

-- 
Mark Smith
Directory Product Development / Netscape

---

From: [email-masked] (Mark C Smith)
Date: Tue, 06 Feb 2001 10:45:56 -0500

Actually, in my experience a lot of clients DO care about attribute
values other than the DN.  Why?  Because if they are using the change
notification to keep some "cache" or related data store up to date, they
may use something other than the DN to locate the related information in
their cache.  E.g., a mail server may use the mail attribute.

-Mark Smith
 Netscape

Jim Sermersheim wrote:
> 
> One more issue regarding the delete operation. I'd like to propose that the entry
> being returned due to a delete operation MAY only include the DN and no attributes.
> The client doesn't care about the attribute values when an entry is deleted, and
> in some cases the implementation work is much simpler if only the DN is to be returned.
> 
> Jim
>

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 06 Feb 2001 08:25:15 -0800

>their cache.  E.g., a mail server may use the mail attribute.

I agree.  It has been my experience that often the naming attribute is not 
what the LDAP enabled application is using internally to uniquely identify 
users.  As Mark suggests, it is often the email address.

Bruce

> > > If optype is MODIFY, a result is returned to the client iff the entry 
> matches the psearch criteria after modifications have been applied
> > > If optype is DELETE, a result is returned to the client iff the entry 
> matches the psearch criteria prior to removal
> > > If optype is MODRDN, a result is returned to the client iff the entry 
> matches the psearch criteria after being renamed
> > >

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories: 
http://www.phptr.com/ptrbooks/ptr_0139744525.html