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/hy
c/
> Chief Architect, OpenLDAP http://www.openldap.
org/project/
>
|
