This message was not delivered due to problems at our site. It is being resent.
The following is a copy of the message:
Received: from rutgers.edu (-:RUTGERS.EDU:-) by yonge.csri.toronto.edu via TCP
with SMTP id AA05574; Fri, 12 Jul 91 13:49:10 EDT
Received: from dimacs.rutgers.edu by rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA07917; Fri, 12 Jul 91 13:47:29 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA13931; Fri, 12 Jul 91 12:42:26 EDT
Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA13924; Fri, 12 Jul 91 12:42:22 EDT
Received: from NRI by NRI.NRI.Reston.VA.US id aa13474; 12 Jul 91 11:57 EDT
Org: Corp. for National Research Initiatives
Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject: Review and future directions
Date: Fri, 12 Jul 91 11:57:17 -0400
From: Greg Vaudreuil <gvaudre(_at_)nri(_dot_)reston(_dot_)va(_dot_)us>
Message-Id:
<9107121157(_dot_)aa13474(_at_)NRI(_dot_)NRI(_dot_)Reston(_dot_)VA(_dot_)US>
Folks,
After consulting with a few people privately, I would like to review
the work of the Simple Mail Transport Protocol Extensions working
group and propose a course of action.
Is is my firm belief that this working group does not have the luxury
of time in defining an extended SMTP protocol. In particular, several
(many?) vendors are deploying or plan to deploy software to transmit 8
bit data at the SMTP level. At this time, there is no standard for
doing this and this may cause serious interoperability problems in the
near future. Second, the issues of 7 bit and 8 bit interworking have
become #very# complex, ranging from transfer encoding conversions to
the conversion of character sets. This work is valuable and should
continue, but must be regarded as longer range in scope.
It appears that defining a "standard" gateway between 8 bit, 7 bit,
and other interesting environments is truly an experimental endevor at
this stage. This exciting interworking problem has many interesting
possible solutions, ranging from bounce to sender through specifying
per-message a complete set of conversion mechanisms permitted and many
varients between them. I would like to see the various approaches
tried and documented before we try to standardize an approach.
In any event, there are some common aspects to these solutions. 1) A
message format for sending 8 bit data over 7 bit is needed. We have
an advanced proposal in Internet-Draft
<draft-ietf-822ext-messagebodies-00.txt>. 2) We need to be able to
detect 8 bit transport and report failures to the "conversion/ failure
recovery process". We have an advanced proposal in Internet-Draft
<draft-ietf-smtpext-8bittransport-00.txt>.
I propose that these two document be finished and submitted to the IAB
as proposed standards as soon as possible. They are needed now, and
they are almost ready. The great volume of email has had it's
rewards. According to our charter, the first draft of the SMTP
extensions was to be written and posted by THIS DECEMBER!! It feels
good to be 5 months ahead of schedule. I would like to move up our
target for making proposed standards of both the message format and
the SMTP transport from March 92 to this December.
I encourage participants in this working group in a position to
experiment with existing software to begin to experiment with the SMTP
extensions to gain experience with the negotiation mechanism. I am
expecially interested in the interaction between a "new" 8 bit SMTP
agent and current "defacto" 8 bit implementations.
Many, including myself, feel that a new mail architecture, including a
standard way to handle mail between diverse environments, is urgently
needed to deal with many current interworking problems on the
Internet. While this is urgently needed, it is not near completion,
nor can the current proposals be considered more than experimental.
This effort should continue separate (but not independant) from the
the standards work to define the transport and message format.
Comments are welcome.
Greg Vaudreuil
Chairman -- Simple Mail Transport Protocol Extensions WG