I haven't been watching this list for too long (it's overwhelming how much
traffic there is on it). Let me describe how the problem has been attacked
in System V Release 4 (SVr4) and beyond. For those of you not familiar with
SVr4 mail, it is a fully 8-bit transparent, content independent mail system.
Any 8-bit message can be transmitted using mail, including arbitrary data
files. (I know of people who regularly mail spreadsheets and even a.out
executables around without any problem.) Most of the description below will
actually deal with the mail system which comes in the release beyond SVr4,
known as System V Release 4.0 Enhanced Security (SVr4ES). That mail system
is evolved just slightly beyond what is in SVr4.
You should have watched the list a little longer, it seems, before you made
the comments about RFC-XXXX that you did. Almost all of them are completely
wrong. I don't know what you've been reading, but it is not RFC-XXXX.
I'll skip over the stuff about SVr4 mail for the purposes of this reply.
I'll get back into it later if you want to continue this discussion once you've
read RFC-XXXX.
So how does this information affect the proposed RFC-XXXX's (both the
extended RFC-822 and SMTP proposals)? I know that SVr4ES isn't available
from any vendors yet, but SVr4 mail has been around for at least 2 years.
AT&T Mail has been handling thousands of binary messages daily for 5-6
years. The technology being used is not new; it is simple and has been
proven through actual use.
I've been using a variant of RFC-XXXX locally for a while now. It currently
conforms to the April draft of RFC-XXXX. I'll be moving to the May draft
in the next couple of weeks.
Much of the technology embodied in RFC-XXXX was developed in response to
observed weaknesses (some of them quite serious) in previous schemes. I
note that some of these weaknesses are present SVr4 mail (according to
your description at least). If you'd like to discuss this further I'll
be happy to do it offline. I don't think the list wants to go through this
again.
I think it would be a shame if mail on the Internet weren't as capable as
mail between SVr4ES systems, and weren't as capable as mail on at least one
commercial mail system. It would also be a shame if the modifications being
proposed for the Internet weren't at least somewhat compatible with SVr4ES
mail.
I'm not going to address this since I don't know enough about AT&T mail, and
I was not able to learn enough from your message to be sure. I will say
that I saw nothing immediately obvious in AT&T mail that would preclude
interoperability with RFC-XXXX.
I think the proposals for the current RFC-XXXX's will bring the Internet up
to the 1980's as far as mail goes. However, it will do NOTHING for the mail
of the 1990 and 2000's, which will require multiple parts, mixed binary and
text, and multiple types and attachments mixed together. How do you plan on
sending mail with an embedded voice and video image? Those types of messages
are being sent right now; not being able to handle them is silly. Such
messages certainly won't flow across the Internet with the current RFC-XXXX
proposals.
Let's see. RFC-XXXX specifies EXPLICITLY mechanisms for "multipart messages,
mixed binary and text, and multiple types and attachments mixed together".
Specifically, there's a multipart mechanism (which can be nested), a
mechanism for encapsulation of binary, and an extensible mechanism for
attaching types to both textual and binary messages.
Specific types are defined for carrying audio and image data as well. We
certainly agree that not having these things is silly, that's why they are
in there!!!
I'm not going to drag this out -- please READ RFC-XXXX and then commment on
it. If somehow you've missed getting a copy I'll be happy to send you one.
Ned