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

pays@faugeres.inria.fr Thu, 18 November 1993 19:31 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10564; 18 Nov 93 14:31 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10560; 18 Nov 93 14:31 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa18789; 18 Nov 93 14:31 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.04236-0@haig.cs.ucl.ac.uk>; Thu, 18 Nov 1993 18:54:21 +0000
Received: from faugeres.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.08350-0@bells.cs.ucl.ac.uk>; Thu, 18 Nov 1993 18:54:02 +0000
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 18 Nov 93 19:51:08+0100
Date: 18 Nov 93 19:51:08+0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: pays@faugeres.inria.fr, c.robbins@nexor.co.uk
Subject: Re: Rep (2) : QUIPU vs X.500 (was: A tool for...)
cc: Woermann@osi.e3x.fr, osi-ds@cs.ucl.ac.uk, tim@terminator.rs.itd.umich.edu, jpslone@mmc.com
Message-ID: <753648668.28130.0-faugeres.inria.fr*@MHS>

> 
> Thanks for this clarification Paul.  This is indeed the case I though you were
> referring to.  I will confirm that in my book this is simply a bug
> in QUIPU, it is not a major architecture problem.  I am working on a fix,
> as you know, I have already given the OFIP an attempted fix, but this did 
> not seem to resolve the problem

We are waiting for this fix, though we are intrigued by the fact
that Steve pretends this requires major modifications.
Anyhow let's wait and see, but we are interested in knowing
how you can avoid the problems of having either 2 masters
or no master and 2 copies for the same entry.


> 
>    >   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)
> 
> QUIPU should be able to generate a reference of any type you require.
> By default subordinate references are used, but NSSRs can be generated if need be,
> however, QUIPU will not use NSSRs itself, but simply pass them to the requestor
> in a reference.
> Cross references can also be generated (and used) if need be.

probably several issues are here.

QUIPU does not really handle subordinate references BUT nevertheless
  generates that type of reference in the PDUs.


   >			 
   >			
   >			
   >		     /
   >		    /
   >		   S1     	<- QUIPU	DQ
   >		  / \      
   >		 /   \
   >	       S11    S12	<- other DSA
   >	     /  |  \   | \
   >	    /   |   \

Let my try to explain a bit.

  What (as far as we understood it) QUIPU DQ knows is the fact that
	it masters entry S1, but it has not properly a subordinate 
	reference, it just knows that subordinates of S1 if any
	are held by DNQ
  
  If for any reason for a request about ...S1,S1i DQ returns 
	a reference and does not chain, this is tagged as subordinate.
	This is not correct as, academicaly may be, DQ does not
	have this subordinate reference, but more a NSSR.
	If S1i does not exist then the requestor is faced with
	a reference internal error instead of a normal "name error".
	


Additionaly Bruno has  some other things to say about that, about
the target-object setting and about other cases involving referals.
This will be submitted in the next days, but in the closed
paradise-partners list until things are more clear.

-- PAP