[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Another Persistent Search question



At 10:45 AM 2/6/2001 -0500, Mark C Smith wrote:
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.

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

-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
>
> >>> Mark Smith <mcs@netscape.com> 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

==============================================
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