Re: My greatest fear

John C Klensin <KLENSIN@infoods.mit.edu> Fri, 23 August 1991 21:35 UTC

Received: from dimacs.rutgers.edu by NRI.NRI.Reston.VA.US id aa24734; 23 Aug 91 17:35 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09263; Fri, 23 Aug 91 16:56:25 EDT
Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09256; Fri, 23 Aug 91 16:56:20 EDT
Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #11057) id <01G9Q4O2SB720005AD@INFOODS.MIT.EDU>; Fri, 23 Aug 1991 16:55 EDT
Date: Fri, 23 Aug 1991 16:55:49 -0400
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: My greatest fear
In-Reply-To: <9108231937.AA01859@ftp.com>
To: ljm@ftp.com
Cc: MRC@cac.washington.edu, ietf-smtp@dimacs.rutgers.edu
Message-Id: <682980949.467432.KLENSIN@INFOODS.MIT.EDU>
X-Envelope-To: ietf-smtp@dimacs.rutgers.edu
Mail-System-Version: <VAX-MM(284)+TOPSLIB(151)+PMDF(4.0)@INFOODS.MIT.EDU>
Status: O

>Don't be obtuse.  Your greatest fear started out as, 'It is possible to build
>a gateway that encodes *every* message that it forwards.'  Why do you think
>folk will do so?

Leo,
  I'll let Mark answer for himself, because his answer will certainly be 
different.  But *my* answer, reinforcing Stef's recent posting, is that 
we have ample evidence that there are "things" out there who declare 
themselves "gateways" on the slightest provocation.  They then do all
sorts of things to mail in the name of "purity" and "improvement" that I 
consider downright hostile.  Because they think they are improving the 
message flow and eliminating things that are undesirable, it has proven 
impossible to get rid of, or even discourage, them.
  *My* greatest fear is that we will encourage those folks to make even 
more of a mess and that we will encourage others to join their camp.  
And in my rather uncomfortable "user" perspective, that issue completely 
dominates considerations of performance and efficiency: if we can't 
assure accurate delivery, I don't much care what else does or doesn't 
happen.
  So, I think people will build things that don't interpret the rules 
the way you, or Mark, or I, would wish because I think we have seen a 
lot of things already that interpret the rules differently from the ways 
we would wish.  And because it is exactly *those* "things* that we are 
talking about having modified to handle this new stuff.
  If we are going to do conversions mid-flight, then I want to see those 
conversions be as narrowly defined, as foolproof, as discretion-free as 
possible.  Otherwise, I think experience tells us that we are going to 
have a mess, whether in the form of someone encoding everything that 
they see, or in the form of someone encoding RFC-XXXX into RFC1154 
(because they like it better), or in the form of someone stripping the 
internal headers, or in the form of someone trying to second-guess the 
encodings used and improve on them.  I think all of those options are 
bad news and really don't prefer one to another.
  Ideally, if we really are going to insist on doing conversions 
mid-flight, I also want to either explicitly assign that authority to 
relays (which makes me very unhappy), or to create a new and very 
restricted gateway category that can do only these conversions, or to 
see a way of explicitly authorizing conversions and designating the 
converter.  I'd hate to see this turn into another excuse for, e.g., "I 
have to fix up the 8->7 part, let's see what else I can 'fix' around 
here while I'm at it".

   regards,
     john