ITS#4809 reports that when replicating modrdn via slurpd, operational attributes don't get replicated. This appears to be intrinsically caused by the definition of the modrdn operation, which, unlike the modify and add operations, doesn't contemplate the possibility to add/modify attributes other than the naming ones. So add/modify can be easily exploited for replication by adding/modifying the write-related operational attributes during replication, while modrdn can't.
Assuming there's any intention to fix slurpd replication until slurpd is dismissed, we need to find a means to attach modification of write-related operational attributes to a modrdn operation, to complement the modrdn operation itself.
The proposed solution consists in explicitly modifying the necessary (operational) attributes by means of an additional modify operation that is attached to modrdn. This may be occasionally useful regardless of slurpd replication, which makes it more appealing for OpenLDAP developers, so that the required effort wouldn't be just wasted by slurpd dismissal.
The additional modify could be wrapped into a control's value, and that control might be the "relax" control itself, so that the original operation, augmented by the optional modify, would need to succeed as a whole or abort, extending the capabilities of the "relax" control by allowing extra modifications to be added, in order to preserve the integrity of the object after the operation.
Comments? p.