pays@faugeres.inria.fr Tue, 26 October 1993 17:47 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11180;
26 Oct 93 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11176;
26 Oct 93 13:47 EDT
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa21487;
26 Oct 93 13:47 EDT
Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP)
id <06398-0@mhs-relay.cs.wisc.edu>; Tue, 26 Oct 1993 11:47:50 +0000
Received: from faugeres.inria.fr by cs.wisc.edu; Tue, 26 Oct 93 11:47:41 -0500
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed;
26 Oct 93 17:47:22+0100
Date: 26 Oct 93 17:47:22+0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: pays@faugeres.inria.fr, genovese@ophelia.nersc.gov
Cc: ietf-osi-x400ops@cs.wisc.edu, CXII@es.net
Message-Id: <751654042.1655.0-faugeres.inria.fr*@MHS>
Tony wrote: > > > >What is to be done (as a whole community) with terribly not conformant > > software that want to connect to GO-MHS? Or more precisely, would it be > > possible to have a common attitude with sites/domains using that type > > of software and really *endangering* the whole GO-MHS? > > > >It concernrs PRMDs (eg. using today MS-MAIL gateways) but also some ADMDs :-( > > > >As we have no direct control on what people buy and use, it is not an easy > >matter. What I suggest is to maintain and publish very widely a > >blacklist of products/providers which will give the name and version > >of the culprits along with a description of the problems. > > - this would allow customers to check this list prior to buying choices? > > - this would put a high pressure over the suppliers to fix the > > problems as soon as possible. > >being unable to solve this type of problem is in my mind a serious X.400 > >killer! > > > > Well this is a touchy subject. But how do you approach it with out > getting into any legal problems - my US legal paranoia showing. I beleave > the GO-MHS coordination service is trying to avoid this problem by > testing new connection requests before they connect. But if the service > moves to a non-coordinated service (i.e. X.500, DNS) this would be > harder to enforce. The Current SMTP world suffers from simular problems. > > At best we may be able to have a list of tested/recommended S/W. To > publish a negative list would invite problems. With ether list, who > would publish it? And who would like to say they had tested and found the > software usable/unusable? It would be nice if we did not go down the > the same path as SMTP but it is not clear how we can avoid it. > > Tony... > > Well I am no expert at all in legal issues, however my view is the following I see two tracks for justifying such a black-list . the internet society can be considered as a user association . who would prevent a user association to advise its members againt running into trouble because they just inform each others of the defects of products and services? additionaly . the same internet society is also responsible for the operation of the whole internet . as said by Stef, is there any law preventing an operator to avoid a network service falldown by advising against offending products? Conversely it seems to me more touchy to publish a list of recommended products, because we don't have to infere in the people choices as long as there is no negative impact on the whole network. cheers -- PAP