Re: A new port should not use smtp, it should use RPC

[Ittai Hershman <ittai@xxxxxxxxxxxxxxxxxxxxx>]

    If we can define an extended-SMTP that is a superset of
    RFC821-SMTP, then we don't need to run two different mail
    protocols on every host, and present-day SMTP implementations
    should be able to send messages via the extended-SMTP
    implementations without any problems.  
    
This list has been going around in circles because a significant
number of well-respected participants claim that this is simply
not possible.  There seem to be some new participants who have
not read the history of this (damned :-) conversation, so the
following is a summary of where we've been and were I hope we go.

It turns out that most of the desired extensions can be handled by
transforming the data (through various means) into 7 bit ASCII and
adding some new headers to RFC-822.  Therefore this group was divided
into two: IETF-SMTP and IETF-822.  Borenstein and Freed have a draft
RFC which is being discussed in IETF-822 which will (eventually)
provide a solution which will not require any changes to SMTP.

Given that most of the desired extensions can be handled without
touching RFC-821 -- SMTP itself -- many people feel that nothing
further should be done.  Others, in particular the non-English Western
Europeans, are demanding that SMTP be changed to recognize a de-facto
enhancement already in the field -- namely officially sanctioning
consenting hosts to transport 8-bit character data in SMTP.  This has
been forcefully rejected by the above-mentioned significant number of
well-respected participants because, they argue, it would cause
interoperability problems.

This has brought us back to root one.  Given the requirement of
interoperability with the existing SMTP world, many people have
essentially been admitting that no change to SMTP is possible.

Therefore, we should (and are) hammering out the IETF-822 RFC.  This
will, once again, allow for most of the desired enhancements (with
some pain for the Europeans), but will cause NO interoperability
problems.  This effort appears to be reaching consensus, and we will
all be happier.

The question of a charter for this group (IETF-SMTP) has been raised,
and we can't even agree on that, let alone get any work done.  I say
we should broaden the scope of the group and be a little more future
oriented.  I argue that any change to SMTP will indeed cause grief, as
has been discussed ad-nauseum, and therefore it is absurd to make
immediate interoperability with the current SMTP implementations a
goal.  I further argue, that once you break immediate
interoperability, you better make the headache worthwhile.  Therefore,
the charter of this group should be changed such that those interested
parties can discuss what we would really like to see Internet e-mail
do, and work out an RFC and some code to document and demonstrate it.

I am reminded of the BOF at the 1988 Interop which sat down in
someone's hotel suite (I don't remember whose now) to discuss serial
line IP.  We started with SLIP and a few hours later the seeds of PPP
(then SOS: Son of Slip) had been formed.  It took two years to then
get it done, but it did get done.

We have a chance to re-invent e-mail based on a very broad set of
experiences, ideas and perspectives.  Let's agree to innovate, broaden
the charter, lengthen the time deadlines, and begin discussing these
ideas in earnest.  Greg?

-Ittai