******** ************************************************** * * * * * The independent guide to BITNET * * * * * * October, 1988 * * * * * * Volume 3, Number 4 * ******** * * * * *** * * * * * * * * * * * * * * * * * * ** * ____ __.---""---.__ ____ * * /####\/ \/####\ * * * (/~~~~~) (~~~~~\) * * * \__OO/ \OO__/ * ****** * __/ \__ * * * .-" . . "-. * * * ] ] \.._ _../ ] ] * * \ \ \."-.__________.-"./ / / * ******** * \ \ "--.________.--" / / * * * ___\ \_ _/ /___ * * * ./ ))))) ((((( \. * * * \ / * * ******\ \_ _/ /****** * ********\ \____/""-.____.-""\____/ /******** ******** **********\ \******************/ /********** * \. .] ]. ./ * *** * ." / ] \ / ] \ ". * * * * ." / ] \ / ] \ ". * * * * /.-./.--.].--.\ /.--.].--.\.-.]. * * * * * *** * * * * ****** * * * * * * * * * * * **** ~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~~~ ~~~ ~~~~~~~ ~~ ~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~ ~~ * ~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~ ~~~ * ~~~~~~~ ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~~~~~~~ ~ ~~~ ****** ~ ~~~~ ~~ ~~~~~~~ ~~ ~~~~~ ~~~~~~~ ~~~~~ ~ ~~ * ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~ * ~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~~~~ ~~~ ~~~~~~~ ~~ ~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~ ~ ******** ~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~ ~~~~ * ~~~~~~ ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~~~~~~~ ~ ~~~~ * ~~~~~ ~~ ~~~~~~~ ~~ ~~~~~ ~~~~~~~ ~~~~~~~~ ~~ * ~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~ **** ~~~~~~~~~~ ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~ ~~~~~ ~ 1 * * * * * ** * * ** ** * * * * * * *** ***** * * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * ***** ***** Christopher Condon Editor CONDON @ YALEVM Timothy Stephen Associate Editor STEPHEN @ RPICICGE Craig White Associate Editor CWHITE @ UA1VM June Genis Contributing Editor GA.JRG @ STANFORD David Hibler Contributing Editor ENGL0333 @ UNLVM Henry Mensch Contributing Editor HENRY @ MITVMA Deba Patnaik Contributing Editor DEBA @ UMDC Gerry Santoro Contributing Editor GMS @ PSUVM Marc Shannon Helpdesk Editor HELPDESK @ DRYCAS Glen Overby Technical Assistant NU070156 @ NDSUVM1 Gary Moss Point of View MOSS @ YALEVM ********************* Contents - Issue 26 ********************* EDITORIAL PAGE_________________________________________________ Bitnotes .................................................... 1 The Human Factor ............................................ 3 Flames To: .................................................. 7 An Oprn Letter to Dr. James Conklin Jr. ..................... 9 FEATURES_______________________________________________________ BIOSCI Novw Available to BITNET/EARN ....................... 12 Four Internet File Servers ................................. 14 The Chaos Mailbox System ................................... 16 DEPARTMENTS____________________________________________________ Headlines .................................................. 18 Feedback ................................................... 19 Policies ................................................... 23 * For information on subscribing to NetMonth, submitting * * articles, sending letters, and printing this file, see * * the "Policies" section on the last pages of this issue. * ----------------------------------------- 1 Page 1 ********* * * Bitnotes * * * * by Christopher Condon * * * * Yale University * * * * CONDON@YALEVM ********* "One size fits all." One of the more frustrating experiences I have to go through is shopping for clothing. Somewhere along the line my body stopped growing at a point where no one keeps my dress-shirt size in stock (15/32), my pants are hard to find (32/30) and my shoes are better suited to a duck (7 1/2 EEE). Somehow all of these factors come together to form a relatively good-looking human being, but finding clothes for him is an exercise in head/wall pounding. Likewise, finding the BITNET service that fits your needs can be difficult. Perhaps the descriptions of the mailing lists to which you subscribed were inadequate, and they weren't what you were expecting. Maybe the file server you were accessing didn't organize its files in any particular way, and you had to wade though alphabetical listings. It might have been that the Relay was not operational during the hours you needed it. As we have mentioned in the past, most servers and services are proviced by volunteers. As such, it is often difficult to criticize their efforts without seeming ungrateful. Not one wants to send someone who has devoted many hours of their own time to making BITNET better a note that says, in effect "Compared to such-and-such, your server stinks." (Substitute your own socially unacceptable adjectives where needed). People either stop accessing these services in favor of something else (often not on BITNET) or they continue because "it's all there is." Everyone loses in this scenario. The users lose time and convenience they could and should have had. The server people lose valuable input. BITNET loses some functionality. The key to resolving this problem is to provide a means of feedback, preferably one which allows some comparisons among different serverices in the same category. For example, what do people like about CSNEWS as opposed to COMSERVE (and vice- 1 Page 2 versa)? They provide similar services to large audiences in different ways. Is there some overlap in their user base? What features make one or the other easier to access? In distributing the latest BITNET USERHELP I have been very lucky in that many people have sent me mail listing comments, corrections, and so on. While people seem to like the document a lot, these changes can make the difference between "very good" and "excellent". The same is true for the servers. You are the users, so you are the experts. Tell the people who run these services what you think. As they say, "the customer is always right". Virtually, Chris Condon@YALEVM 1 Page 3 ********* * * The Human Factor * * * * by T. D. Stephen * * * * Rensselaer Polytechnic Institute * * * * STEPHEN@RPICICGE ********* Believe it or not, there are still people in administrative positions at computer centers who think that undergraduates should be barred from the net. I had assumed that this issue had breathed its last, that the advocates of this type of discrimination had finally realized that their position was ill-considered -- in fact contrary to the best interests of academic computing -- and had changed their minds. Alas, not so. Ill-informed about what actually happens on BITNET and wrong in their assessment of the consequences of student use, the advocates of a student-free network are still out there, like kinks in a garden hose. The POLICY-L "list" jolted to life recently when someone wrote to inquire about arguments that might persuade computer administrators at Southern Illinois University to allow undergraduates to use BITNET. Well known for its excellent university press, its leadership in post-modern scholarship, and its beautiful campus near the Shawnee national forest, it would appear that SIU is also distinguishable as home to one of a small number of computer administrations that continues to hold out against an expanded future for computing in higher education. The keep-students-off-the-net crowd tend to defend their position with three arguments: (a) a bureaucratic argument that claims that student access places undue strain on computer center resources, (b) an economic argument that claims that student access costs too much money, and (c) a moral argument that claims that student message traffic is frivolous and slows down "legitimate" message traffic on the net. I'd feel more hopeful if (c) was the only argument made. If that were the case, we could lay the issue to rest by simply assessing the uses to which the net is actually put. I believe that after spending just one afternoon pursuing this, two things would become abundantly clear: (1) that researchers, professors, and computer center staff engage in quite a bit of "frivolous" use themselves; and (2) that distinctions between "educational" use and "social" use or between use consistent with "research" and use for other purposes would be virtually impossible to defend 1 Page 4 or maintain. Since no one has yet found the royal road to knowledge, it is very difficult to pass judgment on what is educational and what isn't. All that can be said with certainty about the variety of ways of knowing and learning that flourishes in higher education is that protecting and nurturing this variance probably ranks as one of the most noble goals that we in university life can aim for. At any rate, it will take someone bolder than me to say what is an educational use of the net and what isn't. But last December someone from Akron University reported on the UG-L list that administrators banished their students from the net after discovering "...undergrads obtaining obscene and porno material through BITNET...". A similar report from Southwest Missouri State noted that students had been "...discovered using BITNET relays for social chatting, and a small number of students have been discovered sending obscene messages and pictures." Assuming that we are not talking about students of anatomy, human sexuality or art, it could be difficult to extend a reasonable definition of educational use to include exchanging electronic pin-ups or messages that describe sexual intercourse. Frankly, however, I really don't know why anyone cares if consenting students (or faculty) exchange this sort of material or if they use BITNET to do it; every communication medium ever invented has carried sexually explicit messages at one time or another and all new ones will too. Those who would try to eradicate communication about sex may as well try to halt the rain from falling or the trees from losing their leaves in the fall; they have chosen to swim against one of life's most basic and powerful currents. On the other hand, these reports are deeply disturbing in their suggestion that computer center staff have felt qualified to make decisions about what constitutes pornography and obscenity; and, even worse, have apparently not felt timid or guilty about violating the civil rights of their users by reading their mail. Imagine if your dean decided to start eavesdropping on phone calls or opening campus mail. Now there's a way to get your school some attention in the national press! The economic and bureaucratic arguments against student access usually reduce to fairly vague suggestions about student use leading to increased mainframe costs or student access tying up resources and thus interfering with the ability of the computer services unit to fulfill its mission on campus. I'm not a computer center administrator so perhaps I'm thinking about this incorrectly; however, I assume that an idling mainframe costs the university the same to operate as a mainframe that is used to capacity. In other words, the mainframe, just like the 1 Page 5 university's BITNET connection, is a static expense. It seems to me, therefore, that its sensible to look at BITNET as being a little like an all-you-can-eat restaurant: the more of its resources the university can make use of, the better its value. Use of printers, tape drives, and disk packs is another matter, but one that is essentially irrelevant to the question of costs associated with using BITNET. I wonder if one of the roots to the problem might be that some computing centers are funded under a model that actually *is* more appropriate for a restaurant than for a university information center. If schools treat computing resources as though they are consumable goods, people may be tempted to view each use of the computer as though it represented a dollar loss to the institution -- in the same way that a hamburger consumed at a dining hall represents a real expense. If computer administrators take this model too seriously, they may come to view BITNET access as a potential drain on their pool of finite resources. Imagine if the campus library was run on the same model: the more books checked out, the greater the drain on the library. Charges would be higher for checking out hefty tomes like War and Peace than for checking out shorter works. Those who checked out many books would be expected to get a grant to fund their reading. Ridiculous, of course, but only because the university library has come to be viewed as an integral component in the educational process. The more books in circulation -- in fact, the more volumes that there are to circulate -- the greater the mark of distinction for the library and for the university as a whole, and the greater the value of the university library within the academic community it serves. So why aren't computing centers run on the same model as libraries? One reason, I suspect, is that external funding agencies (e.g., the National Science Foundation or the Dept. of Defense) permit universities to charge real money for computer time used toward fulfillment of grants and contracts. To take advantage of this, computing centers have needed to develop accounting systems. The centers need to have a way to show not only what everything costs, but also *that* everything costs. Under normal circumstances, however, funding agencies do not allow charges for time researchers spend using library materials. Thus, there has never been an incentive to think about running libraries on a for-charge basis. But it is important to consider that other point of distinction between libraries and computer centers -- the nature of the mission that they perform on campus. The library functions as 1 Page 6 an integral component in educational practice but the campus computer center tends not to. Certainly you can't have a computer science major without a computer facility, but only a handful of other departments would see the computer center as vital to their undergraduate programs. BITNET brings good reason for this to change. BITNET offers access to educationally oriented network services (e.g., Comserve) and thus invites computing centers to assume an expanded role, one that, in time, will substantially increase the relevance of computing across the academic spectrum. The arguments against students using BITNET are best understood as an expression of a deeper anxiety. The real concern, I suspect, is not over how student message traffic will affect the ability of the net to carry "legitimate" messages or the amount of computer "funny-money" that gets consumed when a student sends an electronic note over the net. It is not even over the degree to which students are responsible in their use of the network. The real concern is the future of academic computing itself. BITNET membership invites computer center administrators and staff to move from their relatively limited (but clearly defined) role in providing researchers and administrators with numerical and textual tools, to a more ambitious though unfamiliar role in facilitating inter- university communication for the entire campus. This move will propel computer services organizations to a center-stage position in educational programs across the disciplines. This is a major evolutionary step and one that may take time for some administrators to come to terms with. Will campus computing centers universally accept the invitation BITNET offers to assume an expanded role in a future of networked education? Of course they will -- the issue has already been decided. Each year more faculty are enthusiastically exploring ways of integrating student use of the network into their courses. They are experimenting with educational designs that use BITNET to connect students with peers across the country and with faculty from other schools and disciplines. The time when computer center administrators will be able to deny students access to network resources is quickly running out. A few schools will hold out, but not for long. 1 Page 7 ********* * * Flames To: * * * * by Craig White * * * * University of Alabama * * * * CWHITE@UA1VM ********* Hello once again, I've been so busy this month that I don't even have a comment about how well my little corner of the net world was connected. I've received too much mail from the lists and have seen a couple of mail-list faux pas. I was very annoyed at one point by some mail that got loose on a couple of the lists that really made my in-box "look" full. Maybe that problem has been fixed. Even so, I am still excited about networks, and continue to find new reason to become even more so. This is another one of those months where I really can't classify what I have to say as a flame, but I feel that these issues need some of your brain bandwidth. I've been writing this column for some months now and I feel that I should give you some information about myself. I work in User Service at the University of Alabama and have been using BITNET ever since our node was connected in 1984. I have been a network fanatic ever since. I am continually trying to persuade friends, acquaintances, and anyone else who will listen to take advantage of opportunities that mail systems and computer networks have to offer. Occasionally people return to me with horror stories of one type or another. This month was one of those months. I have mentioned the Rand book entitled "Toward an Ethics and Etiquette for Electronic Mail" which was written by Norman Z. Shapiro and Robert H. Anderson. As you might know, I think that everyone who uses electronic mail, whether on a computer network, a host based mail system or even PC bulletin boards, should read this book. It discusses many of the potential problem areas involved when people choose to exchange electronic mail instead of using more traditional forms of comunication. I do not keep copies of this publication around to give to these people; rather, I tell them where they can find it and send them on their way. Many times, maybe even most of the time, no one takes the time to find a copy of this book and read it. (By the way it's more like a booklet and you should be able to read it in about the same amount of time it would take to read a news magazine from cover to cover.) Most 1 Page 8 of the horror stories I hear are covered in this book and although it's not quite on the level of Stephen King, I really think that all of you should make the trek to your library and get this book. I would like to give those of you who haven't read the book a taste of what exciting topics are covered. The following is based on a true story (only the names have been changed to protect the innocent). This one is from a friend of mine, we'll call him Fred, in corporate America who's company decided that electronic mail was the way to increase productivity. Their reasoning was sound: there would be no line to report to the boss, they wouldn't have to play telephone tag with co-workers, etc. Things were going great until Fred was told by a friend in another department of a situation that might have some bearing on Fred's department. It seems that Paul, who works in a different group within Freds department, had done a less than bang-up job on an job outside the department. Fred decided that since this related to his department it should be relayed to Ms. Bigg, the departmental boss, so she would be informed in case anything was ever said. He quickly prepared a piece of electronic mail and sent off to Ms. Bigg. As it turned out, Ms. Bigg, who had also been using electronic mail, knew how to forward a piece. Can you imagine what happened? Ms. Bigg forwarded the note to a manager that was over several groups. That manager forwarded it to Paul's manager, who finally forwarded the note to Paul, UNCHANGED. I am of the opinion that you should not send a piece of mail if it would bother you if it ended up typeset on the front page the newpaper. My freind in this case wishes there ware such things as a mail tag that says "this is for informational purposes only, no action required". Electronic mail can be be both a blessing and also a royal pain as evidenced by my friends horror story. Nevertheless, I feel that we should continue to try and make as much use of electronic mail as is possible, bearing in mind the possible pitfalls. As always flames, comments and suggestions to CWHITE@UA1VM. 1 Page 9 ********* * * An Open Letter to Dr. James Conklin Jr. * * * * by Eric Keller * * * * Universite du Quebec a Montreal * * * * FONETIKS@UQAM ********* * Editor's note: Dr. Conklin was recently named Director of the BITNET Network Information Center. Dear Dr. Conklin, I have recently learned via NetMonth that you are the incoming director of the BITNET Network Information Center. I would like to take this opportunity to communicate to you some concerns I have concerning BITNET's operation, concerns that I think need to be addressed as BITNET and its associated networks move into a mature phase of serving a wide variety of needs of a worldwide academic community. I have networked seriously for close to two years. Since March, I have been the editor of foNETiks, a monthly news magazine serving members of the phonetic sciences community. Our magazine typically runs from 30 to 40 pages and presently reaches some 200 email addresses worldwide. As a result, I am a fairly heavy user of BITNET. While reader satisfaction with this rapid means of scientific dissemination runs high, I think some operational concerns need to be addressed at BITNET over the next few years. My main concern is the occasionally haphazard manner in which mail gets delivered. Often, mail bunches up for days and suddenly arrives in gobs. It is certainly strange to be logged on in Quebec and to receive a message from a BITNET site in Indiana saying that the mail sent out a week ago was just delivered. According to reports in recent issues of NetMonth, mail sometimes even gets deleted when mainframe usage is particularly high. With some nodes, a regular exchange of mail has turned out to be impossible because of the delays or the uncertainty that the link entails. I consider that a VERY HIGH LEVEL OF ASSURANCE ABOUT MAIL REACHING ITS DESTINATION WITHIN A REASONABLE DELAY should be at the very top of BITNET objectives. Network mail is no longer a luxury or a lark. It comes close to being an essential service within the academic community, and thus needs to be supported 1 Page 10 with the requisite amount of technical and administrative seriousness. No doubt the BITNET technical staff will be better equipped than I to make suggestions as to how improvements should be implemented. But at least from this perspective, I think that more intelligent routing programs are called for, in order to be able to automatically circumvent nodes that are down or overloaded. Also, some automatic feedback program should be set up to oversee the operation of the whole network, to report on nodes that are down, and to "wake up" support personnel in the affected nodes. Although the lack of strong centralized control is a hallowed tradition of BITNET, some supervision *is* required. It is important to have a mechanism for soliciting the cooperation of nodes that are not pulling the weight they've contracted to pull. Another concern is the explicit or implicit limit on long mail files. Issues of foNETiks often run longer than 100k. Some nodes will simply not accept mail this large, and all of BITNET actively discriminates against large mail file transmission by priorizing the transmission of shorter files. Our present solution is to segment the magazine into 15-page portions and to mail them separately. That may circumvent the problem for now, but it does not address the central issue. The point is that much academic discourse and scientific information quite naturally runs to more than 100k. A small printed science news magazine (like Discover, Psychology Today or Physics Today) contains between 700 and 2000k of information. I don't see why foNETiks should be artificially constrained to 100k. My colleagues and I write papers in international collaboration via BITNET, and many such collaborations generate files longer than 100k. Some of us send data files from one lab to another via BITNET, and these files are seldom shorter than 100k if they are to be useful at all. Yet everywhere we turn, the active discrimination against larger mail files slows us down, and sometimes even imperils the very transmission of our files. I have full comprehension for the physical and economic limits that originally led to the establishment of the small-is-faster philosophy. But the reality is that BITNET is now evolving into a more mature phase of its existence and thus needs to plan ahead to a period where a much larger set of academic needs can be served. One of these needs is the possibility of sending longer files more rapidly and with complete assurance that they do not get deleted along the way. 1 Page 11 This means that nodes will have to make available more substantial resources. More parallel links between nodes should be planned for and established. Letters such as this one should be used to convince computer center support staff in participating nodes that scientific publications and academic exchanges often run much longer than the traditional one-page letter. Long files have a natural place on BITNET and should get more respectful treatment than they do at the present. Finally, I think that access to the other networks should be simplified. In the March 1988 issue of NetMonth, I have commented on some of the difficulties I have encountered in this respect ("Comments of a So-so Happy Crossnet User", pp. 9-11 ). Ultimately, this will only be possible if some simple mail addressing convention is agreed upon by all networks. This will probably involve a high level of abstraction to permit all networks to translate the addressing convention into their particular internal code. Again, the BITNET technical staff will be much better equipped than I to make concrete suggestions. What I am concerned with is that the need for better and more transparent universal addressing be recognized and be translated into the necessary high priorization on BITNET's agenda for future improvements and investments. Before this letter turns into a file longer than 100k, I would like to send you my best wishes for your upcoming term as director. I hope that you will be able to share in some of the concerns I have voiced here, and will be able to do your part in bringing these to the attention of BITNET's regents. 1 Page 12 ********* * * BIOSCI Now Available to BITNET/EARN * * * * by Niall O'Reilly * * * * University College, Dublin * * * * NOREILLY@IRLEARN ********* The Irish National EARN node, IRLEARN, has joined the international network of BIOSCI nodes which provide electronic mail distribution and bulletin board services for biotechnologists. IRLEARN is the fourth such node to date, joining others at the BIONET National Computer Resource for Molecular Biology, Mountain View, California for subscribers in the Americas, Daresbury for subscribers in the United Kingdom (mainly on JANET), and the Biomedical Centre, University of Uppsala, Sweden for subscribers in Scandinavia (mainly on NORDUNET). IRLEARN will be the primary distribution point for BITNET/EARN users, and will also serve users of the Irish Academic Network, HEANET. BIOSCI services provided from IRLEARN will include: * Automatic distribution to BIOSCI subscribers at all BIOSCI nodes of electronic mail messages sent to a BIOSCI address at IRLEARN; * Automatic distribution to BIOSCI subscribers at IRLEARN of electronic mail messages sent to a BIOSCI address at any other BIOSCI node; * A BIOSCI archive from which collections of recent BIOSCI mes- sages may be retrieved by network users; * BIOSCI bulletin boards which will give local IRLEARN users access to the BIOSCI archive. It is expected that the archive and bulletin boards will hold the messages of the current month and those of the immediately previous month. Several different BIOSCI addresses for electronic mail will be available at IRLEARN, as at the other BIOSCI nodes. Each address is intended for messages on a particular topic, and all current addresses are shown below. 1 Page 13 Each address also has a corresponding distribution list at IRLEARN, automatically managed by the Revised LISTSERV software. This software allows network users to become subscribers to any of the distribution lists, and so to receive electronic mail messages sent to the corresponding BIOSCI mail address at IRLEARN or at any of the other BIOSCI nodes. You may, of course, subscribe to as many of these distribution lists as you wish. To subscribe, send the command SUBSCRIBE listname your_full_name to LISTSERV@IRLEARN via mail or message. The BIOSCI listnames are: BIONEWS - General announcements BIOMATRX - Applications of computers to biological databases BIOTECH - Biotechnology Issues SOFT-CON - Information on molecular biology programs EMBL-DB - Messages to and from the EMBL database staff BIOJOBS - Job opportunities GENBANKB - Messages to and from the GenBank database staff GENE-EXP - Gene Expression GENE-ORG - Genomic Organization METHODS - Requests for information and lab reagents MOL-EVOL - Molecular Evolotion ONCOGENE - Oncogenes SOFT-COM - Information on communications software SOFT-PC - Information on PC-software for scientists PIR-BB - Messages to and from the PIR database staff PLANT - Plant Molecular Biology PROTEINS - Protien Analysis RESEARCH - Reseach News SCI-RES - Information about funding agencies, etc. SWISSPRT - Messages to and from the SWISS-PROT database staff YEAST - Yeast Genetics 1 Page 14 ********* * * Four Internet File Servers * * * * by Deba Patnaik * * * * University of Maryland * * * * DEBA@UMDC ********* Mail based servers are simple yet elegant. They run in background all day long and provide access to a large col- lection of files, whcih may contain reports, source programs, binary executables and bulletins. In this month I am reporting four new Internet servers which may be accessed by sending electronic mail. They are: ARCHIVE-SERVER@TITAN.RICE.EDU - This Rice University server stores sun-spots digests, contributed and software for SUN workstations. ARCHIVE-SERVER@SUN.SOE.CLARKSON.EDU - The CLarkson University server offers contributed LaTex and Postscript files. ARCHIVE-SERVER@BCM.TMC.EDU - The server stores NFS (Network File System) bulletins, contributed software for NFS and UNISYS related files. It is run by Baylor College of Medicine WRL-TECHREPORTS@DECWRL.DEC.COM - The server stores abstracts of technical reports and complete reports in postscript format. It also allows you to add your address to the technical reports mailing list and order hardcopy reports. It is run at the Digital Equipment Corpoaration Western Research Lab. These servers use the same software and allow you to write three basic commands: HELP, INDEX, and SEND. The fourth server allows three additional commands; they are: ADD, ORDER and STATUS. Each command must be the first word on a line of a mail message. The server reads your entire message before it does anything, so you can have several different commands in a single message. The server treats the "Subject:" header line just like any other line of the message. You can use any combination of upper and lower case letters in the commands. The files are organized into a series of directories and subdirectories. Each directory has an index, and each sub- directory has an index. The top-level index gives you an overview of what is in the subdirectories, and the index for each subdirectory tells you what is in it. The following 1 Page 15 explainations of the commands are extracted from the help file of the servers. HELP - The command "help" or "send help" causes the server to send you the help file explaining all the commands. INDEX - If your message contains a line where the first word is "index", then the server will send you the top-level index of the contents of the archive. If there are other words on that line that match the name of subdirectories, then the indexes for those subdirectories are sent instead of the top-level index. For example: INDEX or INDEX PROGRAMS or INDEX RECIPES You can then send another mail message to the archive server, using a SEND command (see below) to ask it to send you the files whose names you learned from that list. SEND - If your message contains a line where the first word is "send", then the server will send you the item(s) named on the rest of the line. To name an item, you give its directory and its name. SEND RECIPE AFRICAN-STEW or SEND PROGRAM RCKEEP Once you have named a category, you can put as many names as you like on the rest of the line; they will all be taken from that category. For example: SEND RECIPE CHOC-SHIP-1 CHOC-CHIP-2 CHOC-CHIP-3 The following three commands are supported by WRL-TECHREPORTS server: ADD - If you are not on the mailing list for DECWRL, you can add your mailing address (USPS) by a sending add in the body of your message, followed by your mailing address. ORDER - Allows you to order a harcopy of a technical report. STATUS - This command allows you to check the status of your order. 1 Page 16 ********* * * The Chaos Mailbox System * * * * by Frank Simon * * * * Universitaet Oldenburg * * * * 151133@DOLUNI1 ********* (Translated into English by Thomas Zielke, 113355@DOLUNI1) CHAMAS (the Chaos Mailbox System) is a bulletin board which has been running at Universitaet Oldenburg since April, 1988. It supports the GEONET-standard, developed previously for the GEO1-Mailbox. Commands should be sent to 107633@DOLUNI1. The first command you send should be HELPME, which can be sent via mail or message. You will then be prompted to specify the language (English, French, etc.) which you will be sending commands to CHAMAS. You can then send the command CMD for a list of commands. After subscribing to CHAMAS with the command NICK (a procedure that is only necessary when using CHAMAS for the very first time), one is given the level-3-user privilege class. In the root menu, the following services are offered: PBBS - Public Bulletin Board System OBBS - Official Bulletin Board System INFO - Infos on CHAMAS and its site Oldenburg You can also find special information, i.e. on data networks, in this section. GATES - Gateway to CCC, MCS and CHAMAS-Users SUBNET - nformation from/to Subnet News PD - Public Domain Software Bank MANAGER - User Manager with system-functions PBBS includes read/write-boards like CHAMAS or HACK. OBBS includes read-only-boards like CCC or MCS. Only level-2-users have permission to contribute to these boards, which, however, means that they are responsible for 'their' board. The Manager includes general functions like changing one's nickname, asking for a list of users etc. 1 Page 17 Subnet is a collection of discussion and information groups in Berlin. It is working mainly on Eunet/UUCP by Netmbx. It is like NEWS by UNIDO (for UUCP too). Subscribe to one or more groups and you will get the news whenever the CHAMAS receives something about the groups. These are: General - All on the world CCC - Chaos Computer Club Flame - Politics and Cultur ST - Atari ST UNIX - Unix and Xenix DNET - (dnet.and.sub.general) All on the world sources.UNIX - Sourcelistings for UNIX VMS - Vax/VMS-Operating System sources.MISC - Sourcelistings for the Rest Amiga - Commodore Amiga Nets - Nets and Networking Maps - UUCP-Map (one time in month) Jokes - Oh...i think....jokes OS9 - OS9 Operating System Politik - Politics IBM - Big Blue Science - Science of World Motor - Cars and so on Games - Games and Adventures Most news items are written in German. 1 Page 18 ********* * * Headlines * * * * by Christopher Condon * * * * Yale University * * * * Send your Headlines to BITLIB@YALEVM ********* * From Turgut Kalfaoglu: The are now four TRICKLE software distribution servers in Europe. They are TRICKLE@TREARN, TRICKLE@DKTC11, TRICKLE@BANUFS11, TRICKLE@IMIPOLI Note that PCSERVER@BANUFS11 is gone. They have converted to TRICKLE. * CSNEWS is dead. Long live UMNEWS: As of December 1, 1988 CSNEWS and it's associated userids (CSSERVE, CSNEWSOP, CSBACKUP) will be renamed to UMNEWS (and UMSERVE, UMNEWSOP, UMBACKUP, respectively). Thanks to Andrew Robinson for this update. * The Ozone List and Newsletter: This list and newsletter were set up by people do discuss concerns about about the Ozone layer. To join the list and subscribe to the newsletter, send the following command to LISTSERV@ICNUCEVM: SUBSCRIBE OZONE Your_full_name. Finally archives for the list are sometimes available from LISTSERV@ICNUCEVM and the index can be retrieved by sending the command GET OZONE FILELIST. The editors are more than happy to accept contrivutions to the newsletter. At the moment you can send any material to Terry Sommerville . The material sought includes letters, comments, book reviews, lists of references that you think are good or informative, and summaries of articles. Ideas on how to solve problems are also very useful. 1 Page 19 ********* * * Feedback * * * * A Letters Column * * * * "I'm a little puzzled..." * * * * Send your letters to BITLIB@YALEVM ********* From: Murph Sewall Subject: Name Servers Even before I read June Genis's letter in September's NetMonth, my reaction to WHOIS@ALBNYVM1 and IDSERVER@PSUVM (while recalling NAMESERV@DREW and BITSERVE@CUNYVM -which I'm told is "being phased out") was AARRGGHHH! Proliferation of non- standard named servers with similar, but not identical functions and commands potentially creates as many difficulties as they solve. June really has it right, without a common protocol the noble objectives behind the creation of these servers will be frustrated. Anyone who has subscribed to a list for more than a few weeks has noticed that large numbers of people have difficulty remembering how to use LISTSERV even though list servers have the same name and commands. Name servers at individual nodes make some sense. If I'm looking for the userid of my friend Pete at Albany, WHOIS@ALBNYVM1 is the logical place to look. However, when the need arises, probably months from now, I'm going to have to remember that at Albany it's WHOIS while at Penn State it's IDSERVE but at Drew it's NAMESERV. Then, it'll probably take two or three tries (and some network bandwidth) to get the command syntax matched to whichever server - the problem is obvious. An example of a problem of a different kind exists when the need arises to notify users with similar interests of a new service. When the MBA-L list was created, I used NETNAMES to search NETSERV's UDS (User Directory Service) World-wide for the presences of BUSINESS in the DESCRiptor lists. Even though UDS was relatively new and not widely known outside of computer centers, I found about 30 entries. At present, there is no process that will query node oriented name servers net-wide for a similar list. 1 Page 20 I'm a little puzzled by the editorial comment following June's letter. NETSERV's UDS sure looks like a central name server to me. The NETNAMES EXEC provides straight-forward, user friendly access, which includes the option of requesting replies by mail (I recommend mail for an all nations search; finding all the links to every national NETSERV up at one time is pretty unlikely - I received some replies as much as a week later). Before we'll have any chance of having current data for most active net users into the UDS or any other central data base, we need to do something about the attitude problem at some (I hope not very many) nodes. Several months ago, I asked our bitrep to consider putting the NETNAMES EXEC on the same disk that holds our MAIL software. The problem seems to be a fear that local users might discover that it's there and begin to use it (this is a site that denies students accounts access to BITNET by default and makes exceptions to the blanket policy difficult to obtain). So far, no NETNAMES available mail users generally. I have made one useful discovery. Apparently, LISTSERVs which support the /WHOIS function automatically add names that arrive with any SUBscribe command to the /WHOIS list (if you're subscribed to NETMONTH, chances are that LISTSERV@MARIST knows you). In short, if a person is an active enough net user to have subscribed to a list or two, a /WHOIS query to LISTSERVs in the vicinity of the users node is likely to return the userid. There does not seem to be any expiration for this feature (I know that a query to LISTSERV@MARIST for UCONNVM ids will return a number of ids that haven't been valid for quite some time); perhaps that's correctable? * Editor's note: I have been thinking about that lately and came up with something like this: Every time someone adds himself to a mailing list, he is identifying his interests. What if every list had a keywords for what the list is about, and each time someone adds himself to a list the LISTSERV sends a registration command to a CENTRAL name server. If the key (userid@node) already exists, the keywords are appended to the entry. The user would have the option of accessing this entry and changing it, etc. There could be mirror images of the central server around the network. Each night it would send out a log of all the commands it received to the other servers in order to update them. Add to this an automatic deletion facility like NAMESERV@DREW and you have a pretty neat setup. 1 Page 21 I agree that NETSERV UDS looks like a central name server, but so few people actually register themselves in it that it doesn't serve that purpose very well. Perhaps this LISTSERV modification could send UDS ADD commands to NETSERV, so new servers wouldn't have to be set up. From: Ben Chi Subject: User Directories June Genis, in her letter in the September issue, focuses squarely, I think, on the principal stumbling blocks to implementing global user directory services. The first problem is that of completeness and currency of a centralized server. The success of a centralized server depends crucially on people volunteering directory information to it. All experience up to now suggests that this mechanism is less than totally successful in yielding useful results. On the other hand, many individual sites DO operate local name servers (by whatever name) whose data derive from more-or-less "official" information (e.g., the personnel database) and, as such, are both complete and current. But just as there is no way to compel individuals to enter themselves in a centralized directory or to keep their entries current, so is it impossible to compel sites to implement name servers. It seems, then, that the only way to make any progress is to make the best of what's available and do it in a manner that shapes future developments with an eye toward manageability. To this end, we should 1. Encourage the establishment of more local name servers. In this connection, we need to agree on a common protocol and syntax for directory searches and make server software available to sites that want it. Establish a "directory server," namely a server machine that reports on the whereabouts of name servers. (This is an extension of Genis' point #1.) This needs some thinking out. It may be that a hierarchy of directory servers is what is required, each level of the hierarchy dealing with a more highly delimited group of sites. (The hierarchy could be geographically based, but wouldn't necessarily have to be. An attractive alternative might be to adopt the Internet domain hierarchy more or less unchanged.) 3. Recognizing that there will always be gaps in the server firmament, continue to support a central or some regional name 1 Page 22 servers to accommodate users whose sites don't or won't or can't provide local servers. In summary, then, the scheme involves a directory server (or hierarchy of directory servers) which point the inquiring user to a relevant local name server with "official" name entries if one exists, or to a central or regional name server with "volunteer" name entries otherwise. Having said all this, what next? To get on with it, I volunteer to try to deal with the protocol/syntax problem mentioned in (1) above. Let's start with what exists. If people will send me the help texts for the various WHOIS/NAMESERV/etc. servers currently in operation, I will summarize them and attempt to draft a standard that will serve as a basis for further discussion. Perhaps some others of you can undertake to deal with other parts of the problem. But most of all, let's keep the discussion going. I suggest USRDIR-L as the medium, and will post this letter to that list as well. * Editor's note: A lot of this depends on HOW you expect people to access a name server. The primary purpose, I think, is not to help locate the userid of a specific person, but rather locate groups of people with certain expertise or interests. In this respect, local name servers, or even directories of name servers, won't do the job. 1 Page 23 ********* * * NetMonth Policies * * * * Everything you ever wanted to know... * * * * ...but were afraid to ask. * * * * BITLIB@YALEVM ********* NetMonth is a network service publication distributed free of charge to students and professionals in BITNET and other networks. This magazine and its companion file, BITNET SERVERS, are the work of the BITNET Services Library (BSL) staff and contributors from around the network. BITNET SERVERS is BITNETs list of servers and services. If you know of servers not listed in BITNET SERVERS, or if some listed are no longer available, please contact the NetMonth Editor. * Subscribing to NetMonth and BITNET SERVERS: Send the following command to LISTSERV@MARIST by mail or messgage: SUBSCRIBE NETMONTH Your_full_name A subscriber can delete him/herself from the mailing list by sending LISTSERV@MARIST the command: UNSUB NETMONTH Internet users may use these methods, but must address the mail to LISTSERV@MARIST.BITNET * Back issues: BITNET users may get NetMonth back issues from the file server LISTSERV@CMUCCVMA. For a list of files, send the server the the command: INDEX NETMONTH * Letters to the Editor: If you have questions or comments about BITNET or NetMonth that you would like to see printed here, mail your letter to BITLIB@YALEVM. Make sure that you specify in the "Subject:" header or somewhere in the letter that it is for the NetMonth letters column. 1 Page 24 * Article Submissions: The only requirements for NetMonth articles and columns are that they be informative, interesting, and concern some BITNET-related topic. Send your articles and to BITLIB@YALEVM. * Printing this file: VM users can print this file by using the "( CC" option of the PRINT command. VAX/VMS users should RECEIVE NetMonth with a format of FORTRAN. This will allow page-breaks to be accepted by your printer. _ __- __--- The __----- BITNET __------- Services ___________ Library "Because We're Here." ***************************************************************