[Top] [All Lists]

Re: Implications of MIME for Transport

1992-04-14 19:02:03

[IETF-ACK readers who do not read IETF-822, Nathaniel Borenstein
 posted a draft of an ``Executive Summary'' type document estolling
 the virtues of MIME.  He asked for comments so I'm providing
 a few.  They happen to overlap considerably with the IETF-ACK 
 charter, sooo... -- David]

Rejected Messages

An unfortunately frequent duty of message transport software is the
rejection of mail to the sender.  This may happen because the mail was
undeliverable, or because it did not conform to the requirements of a
gateway (e.g. it was too large).

There has never been a standard format for rejected messages in the
past. ...

Weeelll... strictly speaking there *is* already a standard format
for rejected messages.  It is the "Delivery Report" format defined
over in the X.400 series.  Which, of course, means that the TCP/IP
crowd is going to reject it out of hand because it's big, ugly, and
from the (*&(* phone companies ;-) ;-) ;-).

It should be stressed that the transport software does not need to
understand the structure of the rejected message at all.  It merely
needs to encapsulate it properly.

Again, strictly speaking you are correct.  We can continue on with the
current situation of cryptic error messages coming back to users which
require experts to decode them.  If, instead, we define a standard
format for delivery reports (which include negative delivery reports
as a subset of the functionality) the users UA (if it's smart enough)
can decode the information and present it nicely.  There are other
added side benefits like being able to tunnel IP packets ;-).  Of course
few people will tunnel IP packets with e-mail, but that indicates we
can do other interesting applications -- IF delivery reports are in
a standard parsable format.

As a start I propose adopting the capabilities and features of the P1
and P2 delivery reports into RFC-land documents.  We can represent
those things using the format defined in RFC-1148, something which is
already parsable &c.  If there are capabilities we want to add beyond
that.. fine, wonderful, fantastic.  But use this already existing stuff
as the basis, please.

Fragmenting and Reassembling Large Messages

One problem that occurs with increasing frequency in Internet mail is
the rejection of messages because of size limitations.  This problem can
be expected to grow substantially more severe with the acceptance of
MIME, as MIME invites the use of very large objects such as images and
audio clips.  Fortunately, MIME also provides mechanisms that can help
alleviate the problem.
In particular, when gatewaying mail to or from a system or network known
to enforce size limitations that are more or less stringent than are
enforced locally, message transport software might choose either to
break a large message into fragments, or (perhaps less likely) to
reassemble fragments into a larger message.

Yes automagic fragmentation and reassembly will be neato and keano.

I would be surprised if a sending MTA were to be able to magically know
that a destination MTA would have strict size limits.  I believe that
the only (or `best') way this information can travel from destination
to sending MTA is as part of the protocol between the two MTA's.  I
believe the IETF-SMTP group is talking about adding a SIZE verb to
SMTP, which would serve this purpose.

The point is your words imply that the size limit is known ahead
of time.