Klensin | 24 Jan 16:10 1992
Picon

Whither SMTP extensions

-----------------------------
Application message id:  95304142102991/10991 X400
Grade of Delivery:  Normal

-----------------------------
VMSmail To information: MUVAXA::MRGATE::"mci
_mta::*emsinternet::*mbx1ietf-smtp(a)dimacs.rutgers.edu::su=IETF-SMTP
"
Sender's personal name: John C Klensin

  As I assume everyone has noticed, this list has been very
quiet lately.  There have been few postings since the Santa Fe
IETF, and none since around Christmas.  I've got two blocks of
time reserved in San Diego, but am beginning to wonder if I
should unreserve them.
  There are several obvious hypotheses about the sources of the
silence.  Which is actually the case makes important differences
to where we go from here.
  (1) Everyone has been concentrating on the critical MIME /
RFC-XXXX discussions as they wound toward conclusion and should
now be ready to get back to SMTP extensions issues.
  (2) The mostly-successful conclusion of the MIME enterprise
has either succeeded in wearing everyone out or has convinced
everyone that there is no value in transport models other than
[7 bit] SMTP.  Consequently, we should quietly abandon this
effort, at least in its present form (see below).
  (3) One version of "the Prime conclusion" is correct, which is
that the people who have just been sending 8 bits over the SMTP
channel with the expectation that others will gradually get in
line intend to continue to do that.  Implicit in that may be a
(Continue reading)

Walt Daniels | 28 Jan 17:28 1992
Picon

Re: Whither SMTP extensions

I think there is little doubt that (3) is true.  There are a **large**
number of manufacturers that already just send 8-bit.  The time to have
created a fuss about compatibility with a lot of old equipment is long
past.  We have never heard from any of the manufacturers other than
Prime.  Perhaps they are all happy with the defacto 8-bit is allowed.
The preponderance of people on this list seem to be people with old
equipment.  I would guess that the preponderance of actual machines at
this point are new equipment, i.e. machines that are fully capable of
handling 8-bit if only their software did (and much of it does).

Disclaimer: The opinions above may or may not be those of IBM.  I
don't know what IBM's opinion is or even if it is capable of having a
single opinion :-).

Randall Atkinson | 28 Jan 19:04 1992
Picon
Picon

Re: Whither SMTP extensions

% Date: 28 Jan 1992 11:28:00 EST
% From: dan <at> watson.ibm.com (Walt Daniels)
% Subject: Re: Whither SMTP extensions

(stuff deleted here)

% The preponderance of people on this list seem to be people with old
% equipment.  I would guess that the preponderance of actual machines at
% this point are new equipment, i.e. machines that are fully capable of
% handling 8-bit if only their software did (and much of it does).

  Ironically, some IBM equipment gets unhappy with certain 8-bit
