(leo j mclaughlin iii) writes:
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.
I resent this. What you said originally was completely bogus -- I was simply
being polite about it. You said that we need binary transport for blah blah
blah. I maintain that we don't *need* it to do any of these things. Nothing
you've said proves me wrong on this. It now appears that you want binary
transport because it makes some of these things *nicer*. While this may be true
(I think it is far from a given), it is not what you said. Given your past
record for reiterating already discussed material and generally ignoring
previous messages, I don't think I should assume much of anything when you make
such vague hand-waving references.
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.
Fine. You say you need it. I disagree, as do many others on this list. I think
reliability and quality of service are vastly more important than minor (and I
do mean minor) resource savings.
You also raise a number of straw men here. First of all, if you want to use an
unencoded or compressed format on disk, well, go for it! If you want to use a
similar format in memory that's fine too. This is all highly implementation
dependent. If this then optimizes the mapping of material into display memory
(and I suspect in order to optimize this you're going to have to do a lot more
than simply represent the material in binary form) then you win.
This group is talking about a network representation; what you do once things
are local is a local issue. You can compress, map, encode, decode, and do
whatever you like locally. (Just be sure and tell me what software it is you
write this way -- I want to make sure I don't use it since I'm sure it is going
to be as unreliable as hell.) On the network I want things to interoperate
properly, and I don't care about wasting a small amount of bandwidth to get
this characteristic.
For now let's stick to the issues and get the 822 extensions done. They are not
going to invalidate or cripple a future binary transport, that's for sure.
(Even if we remove the binary encoding now as Marshall has proposed it can be
restored by a future document -- nothing is cast in stone.) If you want to
press on in the ietf-smtp group to actually define and implement a binary
transport in the future go right ahead. This was in fact taken away as an
action item from the Atlanta meeting; it remains to be seen if this can be done
in a fashion that the working group can accept.
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.
I disagree and would never subject myself or anyone else to software written
this way. My collection of horror stories is far too large already.
Ned