Re: CRP- Not present distinguished values

[Steven Legg <s.legg@xxxxxxxxxxxxxxxxxx>]

David,

> Steven,
> 
> Your current text states:
>    ----------------
> Each distinguished value may be in one of two 
> states, present or not present.  The not present 
> state comes about because a primitive has   
> attempted to remove the attribute value while it 
> is distinguished. The value remains pinned, i.e. 
> not present, until the value becomes non-
> distinguished by a later rename, when it will be 
> removed.
> 	--------------
> 
> I dont know how this not present state would 
> come about in reality, since it is not possible 
> in either conforming LDAP or DAP implementations 
> to remove a distinguished value except via the 
> ModifyDN operation.

The situation can arise because DSAs perform LDAP, DAP and DSP updates in
isolation from each other, and only inform each other about those updates
after the fact, according to the replication schedules. So one DSA may
allow the deletion of a value believing it to be non-distinguished whilst
another DSA has already performed a rename which makes the value
distinguished. It is only when the two DSAs exchange and reconcile their
updates that they notice an awkward problem. The solution we've opted for
is to make the value distinguished-not-present, effectively marking it for
deletion as soon as it is no longer required in the RDN.

> Historically, there was at 
> least one LDAP implementation that erroneously 
> implemented the ModifyEntry operation to allow 
> the above error condition to occur, but that 
> company agreed on the LDAP list that it was an 
> error in their implementation and would be fixed 
> in a subsequent release. Unless you know of 
> another good reason for keeping this feature, I 
> therefore question the sense of having it. (It 
> clearly is not sensible to build a replication 
> protocol to cater for bugs in people's 
> implementations, as this number is potentially 
> huge)

I'm not advocating any change to the constraints which must be satisfied
before allowing an LDAP, DAP or DSP operation to proceed locally, but in the
multi-master environment laid out by the requirements document, DSAs won't
necessarily have the complete picture when testing the constraints.
Orphaned entries are another manifestation of this effect.

Regards,
Steven

> 
> David
> 
> 
> 
> ***************************************************
> 
> David Chadwick
> IT Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351  Fax +44 161 745 8169
> Mobile +44 370 957 287
> Email D.W.Chadwick@xxxxxxxxxxxxxxxxx
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string A7OX-K3QT-JPTU
> 
> ***************************************************
>