characters (not all 8-bit characters, but some particular ones -- no I
don't have a canonical list of the bad bit patterns) at least on the
RS/6000s running AIX that I used to use (IBM supplied MTA software).

  I think that most vendors would move to the extended SMTP if we
could just _publish_ the thing as an RFC.  DoD procurements have in
the past mandated conformance to Host Requirements and commercial
customers also have.  In the absence of a spec and the presence of a
need, the current bad behaviour is understandable if bad.  Given a
reasonable spec (the current one) meeting the same need, there will be
market pressure to migrate to conformance with the new spec.

What precisely stands in the way of publishing ESMTP in its current form ?

  Ran
  atkinson <at> itd.nrl.navy.mil

(Continue reading)

Dave Crocker | 28 Jan 20:23 1992
Picon

Re: Whither SMTP extensions

Dan,

I'll try to speak up, a bit, as there is quite a bit of noise at the
moment, mostly from the crowd issuing a large sigh at the current
state of affairs.

I hope that folks don't seriously think that limited hardware is,
anymore at least, the issue about 8-bit.  At this point, compatability
among software would seem the more likely concern.  And I hope that
folks don't think that de facto use of 8-bit is without its
difficulties.  

When this was discussed, over the various IETF meetings during the
past year, it was pretty clear that random 8-bit mail causes problems
in many environments and that simply ignoring the issue would NOT make
it go away.

Further, solving the SMTP limitation doesn't get 8-bit email out as far
as it needs to go, since the "Internet" email world includes many other
protocols.  That is the reason for the heavy effort at the RFC822 level.
(NO, I'm not saying that fixing SMTP is wrong, simply that the scope of
its effect needs to be appreciated.)

Another note for the lazy fare (err, laisser faire) 8-bit users:  It
is beginning to feel as if interest in specifying an EMail Requirements
doc is mounting, so that there might come to be a stronger frame of
reference for asserting conformance.

Dave

(Continue reading)

Dave Crocker | 28 Jan 20:31 1992
Picon

Re: Whither SMTP extensions


    What precisely stands in the way of publishing ESMTP in its current form ?

I left out one minor item from my previous note:  A major concern in
previous discussions was formulating aplan that would support the
switchover to 8-bit and use of a hybrid email service (some 7-bit and some
8-bit.)  I view this as a non-trivial problem.

Dave

Randall Atkinson | 28 Jan 22:13 1992
Picon
Picon

Re: Whither SMTP extensions

Dave,

  It seems to me that to have interoperability of differing SMTP
transport widths, the 8-bit transports would need to know how to
downgrade their 8-bit data into 7-bit MIME compatible data correctly.
Knowing when to downgrade is mostly a function of negotiating 8-bit
transport and so is handled by the current draft.

  The main assumption of that solution is that folks will be able to
handle such MIME format mail.  While Nathaniel has done an outstanding
job of providing patches for almost everything to add MIME support, I
don't know that MIME compliance is really enforceable.  Certainly no
one can enforce implementation of display hardware capable of handling
all characters.

  The thing that bothers me is that if we wait for MIME compliance to
become more universal, we are really saying that the "just send 8-bit"
situation is tolerable in the mean time (I don't believe that is true)
or that we can convince folks already using the "just send 8-bit"
approach to cease and desist (Prime has already said they will
continue regardless).

  Given several undesirable alternatives, maybe the best approach
would be to add some text in either the ESMTP spec or a parallel RFC
saying that 8-bit MTAs should downgrade to 7-bit MIME when appropriate
(i.e. negotiation for 8-bit data fails).  Note that this requirement
is really more appropriate for a Mail Requirements RFC (IMHO).

  Doing nothing is the same as saying the "just send 8-bit approach"
is acceptable (de facto).  
(Continue reading)

Einar Stefferud | 28 Jan 21:33 1992

Re: Whither SMTP extensions

Hi Walt -- It is interesting to contemplate just when the installed
base of older systems, many of which are now unsupported for many
reasons, deserve to be declared "an insignifcant minority" to justify
declaring that they are broken, even though they "still "conform to
the standing specification".

It is also interesting to contemplate when it is OK to just change a
srtanding specification, or extend it in such a way that the change
breaks the standing specification.

Let's see nopw.  IP is running out of address space.  How about lets
some of us just start using longer addresses?  OH, we need IETF and
IAB agremetns don't we?  Well, lets just get them, and get on with it
now.

My observation is that it depends greatly upon whose ox is about to be
gored...  Yours... Or mine...  Hers... Or His...    Cheers...\Stef

Dave Crocker | 29 Jan 01:31 1992
Picon

Re: Whither SMTP extensions

Ran,

I don't think it's that simple.

For example, the current SMTP extension proposal tells you that you
need 8-bit (or 7-bit) at the time you wish to cross the net.  My own
experience, and that of others, suggests that that is a very poor time
to step away from making a transmissions, in or to do a conversion.
It kills system aggregate performance.

To get reasonable efficiency, the conversion needs to take place before
attempting to open the cross-net connection, so that the transfer
phase can do transfer, rather than non-deterministic waiting.

The primary, real-world example of the problem is having the mail
server expand a mail list reference in real time, during the posting
from the net, prior to giving the final OK.  It turns out that senders
often time out while waiting.

Dave

Randall Atkinson | 29 Jan 01:50 1992
Picon
Picon

SMTP performance


Dave's comments all seem quite right to me.  I had overlooked
the issue that he raises and his analysis seems reasonable to
me.

This rather leaves me in a quandry.  Anyone having insight
please do speak up...

Ran
atkinson <at> itd.nrl.navy.mil

Dave Crocker | 29 Jan 06:46 1992
Picon

Re: SMTP performance


    This rather leaves me in a quandry.  Anyone having insight
    please do speak up...

I hesitate to suggest this, but what about adding info to the
domain name service, to indicate the type of smtp support that is
available?

Dave


Gmane