ietf-822
[Top] [All Lists]

Re: Transport Encodings

1991-09-16 16:05:25

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.


Sorry, Ned, you're right.  My message was somewhat more than cryptic.  I was
trying to keep this mailing list from once again thrashing on a non-issue, but
I appear to have failed miserably.

I was wondering why an issue that had been dead and buried long ago at the
SMTP WG and seemingly on this list as well was once again raised.  Namely,
that RFC-XXXX should provide a mechanism for describing the transport but
that publishing RFC-XXXX should not depend on the success or failure of
the ietf-821 working group to provide transports other than line oriented
7-bit ASCII.

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 ...[binary images/executables]... anyway
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.


Don't you use X-Windows?

More to the point, I don't feel any safer because I now have to uudecode
incoming mail by hand and run MS-Word on the output instead of having my
UA automagically feed the message directly to MS-Word.  All the same
spoofing problems exist and I still have to worry about 'bad' files,
it just takes a lot longer.


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....


Well, we don't *need* any of the work we're doing.  Right now, we have a
standard way of transmitting 8-bit text (most of the world's computers
have 8-bit clean SMTP available) and much less standard way of sending
binary images (most UAs which do automatic inclusion of binaries use
uuencode and a few use BINHEX, but few UAs understand the magic enclosure
delimiters of other UAs).

On the other hand, there are many things that would be very nice which
would come from widespread implementation of RFC-XXXX and an enhanced
SMTP protocol.  First and foremost, RFC-XXXX introduces the concept
of a standard way to send typed multipart messages.  If Neil and your
(and my) concerns about type registration are met then a RFC-XXXX based
UA becomes a *very* powerful tool.  Second, deciding on a standard
7-bit format for 8-bit text would allow those behind 7-bit MTAs the
ability to reliably transmit 8-bit text messages to other 7-bit UA
users as well as those with existing 8-bit UAs on the other side of
a 7->8bit gateway.  Third, deciding on a standard 7-bit format for
binary information would allow all those with non-binary capable MTAs
to reliably transmit non-text messages.  Fourth, (and this is a statement
from the 821 WG, RFC-XXXX folk need not read) deciding on a standard method
for support of arbitrary binary messages allows resource limited mail
environments improved Internet access and in some cases Internet access
period.  (Some envionments will be limited by the CPU cycles or non-volatile
storage available, others by funds available for line charges).

                           ....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.

...I think reliability and quality of service are vastly more important
than minor (and I do mean minor) resource savings.


Of course, reliablity and quality of service are what is important.  But,
if a protocol demands an application which is so resource intensive that
it does not run quickly enough to bother using or does not run at all, then
the quality of service is very poor.  

As for the size of the resource savings, it will undoubtedly be very different
in the varied environments of TCP/IP.  However, it is fairly certain that the
difference between [bcopy()] and [bcopy(), unbase64(), bcopy()] is in the
100%-1000% range rather than 10%-100%.  It is equally certain that a base64
encoded binary will carry a 25% surcharge over the original.  It is highly
probable that base64 encoded compressed binary will carry a similar surcharge
over the original compressed binaries.

Luckily, we're not talking about something that threatens reliability or the
RFC-XXXX effort, we're talking about something which (and I know text-centric
folk disagree) will likely help the RFC-XXXX effort by providing extra
incentive for the purchase/adoption of new mail software.  Don't knock
that 25% savings -- I know all too many organizations in which the following
line would work, "Buy this new mail software for me and we'll save on our
email bills because they use this new compression technology called 'binary'."


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....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.


Ya, ya.  See you in New Mexico....  

enjoy,
leo j mclaughlin iii
ljm(_at_)ftp(_dot_)com


<Prev in Thread] Current Thread [Next in Thread>