[Top] [All Lists]

Re: Implications of MIME for Transport

1992-04-15 10:15:04

[Since the focus of ietf-822 is on UA-UA issues perhaps there
 should be another group formed on MTA-MTA issues?  ;-) ;-)]

Excerpts from internet.ietf-822: 15-Apr-92 Re: Implications of MIME fo..
Guido van Rossum(_at_)cwi(_dot_)nl (1368)

Moreover, we already know that it is within the bounds of reasonableness
for MTAs to reject mail based on size.  Now, if someone sends me a GIF
image, and the MTA says its too big, I'd much rather get it as a
lower-quality JPEG image than not get it at all, at least in most cases.
 So I think the bottom line is that this is not nearly as cut and dried
as you imply.  While I'd rather never lose information, I'd often rather
lose a little information than all of it!

Both Nathaniel's and Guido's statements are reasonable points of view.
There are times when loss is acceptible and times when it isn't.  I
doubt that Guido uses FAX machines for transporting pictures needing
image analysis.  On the other hand the people who avidly collect GIF's probably wouldn't care if it became a bit fuzzier.

So, how to serve both parties?

If you take Guido's stance then bandwidth will be wasted, but every last
pixel of the sex scene will make it through unmolested.

If you take Nathaniel's stance then the NASA people (and others) who need
to find volcano's on jupiter will be unable to do so.

There certainly isn't any automagic way to determine the senders desire
with facilities we have at hand.  You couldn't, for instance, look at the
contents or at the source & destination addresses to determine what purpose
the bits will be put to.

So you give the user a way to declare their desire.  For instance the
X.400 protocol contains three flags in P1 named


This by itself satisfies most or all the concerns above.  It might be
nice to have a flag which allows differing levels of loss on a conversion.
But how to describe that, etc?  We can leave that for `later' ..

Where to carry this flag and what to do with it at gateways and such?
But the discussion starts to get out of my depth and into issues of
`style' as applies to protocol specification.  I'll just note that 1148
specifies carrying these particular while X.400/P1 specifies carrying
them in an envelope which is somewhat equivalent to the data carried
in the SMTP conversation.  It'd be nice to expand the amount of information
which SMTP carries, but that's a job for the other WG.

There is potential for abuse with this.  That is, the
people might learn to always set the LOSS-PROHIBITED flag and the
researchers might forget to set it.  But at least control is in the
hands of the sender ...