SMTP and new 822 interworking

[Greg Vaudreuil <gvaudre@xxxxxxxxxxxxxxxx>]

DRAFT                                    	   Greg Vaudreuil/CNRI
                                      		   February 20, 1991

	    A Proposal for 8 bit and 7 bit Interworking


Abstract:
---------

The goals of passing 8 bit mail via 7 unmodified bit SMTP systems is
possible.  However, when passing 8 bit mail between two 8 bit SMTP
systems there is an efficiency loss.  The main argument for upgrading
SMTP to 8 bits is to increase efficiency between two 8 bit speakers.
Given this, any conversion from 8 bit to 7 bit that requires a lot of
resources, either programing or CPU cycles, may not be optimal.

This document is an overview containing a proposal for the efficient
exchange of 8 bit mail in a heterogeneous system of 8 bit and 7 bit
capable mailers.

This proposal involves mandatory changes to the RFC 822 message
format, and optional changes to the SMTP specification.  It is
recognized that 7 bit mail transport systems will continue to exist
for the foreseeable future and need to interwork with and "new" mail
system.

The Proposal:
-------------

Interworking between 7 bit and 8 bit systems requires a planned
interaction between user agents (UA's) and the mail transport
protocol. It is recognized that a user agent does not have a-priori
information about a receiving hosts capabilities.

The fundamental changes this proposal makes is to define encodings in
a nested fashion, with the outermost level containing the translation
between 8 bit and 7 bit.  The final level of encoding can be done
either by a user agent configured to work with a local 7 bit SMTP
transport agent, or by a modified 8 bit SMTP agent when communicating
with an older 7 bit SMTP agent.

If the encodings are indicated by subsequent headers prepended to the
message, this same encoding can be done by a "new" smtp server
transparent to the UA.  A UA receiving a translated message may never
know that is was modified in flight rather than generated under a new
UA.

The Encoding Scheme:
--------------------

Encodings nested, with the form:

     Encoding: 8to7  ; timestamp
     Encoding: Compress; timestamp 
     Encoding: Word Perfect ; timestamp

The encodings are listed with the outermost encoding added first.  The
encodings are timestamped so their order can be reconstructed by a
user agent in the case where a non-conformant system mucks around with
the message.

An SMTP agent translating from 8 bit to 7 bits must add a header line
indicating the translation. 

Note: A modified version of this proposal can be made to allow
multiple encoding types. I'm explicitly not making a choice as to the
multi-part message delimiter specification. (RFC 1154 vs RFC 934)

Requirements for the Outermost 8bit to 7bit Encoding 
------------------------------------------------------

This scheme requires that the outermost 8 bit to 7 bit encoding have the
following properties.  This does not imply that other encoding types
cannot be used inside the body of the message.

1) ASCII text must be preserved by the conversion.  This will preserve
the machine-readability of the ascii parts of the headers in the
translations process, as well as render the converted document
somewhat readable by a old-style ascii only user-agent.

2) ??


The System Illustrated:
------------------------
	
The following four situations may arise:

1) If two hosts speak modified 8 bit SMTP, and a sender sends a 8 bit
   message, the sender has two choices.  They can either encode the
   message into 7 bits, and the receiver can decode it back to 8 bits, or
   the can send the message using efficient 8 bit transmission.

2) If two hosts speak only 7 bit, and a UA needs to send an 8 bit 
   message, they must encode the message before sending it to the 7 bit
   SMTP.  The 7 bit SMTP will then exchange the mail as normal 7 bit
   mail, and the receiving UA will decode the message.

3) If a 8 bit host speaks to a 7 bit host, either directly or as a
   gateway, it needs to speak 7 bit.  The conversion will be done by the
   modified SMTP with a new header line prepended to the message
   indicating that is has been encoded in the new format.

4) If a 7 bit host talks to a 8 bit host, it can only speak 7 bit.
   The UA will decode the message back to 8 bits if needed.


Needed Parts to this Proposal
-----------------------------

1) A message format document, specifying the format of multi-part
messages and specifying standard encoding types, and well as a pointer
to the document specifying the outermost 8 to 7 encoding type.  

2) A revised SMTP specification, including a pointer to the document
specifying the outermost 8 to 7 encoding type.  

3) The encoding document.  I'm not the resident expert, and the only
proposal that I can recall is TEX-HEX and it's relatives for
performing the 8 to 7 encoding meeting the ascii preservation rule.