Re: A tool for getting information out of the Quipu logfiles

pays@faugeres.inria.fr Sat, 13 November 1993 15:04 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02425; 13 Nov 93 10:04 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02421; 13 Nov 93 10:04 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa09786; 13 Nov 93 10:04 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.02854-0@haig.cs.ucl.ac.uk>; Sat, 13 Nov 1993 14:48:50 +0000
Received: from faugeres.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.09491-0@bells.cs.ucl.ac.uk>; Sat, 13 Nov 1993 14:48:38 +0000
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 13 Nov 93 15:48:10+0100
Date: 13 Nov 93 15:48:10+0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: S.Kille@cs.ucl.ac.uk
Subject: Re: A tool for getting information out of the Quipu logfiles
cc: osi-ds@cs.ucl.ac.uk, wright@lbl.gov
Message-ID: <753202090.23329.0-faugeres.inria.fr*@MHS>

> 
> Paul-Andre,
> 
> I'd like to comment very briefly on your "QUIPU vs X.500" comment.
> 
> The success and wide deployablity of QUIPU is due to a number of
> factors.  One is the approach to knowledge handling and replication:
>    a) A means to represent knowledge within the DIT
>    b) A protocol for replication
>    c) A very simple model of data distribution
> These were initially implementation specific, and were subsequently
> standardised for the Internet Community (RFC 1276) as they provided
> features not available in X.500(88).  A service could not be deployed
> without such features.

Agreed, we (the OIFP team) however suspect that this success
was at the price of using non-conforming features (I am not speaking
of just making proprietary choices where the '88 standard provided
nothing)
> 
> 
> There is an aspect of the current QUIPU implementation (not inherent
> to the design or to RFC 1276) which prevents it from operating when
> the higher levels of the tree do not conform to RFC 1276 (even though
> they may still conform to X.500).    
> 
> It is not that straightforward to change, and it is probably of
> marginal benefit to make an 88-oriented change as the viability of the
> current piloting relies on RFC 1276.   
> 
> 
> A correct and sensible evolution will come with the deployment of
> X.500(93) based replication.     This will be supported by future
> versions of QUIPU, which will be fully aligned to X.500(93), whilst
> still providing pragmatic features to enable straightforward
> deployment.  

Our understanding today is that, apart from including conformance to
'93, QUIPU design will have to change in a way that will
prevent it to interoperate with current versions (and in particular
the public domain version). This is related to the referals semantics
which appears today to be different from any of the different
forms defined in '88 and '93 standard.
Of course we may have misunderstood current QUIPU, though all our
studies within OIFP tend to prove we are right, and we would be happy
to be proven we are wrong.
In case we are right I think that this is severe enough
to deserve notifying every current QUIPU user of the situation
and of the drastic change that will have to occur to
accomodate for other implementations in the pilot.
It is the reason why I am insisting in getting confirmation
or proof that we are wrong from the QUIPU specialists.

The OIFP report which includes all details about what has been
identified is today under review and will be published soon.
We hopeour conclusion are wrong, but really fear it is not the case
and thus really need your detailed analysis of the problem
and of the possible way to move toward conformance and interworking
without dismantling the pilot.

regards,

-- PAP

Bruno.Koechlin@inria.fr is the guy with all in depth knowledge
of the issue and will attend the Paradise meeting Monday and Tuesday

We are still wainting for the name of the list to be used
for discussion of these complex opeartion issues and thus still
using osi-ds

> 
> 
> Steve  
> 
>