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

  •   pays