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

Sylvain Langlois <Sylvain.Langlois@der.edf.fr> Tue, 16 November 1993 13:04 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01776; 16 Nov 93 8:04 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01772; 16 Nov 93 8:04 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa05517; 16 Nov 93 8:04 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.04316-0@haig.cs.ucl.ac.uk>; Tue, 16 Nov 1993 12:55:59 +0000
Received: from chenas.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.10150-0@bells.cs.ucl.ac.uk>; Tue, 16 Nov 1993 12:55:26 +0000
Received: from edf.edf.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA08238; Tue, 16 Nov 1993 13:52:58 +0100 (MET)
Received: from cli53an.der.edf.fr.YP.imaicitpt (cli53an.der.edf.fr) by edf.edf.fr with SMTP id AA08316 (5.65c8/IDA-1.4.4); Tue, 16 Nov 1993 13:53:05 GMT
Received: from cli53an.der.edf.fr by cli53an.der.edf.fr.YP.imaicitpt (4.1/SMI-4.1) id AA22993; Tue, 16 Nov 93 13:53:28 GMT
To: pays@faugeres.inria.fr
Cc: Woermann@osi.e3x.fr, Steve Kille <S.Kille@isode.com>, osi-ds@cs.ucl.ac.uk
Subject: Re: Rep (2) : QUIPU vs X.500 (was: A tool for...)
In-Reply-To: pays@faugeres.inria.fr's message of 16 Nov 1993 11:32:55 +0100. <753445975.24278.0-faugeres.inria.fr*@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 16 Nov 1993 13:53:28 +0000
Message-Id: <22992.753458008@cli53an.der.edf.fr>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Sylvain Langlois <Sylvain.Langlois@der.edf.fr>

> I don't want to get into a dispute, but then I want that it is stated clearly
> that either
>    the Paradise pilot is a Quipu pilot 
> 	(because the statement that RFC1276 is the only key is FALSE)
>    or it is an X.500 pilot
> 	(then QUIPU should be fixed asap, because it is not suited
> 	as such for what it is been used for)
> so that each one will decide on its own.

I'm neither trying to support fully (blindly?)  Steve  comments nor to
express the  IC view, but  what  I understood from  Steve's reply  was
not that RFC-1276 was the  only key to the probleme. I understood that
is was  the  only proposal  widely deployed today.  RFC-1276  has some
serious  limitations (bugs?) which may or  may  not  be  fixed  sooner
or  later (depending on various considerations).  The only fact I see,
from  an  operationnal  standpoint,   is  that  products  implementing
RFC-1276  today  provide  a  mechanism  solving  current  operationnal
problems. This mechanism is not perfect: I  would  guess  that most of
the  people in charge of  running DSAs  today  are  waiting for a real
interoperable standard solution to be available  in terms of  "running
code", but until then these  people  can use  RFC-1276  as an  interim
solution in order to cure a real operationnal pain.  

Sylvain
----------------
Sylvain.Langlois@der.edf.fr