Re: ITS#5040, operational attribute updates

[Kurt Zeilenga <kurt@OpenLDAP.org>]

On Jul 23, 2007, at 7:37 PM, Howard Chu wrote:

> I don't see anything in X.501/X.511 etc to imply there's any  
> difference - should modifyTimeStamp be left untouched when an  
> update only changes an entry's operational attributes, or should  
> all modifications, regardless of how they were initiated or what  
> they touch, update the modifyTimeStamp?

Depends on what's getting modified and why.

In general, any change to the DIT object should result in a update of  
modifyTimestamp.  This is necessary for synchronization*
purposes.   That is, any change to a userApplications attribute  
certainly should result to a modifyTimestamp update.

Changes to certain attributes in DSA management planes need not, or  
even should not, result in an update of modifyTimestamp.

For instance, an update of a subentry to make it apply to different  
set of entries should only cause the subentries
modifyTimestamp to be updated.  The changes to entries' subentry (or  
subentries) pointers do not cause the entries
stamps to be changed.

Basically, one LDAP operation should only ever cause one  
modifyTimestamp to be updated.  For instance, a rename of a
subtree causes only the stamp in the most superior entry to be  
updated.  Stamps in the subordinate entries are left
as is.

Regarding refint.  One should view these updates as coming from a  
user application embedded in the DSA, not from the
directory service.  That is, the updates are not made as part of the  
directory update model, but part of an application
update model.  That fact that its coded in the DSA is irrelevant.   
That is, if a DUA renames an object and refint updates
another object's member attribute, the modifyTimestamp of both  
objects should be updated.  One as part of the first
userApplications update, one part of the refint userApplication  
update.  Not that, for synchronization*, this is required.


* stamps should be maintained such that a DUA can detect what's  
changed in the DIT by examining timestamps.  This aspect
of stamps should be considered in determining whether or not the  
stamps should or should not be updated.



> Possible alternatives:
>   1) only update modifyTimeStamp in response to actual Modify (and  
> MoDDN) requests from a client. (thus, not for any internally  
> generated updates.)
>   2) only update modifyTimeStamp if user attributes are changed.
>   3) always update modifyTimeStamp
> --
>   -- Howard Chu
>   Chief Architect, Symas Corp.  http://www.symas.com
>   Director, Highland Sun        http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP     http://www.openldap.org/project/