Support for the generation of MIME compliant messages has been added to
LISTSERV through two new file formats, MIME/TEXT and MIME/APPL.
Preliminary note: the next version of the VM mailer, planned for release
4Q92, will support Netdata format. When this version and the necessary
information to modify LISTSERV to support it are released, there will be
no need to do anything special to mail files with lines longer than 80
bytes. Thus the reason for implementing MIME support is NOT to solve the
80 columns problem, which is a limitation of the VM mailer (and,
consequently, of any software which sends files to the VM mailer in PUNCH
format due to lack of support for other formats). The goal is to provide
a mechanism which can cross gateways safely and will be widely
implemented (I do not say 'is' here because the answers to my previous
questions about MIME and the software I have seen so far make it clear
that we are still at a very embryonic stage). Thus there is and will be
no support for quoted printable encoding, which does not generally
survive ASCII<->EBCDIC translation.
'F=MIME/TEXT' (minimum abbreviation: F=MIME for now, might change before
the official release) can be specified when ordering text files which get
corrupted when mailed normally. LISTSERV translates the text to ASCII,
adds a CRLF at the end of each line, and encodes the message using base64
transfer encoding and 'Content-Type: text/plain'. Note again that this
will not work with binary files, for obvious reasons.
'F=MIME/APPL' (minimum abbreviation: F=MIME/A) can be used as a safer
replacement for F=UUENCODE. LISTSERV does NOT translate the input data or
generate any kind of carriage control: it simply encodes the raw input
data as a stream of binary bytes, using base64 encoding and
'Content-Type: application/octet-stream' with a 'name=' keyword. Because
the data is not translated to ASCII, this will not work with text files.
Again, it is a replacement for F=UUENCODE, which completely ignores
record boundaries and performs no translation, under the assumption that
the file being ordered is a ready-to-use binary file downloaded from a
PC.
In spite of what you may have heard elsewhere, MIME does NOT provide any
file transfer mechanism which could replace FTP or the NJE file transfer
formats (NETDATA et al). MIME can only transfer a stream of bytes, using
the 'application/octet-stream' type, and the standard does not assign any
particular meaning to these streams of bytes: it suggests that the user
interface should offer to deposit the decoded data into a disk file,
which under VM, VMS, MVS or any other non-unixish operating system simply
gets you a one-record file containing a long string of binaries.
Before you counter that MIME could be easily extended to provide such a
functionality and that I should indeed be working full time on doing that
right now, let me add that I seriously doubt that MIME would be a viable
alternative to FTP and SENDFILE, for performance and usability
considerations. If you think the BITNET 300k file size limit is
preposterous, take a look at what most SMTP's are enforcing! 100k seems
to be the norm, and many sites will limit you to as little as 20k.
Granted, MIME defines a way to split messages into smaller fragments, but
when your 3M package is split into 400 chunks of 20k (counting the extra
33% for base64 encoding), chances are that chunk number 294 will get lost
on its way and that you will have to restart from the beginning.
Furthermore mail is not precisely a high performance bulk-data mover.
Unfortunately I haven't been able to make serious tests including the
reconstruction time for series of 100k-messages, but what imprecise
measurements I could make so far indicated a transfer rate of about
2k/sec between two pretty fast machines on the same ethernet. This is not
bad at all for a "backup" mechanism, but I really can't see this becoming
the "prime" file transfer mechanism and making SENDFILE obsolete.
Eric
|
