Re: Rep (2) : QUIPU vs X.500 (was: A tool for...)

[[e-mail]]

I have to apologize for the very bad phrasing and wording of
what I wanted to state, this has lead to many mis-understandings.
Let me try to be clearer and more correct.


> 
> > A major interworking problem is the fact that QUIPU insists
> > on the fact that the master entry of a relative root of a subtree
> > is held by a different server than its direct subordinates.
> 
> Perhaps I'm misreading your analysis, but the way I read it this isn't quite 
> true, although it is close to something I perceive as a potential problem.  
> QUIPU does allow entries and their subordinates to be held in the same server 
> (DSA).  For any "quipuNonLeafObject" entry, QUIPU requires a "masterDSA" 
> attribute which contains the DN of the DSA holding its subordinates.  This may 
> or may not be the DSA holding the entry itself.
> 

Excuse me for the above statement, it was written too fast and the wording
is so poor that especially out of its context it is completely wrong.

What I meant was  (using an example):


			  /
			 /
			A
		      /   \
		     /     \
		   S1       S2
		  / \      /  \
		 /   \
	       S11    S12
	     /  |  \   | \
	    /   |   \

   I have an entry A with 2 subordinates (also subtrees) managed by DSA DS0
   I need to have subtree  S1  (with S11, S12 ...) managed by a different
	DSA  DS1 than the one holding A
   Same requirement for subtree S2 and DS2

   If DS0 is a non-QUIPU, DS0 
       considers that S1 is mastered by DS1 (S2 by DS2)
       and optionaly may hold a slave copy of S1
    If DS1 is a non-QUIPU then no problem
    If DS1 is a QUIPU, DS1 believes that the master entry for S1 it holds
	is a copy, and that DS0 holds the master.
	-> there is no master for this entry S1!!!

     [[ Here come my statement: this QUIPU insists on thinking that
	the entry S1 (relative root of this subtree) is held by
	another DSA: DS0]]

   Conversely
	If DS0 is a QUIPU
		DS0 has to pretend to master entry S2 
        while it is in fact mastered by DS2 if DS2 is a non-QUIPU
	-> we have 2 masters for entry S2!!!

> 
> What gets sticky is the issue of where the root of a subtree is actually 
> mastered, especially when QUIPU is only on one side of the equation.  QUIPU DSAs
> hold the master in the DSA containing all the siblings of that root (regardless 
> of which QUIPU DSA holds the next level down in the subtree).  X.500 describes 
> it differently -- the root of a subtree is held in the DSA holding the 
> subordinate entries, and the root's superior holds a subordinate reference 
> (which may or may not be an NSSR).

That is exactly what I so badly tried to express

> 
> Both RFC 1276 and the QUIPU documentation discuss a concept called "spot 
> shadowing" to handle what sounds like this kind of case (presumably for 
> interaction with non-QUIPU DSAs lower in the DIT).  In the spot shadowing 
> concept, the master of the entry can be held where X.500 describes it, and the 
> QUIPU EDB holding the siblings of that entry (even if it's a "master" EDB) can 
> hold a shadow (slave) copy of the entry.
> 
> What I haven't seen described anywhere is the case in which a non-QUIPU DSA is 
> higher in the tree than a QUIPU DSA.  It would seem that the QUIPU DSA would 
> expect the superior DSA to hold the master copy of its naming context.  If 
> anyone knows, I'd appreciate some clarification.  It's not hard to trick QUIPU 
> with bogus slave EDBs for superior entries, but how well it would interoperate 
> may be another matter altogether.

And here we come to the point.
What we have observed and what I was asking QUIPU experts to
confirm or infirm is that we have the feeling that QUIPU,
because of its EDB model
   is able to interwork when chaining is used though
	more careful testing is still needed because we have found
	bugs in too many implentations (QUIPU included)
   is NOT able to interwork properly when chaining is not used
	and references are returned. It seems that QUIPU, at best,
	implements only part of the reference types proposed by the standard.
	(BUT I repeat this is an assumption based on logs and PDU analysis, not
	on any knowledge of QUIPU internals and architecture)


> 
> I haven't experimented with either of these perspectives at all, so I can't 
> share any experience.  And since I wasn't one of QUIPU's developers, I don't 
> have any insight from that point of view.  Regardless, I hope this helps.
> 
>   -- Skip Slone
> 
> 

Thanks Skip

You helped and push me to present a much more precise description
of our perception of the issue.


regards

-- PAP

> 
> 
> 
> 
>