Date   : Sat, 09 Aug 1986 00:10:44 EDT
From   : Dave Towson (info-cpm-request) <cpmlist@AMSAA.ARPA>
Subject: [prindle: access to SIMTEL20 from other nets]

Fellow CP/Mers - Thanks to all who have contributed to this discussion so
far.  The comments have all been quite thoughtful and reasonable, in my
opinion.  With this note, I am relaying a message sent to me at the list
maintainer's address for the reason stated therein.  This message, like some
others, suggests an approach that would require the development of some new
software.  Assuming that a host to run some special software (not necessarily
exactly as described here, but something new) were available, does anyone care
to volunteer to write such software?  


Dave


----- Forwarded message # 1:

Received: from nadc.arpa by AMSAA.ARPA id a013593; 7 Aug 86 10:11 EDT
Date: 7 Aug 1986 10:07:44-EDT
From: prindle@NADC
To: cpmlist@amsaa
Subject: access to SIMTEL20 from other nets

Dave,
I am sending this to you rather than the whole list because:

1. It is long.
2. It may be totally out in left field!

If you think it has any merit, then by all means post it to INFO-CPM and/or
INFO-ADA.  But if you think I'm crazy, tell me so, 'cause I still have plenty
to learn about networks.

Incidentally, if for no other reason, CP/M re-birth may be attributed partially
to the Commodore 128.  That's certainly why I'm here!

Thanks,
Frank Prindle

I know I have gotten requests to help non-DDN people get selective pieces of
software from the SIMTEL20 archives.  To do this manually, while tolerable in
extreme moderation, is impossible on any sort of large scale.  On the other
hand, wholesale distribution of software over the INFO-xxx mailing lists is
just not practical.

There is, perhaps, a technical solution to the problem of how to allow non-DDN
network users to submit software to, and extract software from, the SIMTEL20
public domain archives (CP/M, MSDOS, UNIX, and ADA). First let's work up to
the solution with some observations:

First -

DDN hosts seem quite capable of receiving mail from, and mailing to, hosts on
other networks through a fairly extensive network of relay sites.  Although
there seem to be a variety of syntax variations, the following form (from the
DDN side) seems more or less universally understood:

       mail person%host.hisdomain@relayhost.mydomain

where "relayhost" has access to both "mydomain" and "hisdomain" networks.

 (e.g.) mail smith%umass.bitnet@wiscvm.arpa

I don't know the details of mail syntax from other networks to get the mail to
a relay site, but it obviously can be done, and if it gets to a relay addressed
to someone%somewhere.arpa, it will no doubt make it to it's DDN destination.
(This will undoubtedly be somewhat complicated soon, as there is a movement
afoot to have DDN hosts adopt more exotic domain names as opposed to just
plain ".arpa".  This will just blow off about half the mailers and mail
servers in the world for a few months until all the software gets modified to
handle the new domain syntax).

Second -

The "person" to whom mail is addressed may, in actuality, be an automaton
(e.g. a re-distribution list) as opposed to a real person who sifts through
mail.  Thus, properly formatted mail might easily be processed as input to
a computer program, the actions of which would be directed by the contents
of the mail.  A simple example of this would be a periodic batch demon
checking a user's mailbox every hour or so and sending out a canned reply
to the sender: SORRY, I AM OUT OF TOWN FOR TWO WEEKS - WILL REPLY 8/16/86.
Of course, the demon would have to have a few ounces of intelligence; for 
example, it would be most unkind to send such a reply to a distribution list
like INFO-CPM, for this would start an endless loop (don't laugh, it has
happened!).

Now, for the potential solution -

Instead of a non-DDN user posting an encoded form of his software to the entire
world, he would mail his encoded software (adhering to specific formatting
rules) to a DDN "server" mailbox.  If "uuencode" were used, perhaps it would
be best if this server were on a UNIX machine rather than TOPS-20, but other
encoders/decoders (e.g. public domain atob/btoa) could be used.  The server
would scan the sender's message, sense that it was a submission and properly
formatted, send an acknowledgement back to the sender, and queue the decoded
files for "ftp" transmission to SIMTEL20 archive administrators (the last step
would not be necessary if the "server" were SIMTEL20 itself).  When and if the
archive adminstrator put the software in the archives, he/she would notify the
original user by mail, who in turn could post a short note to the mailing list
abstracting the software and noting that it was now in the archives.

When a non-DDN user wished files or a directory from a particular archive,
he would again mail to the "server", this time formatted as a "software
request" rather than a submission.  The server would scan the sender's message,
sense that it was a software request, ftp the requested software from SIMTEL20,
encode it according to the rules, and mail it to the requestor.

When the "server" receives an ill-formatted message, notice to that effect is
simply returned to the sender.  A single server need not handle all the
SIMTEL20 archives, nor is it necessary for a single server to handle both
the submissions and the software requests for a single archive (i.e. sharing
the burden!).

But can it work? -

Now I'm not saying such an approach is without substantial technical risk or
complexity.  It obviously represents a potentially large increase in computing
resource burden to be absorbed by the administrator(s) of the server(s).  It
may also be administratively unacceptable to the DDN regulators or to the
regulators of the other networks.  It also may not work at all, for a variety
of technical reasons (e.g. mail messages on USENET are generally limited to
100000 bytes, so large files would have to be broken up).  By building a new
(and inefficient) File Transfer Protocol on top of the mail connections, it
probably borders on heresy!  Furthermore, interactions with "net.sources" and
other such special arrangements should be considered.  Finally, it represents
a lot of work to implement.

Nuff said - I'll ramble no further.  Perhaps this discussion should be moved
to INFO-NETS.
                                               Frank Prindle
                                               Prindle@NADC.arpa

----- End of forwarded messages