Newsgroups: bit.listserv.lstsrv-l
Date:         Sat, 3 Oct 1992 19:49:30 +0100
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      LISTSERV support for outgoing MIME-formatted mail

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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU