cpmlist@AMSAA.ARPA (info-cpm-request) (08/10/86)
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 --------------------------------Cut Here-------------------------------------- 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