* * * * * ** * ** ** * * * * * * * * * * * * * * * ***** ******* * * * ***** ****** ******* ****** * * * * * * * * * * * * * * * * * * ******* * * * * * * * * * * * ** * * * * * * * * * * * * * ****** * * * ***** * * * * * * * * The monthly guide to BITNET servers and services * * * * Volume 1 Number 8 February 1987 * * * ***************************************************************** * * * Editor: Chris Condon CONDON@YALEVMX * * Assistant Editor: Steve Sutter SUTTER@YALEVMX * * NetMonth Staff Supervisor: Gary Moss MOSS@YALEVMX * * * ***************************************************************** * * * * RRRRRRRR EEEEEEEEE AAA DDDDDDD EEEEEEEEE RRRRRRRR RRRRRRRRR EEEEEEEEE AA AA DDDDDDDD EEEEEEEEE RRRRRRRRR RR RR EE AA AA DD DD EE RR RR RR RR EE AA AA DD DD EE RR RR RRRRRRRR EEEEEEE AA AA DD DD EEEEEEE RRRRRRRR RRRRRR EE AAAAAAAAA DD DD EE RRRRRR RR RR EE AA AA DD DD EE RR RR RR RR EEEEEEEEE AA AA DDDDDDDD EEEEEEEEE RR RR RR RR EEEEEEEEE AA AA DDDDDDD EEEEEEEEE RR RR * * SSSSSSS UU UU RRRRRRRR VV VV EEEEEEEEE YY YY SSSSSSSSS UU UU RRRRRRRRR VV VV EEEEEEEEE YY YY SS SS UU UU RR RR VV VV EE YY YY SS UU UU RR RR VV VV EE YY YY* SSSSSSS UU UU RRRRRRRR VV VV EEEEEEE YYY * * SS UU UU RRRRRR VV VV EE YYY * SS SS UU UU RR RR VV VV EE YYY * SSSSSSSSS UUUUUUUUU RR RR VVV EEEEEEEEE YYY * SSSSSSS UUUUUUU RR RR V EEEEEEEEE YYY * * * * IIIIIIIII SSSSSSS SSSSSSS UU UU EEEEEEEEE * * IIIIIIIII SSSSSSSSS SSSSSSSSS UU UU EEEEEEEEE * * III SS SS SS SS UU UU EE * * III SS SS UU UU EE * * III SSSSSSS SSSSSSS UU UU EEEEEEE * * III SS SS UU UU EE * * III SS SS SS SS UU UU EE * * IIIIIIIII SSSSSSSSS SSSSSSSSS UUUUUUUUU EEEEEEEEE * * IIIIIIIII SSSSSSS SSSSSSS UUUUUUU EEEEEEEEE * * * * * ***************************************************************** 1 ************************************************************************ * Contents * ************************************************************************** Bitnotes ............................................................... 1 The NetMonth Reader Survey ............................................. 2 The Simtel20 Archives .................................................. 6 Listserv's File Server Functions ...................................... 10 Odd Parity ............................................................ 15 The Ethics of Computer Conferencing ................................... 16 Electronic Chain Letters .............................................. 17 New Mailing Lists ..................................................... 18 The CSNET Information Server .......................................... 19 The United States Data Defense Network - Network Information Server ... 21 The Color and Vision Network .......................................... 22 Feedback .............................................................. 23 Policies .............................................................. 26 NetMonth is a network service publication distributed free of charge to students and professionals in BITNET and other networks. This magazine and it's companion file, BITNET SERVERS, are the work of the Yale Computer Center BITNET Services Library (BITLIB) staff. The BITLIB is a local online help facility designed to inform Yale network users about what services are available to them through BITNET, and provide instructions and utilities for their proper use. In publishing NetMonth the BITLIB staff members hope to share the fruits of their labor with institutions outside of Yale in order to promote a productive and enjoyable networking environment for everyone. BITNET SERVERS is BITNET's most complete and up-to-date list of servers and services. It is sent to NetMonth subscribers at the same time as the magazine. BITNET SERVERS is dependent on your support to remain accurate. If you know of servers and services not listed in BITNET SERVERS, or of those listed in the file that are no longer available, please contact the NetMonth staff at BITLIB@YALEVMX. Subscribing to NetMonth and BITNET SERVERS: Send a mail message with your name and network address (userid@node) to BITLIB@YALEVMX (Arpanet users send your mail to BITLIB%YALEVMX.BITNET@WISCVM.WISC.EDU). A subscription to NetMonth is also brings you BITNET SERVERS. You do not need to request both. In order that we may maintain the most efficient mailing list possible we ask that you inform us prior to the expiration of your userid. Article submissions and Letters to the Editor are both accepted and encouraged. See the "NetMonth Policies" section at the end of this magazine for more information. Printing this file: VM users may print this file by first copying or renaming the file to NETMONTH LISTING and then printing the resulting file using your local file printing command. In this way page breaks and other formatting will be recognized by your printer. -------------------------------------------------------------------------- FuzzyBytes Electronic Publishing "Because We're Here." 1 Page 1 ************************************************************************* * Bitnotes Issue 7 * *************************************************************************** Well, let me say this about that... A small celebration is in order. The NetMonth/BITNET SERVERS mailing list has reached (actually, exceeded) the 500-subscriber milestone. This is a significant number, not only because it is so large, but because there are now twice as many readers as there were when the first issue of NetMonth hit the newstands only eight months ago. The reaction from the staff ranged from astonishment to extreme glee. The general consensus: "It looks like we're doing something right." The letters and comments in the subscription requests seem to support this opinion. I certainly have no objection to people saying nice things about the staff, the magazine, or my taste in cover art. (On the contrary, I am known to thrive on that sort of thing). Some of you will remember, however, that I feel terribly cheated when I receive little creative input from the readers. How could the magazine be better? What would you like to see? Are we doing anything that annoys you? What should we emphasize? What aren't we emphasizing enough? Yes, it is time once again for a Reader Survey. Those of you who are on the mailing list for NetMonth will be receiving the file NETMONTH SURVEY along with BITNET SERVERS and this issue. This should make it terribly easy for you to answer the questions by editing the file. The completed survey should be sent to BITLIB@YALEVMX (by mail is possible). For those of you who are not on the mailing list for NetMonth, the survey appears in this issue. The directions this magazine takes in the future are directly dependant upon your answers. Most of the questions on the survey are multiple choice, but the most important questions are those where you are asked to give your opinion. There are also a number of questions about which BITNET servers and services you use most often. Blurring identities... A file server is a file server, unless of course, it is also a name server. Then it is niether, or both. Many of our file servers have taken on the duties of name servers, notably NETSERV. The name "file server" doesn't exactly do it justice, and "name server" doesn't even come close. Somehow we get by and list it separately under both categories. This sort of thing is so commonplace that we don't even notice anything odd about it. 1 Page 2 A list server is a list server, unless of course, it is also a file server. Then it is... strange. Yes, LISTSERV now runs as a file server, with a command set that you couldn't tell from NETSERV's unless you looked closely. This added utility will allow members of mailing lists to easily access list archives. List maintainers will be able to make various files available to subscribers. Everybody will be happy. See the article on Listserv's file server functions in this issue. Thanks where thanks is due... Thanks to those people who contributed articles for this month's issue: John R. Cook sent in some suprising results from his Relay Ethics survey. (Well, they suprised ME, anyway.) Eric Thomas contributed the information on Listserv's file server functions, and Peter Kaiser wrote about the Color and Vision Network. Finally, thanks to Steve Middlebrook for informing me about the SIMTEL20 ARCHIVE-REQUEST and how I could get instructions on how to use it. Virtually, Chris Condon@YaleVMX ************************************************************************* * The NetMonth Reader Survey * *************************************************************************** Please return your survey responses to BITLIB@YALEVMX via mail if possible. All answers will be kept confidential. Thank you for your time... ************************* * Part One - Who are you? * *************************** Answer column +----+ ] ] 1. How long have you been reading NetMonth? +----+ a. 1-2 months b. 3-4 months d. 5-8 months e. I was a Bitlist reader 1 Page 3 +----+ ] ] 2. Are you a(n): +----+ a. undergraduate student >>>Please specify major: b. graduate student >>>Please specify degree: c. computer center staff >>>Please specify: d. educator (doctor, professor, teacher, etc.) e. other >>>Please specify: +----+ ] ] 3. How old are you? +----+ a. 18-25 b. 26-35 c. 36-50 d. 51+ e. none of your business! +----+ ] ] 4. Are you: +----+ a. male b. female +----+ ] ] 5. Do you read any electronic magazines other than NetMonth? +----+ a. yes b. no If "yes", which ones: +-------------------------------------------------------------+ ] ] ] ] ] ] +-------------------------------------------------------------+ +----+ ] ] 6. Do you subscribe to any digests/mailing lists? +----+ a. yes b. no If "yes", which ones: +-------------------------------------------------------------+ ] ] ] ] ] ] ] ] +-------------------------------------------------------------+ 1 Page 4 +----+ ] ] 7. How often do you sign on to RELAY? +----+ a. almost every day b. a few times a week c. a few times a month d. not more than once a month e. never +----+ ] ] 8. Have you ever used a file server before? +----+ a. yes b. no If "yes", which three do you use most often? +-------------------------------------------------------------+ ] ] ] ] ] ] ] ] +-------------------------------------------------------------+ +----+ ] ] 9. Have you registered yourself on a name server (for example, the +----+ NETSERV User Database or the CSNEWS Bitnauts List)? a. yes b. no If "yes", which ones? +-------------------------------------------------------------+ ] ] ] ] ] ] ] ] ] ] +-------------------------------------------------------------+ 10. What operating system is your mainframe running? +-------------------------------------------------------------+ ] ] +-------------------------------------------------------------+ 1 Page 5 ********************* * Part two - NetMonth * *********************** 11. What do you feel are NetMonth's strong points? (Use more space if you need it.) +--------------------------------------------------------------------+ ] ] ] ] ] ] ] ] +--------------------------------------------------------------------+ 12. What do you feel are NetMonth's weak points? (Use more space if you need it.) +--------------------------------------------------------------------+ ] ] ] ] ] ] ] ] +--------------------------------------------------------------------+ 13. In what ways do you feel NetMonth could be improved? (Use more space if you need it.) +--------------------------------------------------------------------+ ] ] ] ] ] ] ] ] +--------------------------------------------------------------------+ 14. What would you like to see in future issues? What kind of ideas do you have? (Use more space if you need it.) +--------------------------------------------------------------------+ ] ] ] ] ] ] ] ] ] ] ] ] ] ] +--------------------------------------------------------------------+ 1 Page 6 +----+ ] ] 15. The best issue of NetMonth so far was: +----+ a. July 1986 b. August 1986 c. September 1986 d. October 1986 e. November 1986 f. December 1986 - January 1987 g. February 1987 h. No opinion Why? +-------------------------------------------------------------+ ] ] ] ] ] ] ] ] +-------------------------------------------------------------+ 16. What stand out in your mind as the best and worst things you ever read in NetMonth? +--------------------------------------------------------------------+ ] ] ] ] ] ] ] ] +--------------------------------------------------------------------+ ************************************************************************* * The SIMTEL20 Archives * *************************************************************************** There is a collossal amount of free public domain software for the CP/M, PCDOS/MSDOS and UNIX operating systems, and for the DoD standard programming language, Ada, in several archives on SIMTEL20.ARPA, a DECsystem-20 running the TOPS-20 operating system at White Sands Missile Range. To obtain a directory listing of interest to you, send your request to ARCHIVE-REQUEST@SIMTEL20.ARPA with up to five of the following commands in the body of any one message: SEND PD:CPM.CRCLST SEND PD:CPMUG.CRCLST 1 Page 7 SEND PD:SIGM.CRCLST SEND PD:PC-BLUE.CRCLST SEND PD:MSDOS.CRCLST SEND PD:UNIX.CRCLST SEND PD:ADA.CRCLST SEND PD:MISC.CRCLST The PD: archive is the one to watch for the very latest CP/M offerings, as it is updated frequently. The PD:, PD: and PD: archives contain software distributed by the CP/M Users Group, the SIG/M Users Group and the PC-Blue Users Group respectively. This software is available on diskettes from the associated users groups, and the archives are updated as new volumes are issued. The PD: archive contains software for the IBM-PC and similar machines. Some runs under CP/M, and some under PCDOS/MSDOS. The PD: archive also contains software for the MSDOS and PCDOS operating systems; but this archive is locally managed, and therefore is updated more frequently than the PD: archive. The PD: archive contains a variety of UNIX tools. Those which apply specifically to CP/M are in the directory PD:. The PD: archive is growing rapidly. Information about this archive is in directory PD:. In general, the archived software is very good, having been worked-over and refined by many users. The documentation and comments tend to be complete and informative. Files in all of these archives can be obtained using the ARCHIVE-REQUEST procedures described in this article. ************ * Disclaimer * ************** Please note that due to the large number of files available, the archive maintainers cannot possibly attempt to validate the proper operation of the various programs. When a program bug is reported, immediate action is taken to either correct the error or remove the offending program from the archives. Still, users must understand that all archive programs are offered AS-IS, and the archive maintainers specifically disclaim any liability should these programs malfunction or cause damage, incidental or otherwise. When testing ANY new software, be certain that all information stored on disk is backed-up before you start, so that you can recover if files are damaged or erased. This is particularly true if you have a hard disk, in which case malfunctions can be spectacularly disasterous. 1 Page 8 **************************** * How to use ARCHIVE-REQUEST * ****************************** To obtain up to five files in a single request message by netmail from the public domain archives kept on SIMTEL20.ARPA, send a message to: ARCHIVE-REQUEST@SIMTEL20.ARPA The message body must contain lines beginning with the keyword SEND, one SEND line for each file requested. Case is not significant. The general syntax of a SEND line is: SEND format filename In general, a filename consists of the following components: device:file.type.generation "device:" is usually PD:, and the combination of PD: is expected unless an alias has been advertised of the form "alias:", which takes the place of both device and directory fields. The generation field should be left off in order to default to the highest generation number so you can be sure of getting the latest version of the file requested. "file.type" follows the usual filenaming conventions. In all formats listed below, if the file to be sent is larger than 55K, the file is sent in numbered parts. The parts must be reassembled in order and edited to remove any headers, preface, and trailers before the process can be reversed to reconstruct the original file. Allowable formats are: SEND HELP Much like what you are reading now. SEND INFO A detailed description of the SIMTEL20 Archives, which includes this file, pointers to certain key files, and descriptions of various file transfer programs and related utilities. SEND BOOTSTRAP A brief quick reference listing of filenames of the key utilities used to reconstruct files sent by the compression and encoding techniques listed below. 1 Page 9 SEND DIR filespec This format returns a CRC list of the requested files, and is the only format which allows wildcard filenames (but not wildcard directory names). The list is sent as an ASCII text file. The wildcard characters are "*" and "%". The asterisk means any number of characters, while the percent sign means exactly one character. Either or both may appear in any combination in either or both the file or type fields, while only the asterisk may appear in the generation field. SEND RAW filename If the file is ASCII, it is sent as-is, regardless of size. This format is the least efficient over network and mail gateway resources. Use this format only if you absolutely must. With the four formats listed below, if the file is ASCII and under 25k characters, it is sent as-is, as if RAW format was requested. Binary files are always processed according to the requested format. However, a request for ARC or SQ processing of files with type ".ARC", ".LBR", or ".%Q%" is ignored and the original file is either uuencoded or hexified (if possible), according to the requested format. If the file was not sent RAW, a short preface is inserted at the front of the message describing the process actually taken and a CRC entry describing the original file. SEND ARE filename or SEND filename The original file is made into a uuencoded ARC file. SEND ARH filename The original file is made into a hexified ARC file if the ARC file is under 64K bytes long. Otherwise, an apology is returned instead of the requested file. SEND SQE filename The original file is made into a uuencoded SQueezed file. SEND SQH filename The original file is made into a hexified SQueezed file if the Squeezed file is under 64K bytes long. Otherwise, an apology is returned instead of the requested file. * * * * * * * * * * * * 1 Page 10 ************************************************************************* * LISTSERV's File Server Functions * *************************************************************************** by Eric Thomas ERIC @ FRECP11 ************** * Introduction * **************** Although the primary function of LISTSERV is to distribute mail and files to pre-defined distribution lists, it may often be desired to provide the subscribers of the list with a set or data or program files to be periodically maintained by a particular person or set of persons. Apart from the obvious example of list "notebooks" (archives), working groups might want to provide minutes of internal meetings held by some of the subscribers, technical groups might want to share application programs and/or mods to a program they are all using, etc. It was decided that the more convenient way of meeting these needs was to provide basic, non-specialized file-server functions along with the mail-processing functions of LISTSERV. Those functions would have to provide powerful yet list-based file access control and remote file updating facilities, under the control of both the list owner and the LISTSERV management. Automatic distribution of updated material to subscribers was another major goal since it makes this distribution more efficient whenever several peers are created to support the list and relieves the file maintainer of the burden of preparing the list of subscribers -- it is the users that request such distribution from the server without any intervention from the file maintainer. It was decided that LISTSERV should conform to the well-implemented and well-accepted standard command set of the Netserv file-server developed by Berthold Pasch (PASCH@DHDIBM1) for EARN. Commands should be similar enough not to confuse unexperienced users who switch from one of the servers to the other, with additional commands or parameters being provided if needed. All the commands would not be supported of course. The LISTSERV commands should conform to the general LISTSERV convention whenever there is a conflict between LISTSERV and NETSERV conventions, the best solution being of course to support both conventions to allow for application programs written for NETSERV to operate with LISTSERV with a minimal amount of changes. A presentation of the set of commands that were retained will follow. You should note that a significant number of these commands have the same syntax for LISTSERV and NETSERV and yet operate very differently on the two servers (the best example being the PW command). 1 Page 11 *********** * FILELISTs * ************* Several "file directories" (FILELISTs) were required to allow each list to have its own set of files, independently from each other, and to make it possible to hide the very existence of those files from those users who are not supposed to retrieve them. LISTSERV maintains a number of FILELISTs which can be nested in each other if needed. The "root" filelist is called LISTSERV FILELIST and is always maintained by the LISTSERV management. In UNIX terms, a FILELIST is a "directory" which can contain sub-directories (any level of nesting is allowed) and is defined upwards in the tree structure with the root being LISTSERV FILELIST. To review the contents of a filelist, you can either request it to be sent to you by means of the usual "GET" command (see below) or use the special command "INDEX": INDex Sends you the specified filelist (defaults to LISTSERV FILELIST). This command is strictly equivalent to "GET filelist_name FILELIST" and has been made available for compatibility with other file servers on the network. LISTSERV filelists are nearly fully compatible with the ones you may obtain from Netserv. The header of the filelist will give information about the contents of the filelist and a list of File Access Codes (FACs) which will be used later in the body of the filelist and identify who will be able to retrieve or store the file in the server. This FAC list is included between "banners" made of an asterisk, a blank and a full line of colons, and will usually have been commented by the maintainer of the filelist to help you understand to whom the FACs refer. The body of the filelist will contain file declaration, possibly interspersed with comment lines. Comment lines start with an asterisk in column one. The format of the other lines is as follows (column numbers are given for easier reference by application programmers): 1 3 12 23 26 31 35 41 47 56 65 ] ] ] ] ] ] ] ] ] ] ] V V V V V V V V V V V filename filetype get put rfm lrecl nrecs date time description SAMPLE FILE ALL CTL VP 106 85 86/11/12 19:50:14 Dummy file filename is the 'name' of the file to be used in the "GET" command. filetype is the 'type' of the file to be used in the "GET" command. 1 Page 12 get is the FAC that controls read access to the file. That is, people who do not "meet" that FAC will not be able to issue GET commands for the file. put if the FAC that controls write access to the file. Usually points to the file maintainers. rfm is the record-format of the file. The first letter is either "V" for "Variable length" or "F" for "Fixed length records", while the second letter will be set to "P" for "Packed format files" or left blank for normal files. Note that packed files will be automatically unpacked prior to being sent to you as a result of a GET or Automatic File Distribu- tion command; however if you obtain a direct link to the disk on which they are stored, you will find them to be in packed format. nrecs is the number of records in the file. Files flagged with nrecs = 0 and dots in the other fields are not yet available but can be subscribed to or stored by their maintainer. date/time is the date the file was last updated, in yy/mm/dd format (this makes it easier to sort the filelist by date). Note that the process of updating the "date" field in a filelist causes this filelist to be flagged as changed and the corres ponding date/time in its entry up the tree structure to be modified accordingly. ******************** * Ordering the files * ********************** GET fn ft Sends you the requested file provided you are authorized to retrieve it. Synonyms have been defined for the GETND, GETDD, GETPP and GET80 commands of Netserv. "GETND xxxx" is translated to "GET xxxx F=Netdata", etc. Note that in this implementation, GETPP and GET80 are strictly equivalents and will cause the file to be sent in Listserv-Punch format if its logical record length is greater than 80. Send an "Info LPUNch" command to LISTSERV for more information about Listserv-Punch format. You can use the GET command, or its synonym SENDME, to request a file to be sent to you. You must specify the filename and filetype of the file as their appear in the filelist, and you may optionally append a third parameter to the command to indicate from which filelist you want the search for the file to start. This parameter is normally not required 1 Page 13 unless there is more than one file available from LISTSERV with the "filename filetype" you are requesting. Application programs who issue GET commands to LISTSERV and know the filelist name should specify it since it speeds up the filelist search. The default is to start at the root filelist, of course. The LISTSERV-standard "file-format" keyword ("F=fformat") is supported on this command. Additionally, synonyms have been defined for the Netserv GETxx commands. Note that the Netserv "GET80" format is not supported by LISTSERV; LISTSERV-punch format is substituted. The LISTSERV "GET" command is compatible with the NETSERV one, with the exception of the GET80 format restriction and with the addition of the optional file-format keyword and filelist_name parameters. The "prologtext" feature of NETSERV is not implemented in the LISTSERV GET command. ********** * Packages * ************ The term "package" refers to a set of program or data files which are supposed to be retrieved together under normal conditions. Provision has been made to allow for users to retrieve those packages with a single command, and to subscribe to it as a whole with updated versions of only the individual changed files being sent out. The package exists independently of its individual components which can still be referenced separately. With each package is associated a dummy file and a definition file. The dummy file has a fileid of "packagename PACKAGE" and does not really exist. However, ordering this dummy file will cause the whole set of files to be sent to you. Similarly, subscribing to this single dummy file will result in a global subscription for all the components of the package. The dummy file should be used whenever reference is made to the package as a whole. The definition file has a fileid of "packagename $PACKAGE" and lists the set of files that are contained in the package. Unlike the dummy file, it really exists and can be retrieved as any other normal file. It will usually list itself as first file of the package so that you can check you have received all the files in the package after ordering it. It may reference another package which is required for the package to be used (any level of nesting is allowed). If you subscribe to a package via Automatic File Distribution (qqv), you will automatically receive updated versions of all the corresponding sub-packages if they are updated. Similarly, ordering the package will cause all subpackages to be sent to you alike. 1 Page 14 *********** * Notebooks * ************* LISTSERV is able to automatically keep notebooks for a list if desired by the list owner. Those notebooks are listed in a special filelist called "NOTEBOOK FILELIST", which is automatically maintained by the server according to the parameters specified in the headers of the various lists. The filelist can be subscribed to via FUI (see LISTAFD MEMO for more information) but AFD distribution has been locked out to avoid generating too much traffic as this filelist is very likely to be updated every day and to be quite large. It can be obtained via the normal GET command. The files listed in the NOTEBOOK filelist are just like normal files and can be retrieved as indicated by the GET File Access Code. They can be subscribed to as normal files, and can even be modified or deleted by the list owners, as indicated by the PUT FAC. However, once the files are deleted they will disappear permanently from the filelist (unlike normal files which would be forced to nrecs = 0). ********************* * Other documentation * *********************** More information about the Automatic File Distribution feature can be obtained from LISTAFD MEMO ("Info AFD"). File owners should retrieve LISTFOWN MEMO ("Info FILEOwner") for more information on the PUT command and internal filelist format. A complete description of the Listserv-PUNCH format (with sample PASCAL conversion program) can be found in LISTLPUN MEMO ("Info LPUNch"). Information about Netserv can be obtained by retrieving NETSERV HELPFILE or NETSERV REFCARD from the nearest Netserv host. . + . * You aren't here . + . . + ] *. * + . * * . ] . + . * .. . + V * . . . . . . . + . + . . * * + + * . . 1 Page 15 ************************************************************************* * Odd Parity * *************************************************************************** Here is the first of many monthly columns by our own Assistant Ediitor, Steve Sutter. We are calling this Odd Parity because, well, it was the only title we could think of at the time. Luckily the title works, since this is rather odd (and you can figure out the Parity bit for yourself). We are rather lucky to have Steve on our staff, partly because he is not yet what you would call a network guru. He is, to put it bluntly, a typical BITNET user. How long this will last, I don't know. One can't work on this magazine and not learn something eventually. In the meantime, enjoy this perspective while you can: - Chris by Steve Sutter SUTTER@YALEVMX Just recently I was looking over the list of nodes connected to Bitnet. I hadn't looked at it in about a year, and was surprised to see how much it has grown. The geographical implications of the list are impressive. I have tried to come up with a few ideas on how this fact can be used. My first idea would be some form of a file server for information concerning travel. I imagine that many people end up traveling to other universities quite frequently. I think it would be very helpful to have a file for each site describing how to get there, where the train and bus stations are, what roads to avoid, and possibly where to stay and eat. A little more ambitious would be a description of the area. I find it aggrevating to see a node name and not have any idea where it is, or what it is like there. I think this would be especially interesting for more distant nodes, and would help to "beautify" the net in general. Although it would take some constant effort, a list of local events would be nice, and while I'm at it how about car pooling information. Incidently, if every site would clean out a basement somewhere and open it up as a youth hostel sort of thing, reservations could be made over the net. Well, maybe I am getting over-ambitious. Another less practical idea would be a newspaper of sorts. This would require a great deal of effort, but it would be sort of like a static relay. It would be nice to see some articles about student life, research accomplishments, and even local news of interest. If enough people responded, it might be possible to come up with weather predictions! Well, anyway I think it would make a good magazine, the Net Community Gazette. Who knows, with enough local input it might even scoop some of the hardcopy newspapers. Maybe it would make a good NetMonth spinoff... Finally, I think the Net itself would be a good place to do research, a virtual laboratory of sorts. I would suggest maybe a digest for the posting of surveys. This would probably have to moderated, but hopefully not too seriously. I think that if the results were also posted, people 1 Page 16 would actually bother to do some of the surveys, especially if they were brief. The only problem is that the survey group wouldn't change much. After all, even a great magazine like NetMonth has less than a thousand subscribers. Well, I will stop rambling now. If any of these ideas already exist, let me know. If you find them offensive and/or stupid, I apologize. Otherwise, think about it, and I will look for the results. ************************************************************************* * The Ethics of Computer Conferencing * *************************************************************************** By John R. Cook UD118169 @ NDSUVM1 The objectives of the present study were twofold. First, an attempt was made to assess the extent to which some traditional moral principles governing face-to-face communication have gained acceptance by the users of computer conferences. This was done by assessing the prevailing community standards for computer conferencing on Compuserve's CB and on BITNET's Relay. The assessment was carried out using email and other message facilities on both of these networks to distribute a 24-item questionnaire entitled Questionnaire for Users of "CB's" and Other Computer "Chats". The second objective of the study was to explore some approaches that might be taken towards distributing questionnaires and collecting data over computer networks. The 25 CB and 112 Relay users participating in the study tended to be male, undergraduate students in their mid-twenties and their average level of education was that of a college sophomore. Six of the CB users also turned out to be Relay users. In terms of their use of electronic journal and mail services, the largest portion of Relay users (21%) were Psychnet subscribers, followed by NetMonth (17%) and COMSERVE (16%). CB users were found to be much more reluctant to participate in the study than Relay users, as evidenced by their lower response rate. Also, Relay users were found to be more accepting of a proposed rule requiring users to register their true names and identities before signing onto the system. Otherwise, there was a high degree of similarity in the responses of CB and Relay users on this survey. The moral or ethical standards for computer conferencing revealed by the survey were found to be largely consistent with the moral principles governing face-to-face communication. One difference between computer- mediated and face-to-face communication was suggested by the conference users' greater acceptance of practices such as adopting nicknames that are considered sexually provocative or sharing details of one's intimate personal relationships on a public channel. However, when CB and Relay 1 Page 17 users were asked to evaluate the potential benefits of computer conferencing, they appeared to discount the importance of some of these practices, in a way that brought them back in line with traditional moral principles governing face-toface communication. In conclusion, it seems we do tend to attach importance to the same sorts of activities both on- and off-line. In this respect, several traditional moral principles governing face-toface communication have been found to be accepted by the users of computer conferences. One area where discrepancies between our on-and off-line ethical standards do tend to occur, is in the larger range of behaviors we are willing to consider as morally acceptable in other conference users. ************************************************************************* * Electronic Chain Letters * *************************************************************************** (Extracted from CSNEWS@MAINE) Recently, the problem of chain letters being distributed by electronic mail facilities is increasing, and the number of complaints received about them is mounting. These letters serve no useful or educational purpose, and are a waste of computer and network resources. For reference purposes, a "chain letter" is any mail message that requests or implies that the receiver should re-broadcast the message to several other users. The phrase "Send a copy of this letter to 20 other people you know" is an example of the type of wording you will encounter in a chain letter. Quite often, you will receive the letter from someone you do NOT know. When you receive a chain letter: when you find that you have received a chain letter, it is a good idea to forward it to the operations manager at your computer center. He or she will be able to take appropriate action, such as contacting the computer center of the person who originally sent the file. For those who might think of sending a chain letter: such abuse of BITNET will not be tolerated by most users and most computer centers. Chain letters are an annoyance to the user community at large, and their broadcast and rebroadcast results only in wasted storage space. If you receive a chain letter, purge it or forward it to your operations manager -- do NOT rebroadcast it. CSNEWS action: if it can be shown that a user or group of users has been involved in the distribution of a chain letter, their access to CSNEWS facilities will be revoked immediately for an indefinite period. If one of the CSNEWS staff receives, directly or indirectly, a copy of a chain letter, he or she may immediately notify the operations staff at MAINE and at the computer center from which the letter originated. 1 Page 18 ************************************************************************* * New Mailing Lists * *************************************************************************** AAI@ALMSA-1.ARPA Digest for discussion of the Automated AUTODIN Interface system. The AAI system is a series of programs that interface a data processing installation (DPI) with an AUTODIN switching center. This digest will provide information to the user community and other personnel interested in the developments/enhancements and implementation thereof. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to AAIREQ@ALMSA-1.ARPA. Coordinator: Jo Ann M. Bohnenstiehl Bob Savacool ISO@NRTC.NORTHROP.COM Discussion group focusing on the ISO protocol stack. The list naturally has some overlap with the ISODE list; contributors are urged to use the appropriate list based on their topic of discussion. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to ISO-Request@NRTC.NORTHROP.COM. Coordinator: Marshall T. Rose NeWS-makers@BRILLIG.UMD.EDU Mailing list for the discussion of NeWS: the Network/extensible Window System. NeWS, originally called SunDew, was written primarily by James Gosling, at Sun Microsystems, who is well known for his Unix Emacs. NeWS is an extensible multitasking window system environment, consisting of a network based display server that is controlled and programmed in PostScript, Adobe's page description language. NeWS was designed to be a portable, device independent window system development platform that runs on a wide range of hardware, in a distributed heterogeneous environment. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to NeWS-makers-request@BRILLIG.UMD.EDU. Coordinator: don@BRILLIG.UMD.EDU 1 Page 19 TRANSPUTER@TCGOULD.TN.CORNELL.EDU The Transputer mailing list was created to enhance the communication among those who are interested in the Transputer and Transputer based systems. Submissions should be of non-proprietary nature and be concerned with, but not limited to: Algorithms Current development efforts (hardware and software) INMOS and third party systems (Meiko, FPS, etc.) Interfaces Dedicated computational resources Occam and Non-Occam language development All requests to be added to or deleted from this list, problems, questions, etc., should be sent to transputer-request@TCGOULD.TN.CORNELL.EDU. Coordinator: Andy Pfiffer ************************************************************************* * The CSNET Information Server * *************************************************************************** The CSNET Info-Server is an automatic program that delivers information by electronic mail. To order a document from the Info-Server, send a message to either 'INFO-SERVER@SH.CS.NET'or INFO-SERVER@CSNET-SH.ARPA. You do not need a subject field. The text of your message must be in a special format, such as: REQUEST: INFO TOPIC: HELP TOPIC: ADR-3 REQUEST: END This request asks for two documents "HELP" and "ADR-3" from the collection "INFO". Your message must have a "REQUEST" line, and one or more "TOPIC:" lines to specify one or more documents. The line "REQUEST: END" is optional; it tells the Info-server to ignore the rest of the message. To send documents to an address that is different from the address in your From: field, please include a Reply-to: field in the header of your message. Do NOT include a Reply-to: or Acknowledge-to: field in the body of the message -- the Info-Server won't recognize them. For each request message, the Info-Server generates a receipt message which includes the list of documents sent, a report of errrors in the request, and, if a Reply-to: field is used, the address in the From: field of the request message. 1 Page 20 The document you are now reading can be requested by: REQUEST: INFO TOPIC: HELP There are currently four REQUEST collections: INFO, RFC, SOURCES and MOD.SOURCES. REQUEST: INFO CSNET general information documents. REQUEST: RFC Documents in the "Request for Comments" series published by the DDN Network Information Center (NIC). REQUEST: SOURCES Files of program sources or information about program sources from CSNET. REQUEST: MOD.SOURCES An archive collection of public-domain programs from the "mod.sources" mailing list, distributed by USENET netnews. These Unix source file have been selected and tested by the mod.sources moderator. The first two volumes of the total of six volumes are now available. Send for the topics HELP and INDEX. You may specify a limit, in lines or bytes, to the maximum size of document that you wish to have sent in a single message. For example: LINE-LIMIT: 1000 or BYTE-LIMIT: 75K The Info-Server will break the documents at exactly the specified number of lines, or at the line preceeding the specified number of bytes. The minimum limit is 250 lines or 19000 bytes. You may use the form "75000" or "75K" in either limit, but NOT "75,000". The limit affects only lines up to the next REQUEST: line. You may combine different requests in the same message, and use any combination of upper- and lower-case letters in your text. You may also include or omit spaces and tabs, use any number of REQUEST and TOPIC lines, and omit "REQUEST: END". REQUEST : info byte-limit: 22000 topic: tbl-4a (Byte-limit in effect) TOPIC: ml-2 Request : rfc TOPIC : rfc822 (Byte-limit not in effect) 1 Page 21 If you include "REQUEST: END", the Info-Server will ignore whatever follows in your message. If you include "REQUEST: ATTENTION", the INFO SERVER will ignore whatever follows and deliver your entire message to "CIC@CSNET- SH.ARPA". (This conforms to MOSIS; we prefer that you send ordinary questions directly to "CIC@CSNET-SH.ARPA.) You are encouraged to suggest additional documents you would like to have available from the CSNET Info-Server. ************************************************************************* * The United States Data Defense Network - Network Information Center * *************************************************************************** This is an automated service provided by the DDN Network Information Center. It allows access to NIC documents and information via ordinary electronic mail. This is especially useful for people who do not have access to the NIC via a direct Internet link, such as BITNET, CSNET and UUCP sites. To use the mail service, send a mail message to SERVICE@SRI-NIC.ARPA. In the SUBJECT field, request the type of service you wish followed by any needed arguments. The message body is normally ignored. The information you request will be sent back to you as soon as possible. The following services are currently available: HELP This message; a list of current services. RFC nnn nnn is the RFC number or the word INDEX. IEN nnn nnn is the IEN number or the word INDEX. NETINFO xxx xxx is a file name or the word INDEX. HOST xxx Returns information about host xxx. WHOIS xxx Returns information about xxx from the WHOIS service. Use "WHOIS HELP" for information on how to use WHOIS. Example SUBJECT lines: HELP RFC 822 RFC INDEX NETINFO DOMAIN-TEMPLATE.TXT HOST SRI-NIC.ARPA WHOIS MKL Send comments or suggestions to SUGGESTIONS@SRI-NIC.ARPA. Send questions and bug reports to NIC@SRI-NIC.ARPA. BITNET/EARN/NETNORTH users should check to see if the information is available from one of the NETSERV file servers (eg. NETSERV at BITNIC) first before requesting information direct from the DDN NIC. 1 Page 22 CSNET users should check to see if the information is available from the CSNET information server (INFO-SERVER@SH.CS.NET) first before requesting information direct from the DDN NIC. ************************************************************************* * The Color and Vision Network * *************************************************************************** by Peter Kaiser PKAISER@YORKVM1 The Color and Vision Network is for scientists working in color and vision research. At present the Network has three major activities. 1. Members' E-mail addresses are maintained and sent to all those in the Network. 2. A key word list that associates scientists and their interests within the areas of color and vision is maintained and distributed. 3. Any person in the Network can have a bulletin, announcement, atc, sent all the other people in the Network. Scientists working in color and/or vision who wish to join should contact Peter Kaiser at: CVNET@YORKVM1 or CVNET%YORKVM1.BITNET@WISCVM.WISC.EDU They will receive the list of E-mail addresses plus a request to provide key words which represent their interests and experience in color and/or vision research. Scientists from Australia, Canada, Germany, Japan, Netherlands, Sweden U.K., and the U.S. are in the Network. They come from universities, research institutes, national laboratories and private industry. The list is growing daily. Peter K. Kaiser York University 4700 Keele St. North York, Ontario, M3J 1P3 Canada * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1 Page 23 ************************************************************************* * Feedback * *************************************************************************** Date: Wed, 21-JAN-1987 21:12 PST From: Don Hosek To: Christopher Condon After seeing the recent flood of letters in the January NetMonth, I just had to throw my hat in the ring. Relay is a valuable but precariously balanced Bitnet resource. I would suggest that those people who dashed off letters to NetMonth defending the relay "clone" read some of the back issues of NetMonth and BitList and learn a little bit about the old style chat machines and the history of Relay. In the days before Relay, chat machines were one of the biggest drains on network resources (and mostly so people could endlessly say "hi.") At an unnamed University I once worked at, for a user services employee to be caught using a chat machine meant termination. Period. Even now, relay use is not encouraged at this site (at least not until they get a Relay of their own, I'm told). The Relay clone while certainly an excellent exercise in Rexx programming, was a danger to the status of Relay. In appearance it resembled Relay, and it certainly was not good public relations for the supporters of Relay who, I am certain, are often called upon to explain misuses of Relay and exceptional "loads" on the network from relay use. I might suggest that any users wishing to learn to use IUCVTRAP or WAKEUP or whatever their heart desires stay away from writing a program that operates as a chat machine unless it is *highly* restricted in the nodes that may use it, i.e., only the host node and possibly those linked directly to the host node. Certainly, don't endanger the status of legitamite network services with "dangerous" programs. -Don Hosek *************************************************************************** Date: Fri, 23 Jan 1987 10:33 SET From: Eric Thomas Subject: Your relay clone To: Niccolo Avico cc: Jeffrey R. Kell , Christopher Condon Nico, I have seen the discussion about the RELAY clone you wrote in NetMonth and would like comment on your sayings (Chris, you can include this mail in the next issue of NetMonth if you want). 1 Page 24 First, we have never accused you nor ESC1040 of usurping the name of RELAY or similar things (just because RELAY is a copyrighted program does not mean that we're going to "scream like Khomeini" if someone re- uses the name -- the main reason to use a different name is to make it clear to users that this is NOT the same program and that complaints/bug reports must be sent to another userid). Anyway you used a different name, so there is NO problem about copyright red tape and suchlike. The main reason why I would like you not to distribute your program to students any more is a purely TECHNICAL reason: although it is probably a very interesting REXX experience, and it can help a new REXX user a lot, a centralized chat machine like your CHATTER is a DANGER to the network. Please consider the following situation: 10 users from the USA are signed up to your chat machine at ICNUCEVM. Every time one of the 10 users sends out a message, it gets redistributed to the 9 other people on the channel. Each of them is, say, about 9 nodes distant from ICNUCEVM on the average so you get a network load of about 80 messages.link (that is, the same load as if 80 messages were being sent on a single link). If the message rate is about 20 messages per minute (that's not much, I've seen worse), you get a load of 1600 messages.link per minute imposed on the network. This is with just 10 users, each sending but TWO messages per minute. With 30 users sending 5 messages per minute, you get a load of 40,500 messages.link!! This means complete saturation of the network lines, ie spool files can no longer be transferred. This does not happen with RELAY since any given message will cross the lines only once and will get redistributed by the receiving RELAY (hence the name). You should know that RELAY has been tolerated by the BITNET Executive Committee ONLY provided that Joe users be made unable to use it during peak hours. If you start allowing US students to use a chat machine during work hours, especially a centralized chat machine on the other side of the ocean, then you are definitely going against the Executive Committee's decision. Now about ESC1040 and "Contact sysops if you see bogus relays!!": you should know that the majority of bogus relays are run ILLEGALLY by students who have somehow obtained the exec. A chat machine imposes a high load on the system it is running on, but also on OTHER systems in the network. The local system contact is responsible for this before the BITNET/EARN community and must be able to justify the load. If a chat machine is causing the network to stop transferring files, HE will get the blame. I therefore find it perfectly normal that no chat machine be allowed without the approval of the system operator at the site. If the sysop has given permission to run the relay and receives a note from someone saying "There is a bogus relay at your node", he will just reply "No, it's an officially approved machine" and the problem will be settled. 1 Page 25 You should know that ESC1040 has done a lot more than just write a chat program. From what I heard he has been abusing his operator privileges to get accounts to run the chat machines on. From what I SAW, he sent the authors of RELAY (including me) a note saying that he was the official system contact person for his node and that his chat machine was developed in collaboration with a the USSR as part of a secret project, etc. This was an insult to the official representative of his node and it is probably the reason why his account was removed, assuming it was (didn't hear about it). His behaviour on his chat machine was unacceptable, I heard him criticizing openly the RELAY system and forcing RELAY users to be signed on his chat machine even though they wanted to get off. Last, but not least, let me tell you that it is VERY unpleasant to receive angry complaints from network users/operators about a problem that is not caused by YOUR program, but by someone else's. I have been in this position several times and I can only agree with Jeff when he says he would like it made clear and obvious that your chat machine is not his. We have no objection to you chat program provided you respect the network (ie limit it's service area to nodes which are very near to your site, which was not the case with the machines ran by ESC1040), and you make it clear that this is a different program (which is your interest as an author anyway). With kind regards, Eric *************************************************************************** Date: Fri, 23 Jan 87 08:46:51 EST From: Jeffrey R Kell Subject: Re: Your relay clone To: Eric Thomas , Niccolo Avico cc: Christopher Condon In-Reply-To: Message of Fri, 23 Jan 1987 10:33 SET from Just to summarize briefly a lengthy note I sent to Chris (I thought this was all over, but didn't get a CC: of Niccolo's last letter)... The primary concerns of mine were, as Eric mentioned, (1) confusion with the real relay, leading to complaints to me and (2) misuse of the EXEC which would lead to executive committee action and/or network trouble. The bottom line of all of this is: the danger here is *who* has the EXEC, not *what* the EXEC is. Even though Relay is somewhat accepted by the network administration, a copy of Relay can be easily hacked to break the rules it is designed to enforce (recall 'Psycho' at Waterloo). These "dark-side hackers" would misuse anything. Perhaps they could, in time, write their own code; but why give them a head start. And why provide "would-be-dark-side-hackers" who can't write one of their own with working code ready to misuse. 1 Page 26 Date: Tue, 27 Jan 87 16:58:27 SET From: Hermann Schneider Subject: ESC1040 (RELAY clone) To: Niccolo Avico cc: Christopher Condon Hi, I read the article in NetMonth about our RELAY clone. I am the senior system programer here responsible for data communication and our EARN connection. To put things right: -ESC1040 was never removed from Bitnet -The RELAY clone was not the only reason to restrict him to use of the network. The reasons are ipurely in the interest of the Agency. Therefore I want to ask Nico not to start shouting against something he doesn't know. Sentences like 'acting histerically like Komeini' are misplaced here (it is you Nico who acts like this). There is also no reason to make the Americans responsible for what has happened. Stay cool and fair! Hermann ************************************************************************* * NetMonth Policies * *************************************************************************** If you have questions or comments about BITNET or NetMonth that you would like printed here, mail your letter to BITLIB@YALEVMX. Make sure that you specify in the "Subject:" header or somewhere in the letter that it is for the NetMonth letters column. This doesn't mean that your letter will be printed, but it helps. Your opinion counts! Article Submissions: The only requirements for NetMonth articles are that they be informative, interesting, and deal with BITNET services (or any other good BITNET related topics). The editor will inform you of any changes to your writing and will submit them for your approval, deadlines permitting. Send your articles to BITLIB@YALEVMX. --------------------------------------------------------------------------- FuzzyBytes Electronic Publishing "Because We're Here."