Skip Navigational Links
LISTSERV email list manager
LISTSERV - COMMUNITY.EMAILOGY.COM
LISTSERV Menu
Log In
Log In
LISTSERV 17.5 Help - LSTSRV-L Archives
LISTSERV Archives
LISTSERV Archives
Search Archives
Search Archives
Register
Register
Log In
Log In

LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Menu
LISTSERV Archives LISTSERV Archives
LSTSRV-L Home LSTSRV-L Home

Log In Log In
Register Register

Subscribe or Unsubscribe Subscribe or Unsubscribe

Search Archives Search Archives
Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
Support for multipart messages in version 1.8a
From:
Eric Thomas <[log in to unmask]>
Reply To:
LISTSERV give-and-take forum <[log in to unmask]>
Date:
Tue, 17 Aug 1993 02:31:14 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (42 lines)
To make life easier for EARN users  who were used to a similar feature in
LISTEARN, version 1.8a introduces support for a new command line keyword,
SPLIT=, which  can be  used when  ordering files  to request  delivery as
multi-part MIME messages with the  specified maximum size (in kilobytes).
Thus  for instance  you could  GET BLAH.ZIP  SPLIT=100 if  you know  your
gateway only supports messages of 100k  or less. LISTSERV will not accept
to cut  files into  pieces of  less than  20k each,  mostly to  avoid bad
surprises if you forget a zero.
 
To  avoid confusion,  it is  important to  note that  SPLIT=nnn is  not a
delivery  format  like  F=NETDATA  or F=MIME/APPL,  but  an  option  that
instructs LISTSERV to further cut the  file in a number of smaller pieces
before sending it  to you, in addition  to whatever else it had  to do to
encode the  file and get it  to you. One  does not order files  "in SPLIT
format", and indeed 'GET SOME.ZIP F=SPLIT'  is not valid. You both select
a format and tell LISTSERV what the maximum message size for your gateway
is (in most cases  you will just type SPLIT=nnn and  let LISTSERV use the
default format, which is "plain mail").
 
The SPLIT=nnn option  is valid only for mail  delivery formats: UUENCODE,
XXENCODE, MIME/TEXT, MIME/APPL and of course MAIL. You cannot use it with
NJE formats such as F=NETDATA because it would make little sense to order
a NETDATA deck in 6 pieces which have to be assembled using PUNCH (NOH in
the right  sequence before you can  RECEIVE the file. At  any rate BITNET
accepts much larger messages  and there is no need to  split NJE files in
segments of 100k in the first place.
 
The MIME  multipart format was  chosen because it is  straightforward and
reasonably  intuitive to  a  human  reader: people  without  a MIME  user
interface are not being sacrificed to a "chosen few". I have attempted to
decode the messages  using an old copy  of MH (V6.7) I  installed about a
year ago  on a  local unix  box and it  claims the  message is  not valid
and/or the last part is missing. I  on the other hand claim the last part
is not  missing and/and the  message is valid,  it just doesn't  have the
"total=" indicator on all  segments, nor does it need to,  nor am I going
to make two passes through the file just to supply it. I would appreciate
feedback on  the ability of current  versions of MIME user  interfaces to
handle the  output of  both 'GET  PEERS NAMES  F=MIME SPLIT=20'  and 'GET
PEERS NAMES SPLIT=20' (I have just installed the code on LISTSERV@SEARN).
 
  Eric

ATOM RSS1 RSS2

COMMUNITY.EMAILOGY.COM CataList Email List Search Powered by LISTSERV