We *need* binary transport because [see text of messages from last
seven months]. Yes, I do intend to show/run arbitrary data (such as
bitmaps, lotus spreadsheets, and MS-word docs) without PEM. Yes, I do
intend to allowing users to specify proper defaults for declining
information for particular applications and/or from particular hosts.
No. We don't *need* binary transport to do these things. We *need* binary
encoding to do these things. We have binary encoding already. We *need*
binary transport only if we're concered about that last 20% of efficiency to
the point where we want to make major protocol changes to get it.
Sigh, never say anything in one paragraph when five will do.
The reasons for *needing* binary transport are those related to CPU, memory,
and disk space utilization. One common example used today in (non-SMTP)
PC based mail systems is the sending of a document image -- the difference
between reading body parts of the incoming mail message into display memory
and doing base64 on the fly and then doing the copy is rather substantial.
One of the counter arguments that has been raised over the past few months
has been that binary transport won't really save anything because you would
have to decode them anyway (possibly saving images/executables to disk)
because no one would ever trust incoming binary to use it directly. And,
while I would not trust everyone, I would trust the mail from those who
send the vast majority of the messages I recieve.
enjoy,
leo j mclaughlin iii
ljm(_at_)ftp(_dot_)com