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/