------- Blind-Carbon-Copy
To: David Robinson <DRB(_at_)relay(_dot_)prime(_dot_)com>
cc: IETF SMTP list <IETF-SMTP(_at_)dimacs(_dot_)rutgers(_dot_)edu>
Subject: Re: Why We Disagree So Much... A Thought
In-reply-to: 10 Apr 91 22:20:24 EDT.
<9104110220(_dot_)AA04058(_at_)rutgers(_dot_)edu>
Cc: "Einar Stefferud" <stef(_at_)ics(_dot_)uci(_dot_)edu>
Date: Wed, 10 Apr 91 22:04:25 -0700
Message-ID: <29993(_dot_)671346265(_at_)ics(_dot_)uci(_dot_)edu>
From: "Einar Stefferud" <stef(_at_)ics(_dot_)uci(_dot_)edu>
I am only sending this to the ietf-smtp list, because us ietf-822 people
do not want to be bothered any more by this damn argument! I suggest
that you keep your arguement about it to your own side of the house! We
don't want to hear about it! Until now, life was actully becoming sort
of pleasant on the ietf-822 side of the house!
Mr Chairman, will you please rule this discussion out of order on the
ietf-822 side ot the house! Best...\Stef
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
David --
NO! I think the cause is orthogonal to your continuum.
It is precisely because of the large immobile installed base that is
perceived as very likely to never be upgraded under any conditions, that
causes me, and I belive many others to want to do nothing to SMTP
(RFC821) that will break old systems.
The whole idea of just declaring older installed systems broken in the
effort to move forward is just a very very bad idea, and we should put
it away forever in the context of SMTP(RFC821). You can carry 8-bit
stuff in 7-bit SMTP if you want to, so you are only making a very small
gain in badwidth efficiency anyway. (But we have been over this
endlessly, so I will not repeat any more of it.)
If you want to go ahead anyway, then declare that you are going to
define a new internet mail standard (to do what X.400 does, and more if
you can) and run it as a 3rd alternative MTA system, with gateways
between it and RFC821/822 systems to protect RFC821/822 systems from
any and all ill effects. All you need to do is define gateways between
your RFC-newmta systems and RFC821/822 systems and X.400 MTA systems.
Lets get the real issue out on the table here. I always say that it is
much easier to hold an autopsy if you have a corpse on the table!
Some want a new INTERNET RFC STANDARD blessed MTA system to do 8-bit
mail (at minimum), and they don't want to use X.400 to do it, so they
want to convert an existing installed base (7bit RFC821) into something
new. They don't mind that it breaks lots of mail systems that lots of
people are using in production mode, with no desire to fix it, cause it
ain't broke. They just want to blatantly declare all old stuff "broken,
when it is not" and go their merry way.
Well, I wonder how they would react if we were on opposite sides of this
same question about just declaring my tools broken when they are not.
My response, and yours to this challenge is "Just Say NO!".
I don't know why they (the "we want a new MTA Protocol" people) don't
want to just do something entirely new that only works among consenting
parties that implement their "something new", with firewalls around it
to protect the non-users.
For myself, having already seen what happens when we have gateways among
three mail system realms (RFC822/X.400/PROFS), I don't want to promote
this "3 body problem" as a solution, but I will not stand in the way of
folk who are really convinced that they have a valuable idea for how to
really do mail right (e.g., do the MTA protocol right, for the last
time, of course).
I just don't want to contribute to it, and I don't want it to damage my
currently working installed base. And I don't want it to get in the
way of the other work that we need to get done.
This is what the problem is all about! Best...\Stef
------- End of Blind-Carbon-Copy