🚀 go-pugleaf

On Thu, 2 Apr 1992 10:45:44 -0500 jwagner@PRINCETON.EDU said:

>But I  still need to know  what delivery options people  need beyond the
>two  currently on  the table  (80 byte  card image  with longer  records
>truncated and NETDATA).

Well I have  thought about this business and came  to the conclusion that
there is  no way LISTSERV  is going to use  Netdata, stripped or  not, to
send DISTRIBUTE  jobs with long lines  to other servers. Netdata  has the
property  that a  logical record  will not  necessarily start  on a  card
boundary, and as  far as I know there  is no way to force  this to happen
(by  inserting "filler"  bytes or  whatever).  This means  the RSCS  list
processor could not  be used any longer, which is  a huge step backwards.
In addition  there is the problem  of CRC calculation, which  is based on
card images, and which I want reported  as a CRC error by the appropriate
DISTRIBUTE routines, rather than as an error 32 from DMSDDL with the file
transferred to the postmaster and nobody else being notified.

There is  no need for me  to put up  with all that aggravation  simply to
make it possible for  records to exceed 80 bytes. I  need to keep sending
the jobs in  PUNCH format so that  I can use the RSCS  list processor and
checksum  things  in a  straightforward  way,  and have  checksum  errors
reported as  before. The only thing  that must change is  the contents of
the card images  that represent the message being sent.  The new protocol
must be straightforward and easy  to implement efficiently. My first idea
was to just  do the same thing  BSMTP does in MAIL  FROM/RCPT TO headers:
put a  X'15' in column 80  if a continuation is  needed (if col 80  was a
X'15', force a continuation with a X'15'  in col 1 of the next line). The
message will look very much the same as when regular folding takes place,
except you get  a special character in column 80.  This makes viewing and
debugging much easier.  The new convention could be  indicated in advance
by a new BMSTP  statement, or by using DATB rather  than DATA to announce
the text, or whatever.  If the mailer were to support  such a format, the
data  could  be delivered  'as  is'  by  LISTSERV  without having  to  be
re-encoded in Netdata format.

  Eric