******** ************************************************** * * * * * The independent guide to Bitnet * * * * * * January 1988 * * * * * * * Volume 2, Number 6 - 7 * ******** * * * * * *** * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * * * ****** * * * * * * * * * * * * * ******** * * * * * * * * * * * * * * * * * * * * * * * * * * * ******** * * * * * * * * *** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *** * * * * * * * * * * * * * * ****** * * * * * * * * * * * * * * * * * * * * * * ** * * * ** * * *** * * * * * *** * ** ** * * * * *** ** * **** * *** * ** * **** * * * ** * **** * ** * * **** * * ** * **** * * * ** * ******* ** * * * **** * * **** ** ****** * **** * ********** * * * **** * ** ******** ************* ************ * ****** * ****** ************************** ************ * * * ****** *************************************** * * * ********************************************** * * ********************************************** * ******** * ********************************************** * * * ********************************************** * * * ******************************************** * * * * **** ************************************************** 1 * * * * * ** * * ** ** * * * * * * *** ***** * * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * ***** ****** Christopher Condon Editor CONDON @ YALEVM Mike Patrick Contributing Editor PATRICK @ YALEVM Glen Overby Technical Assistant NU070156 @ NDSUVM1 Gary Moss Staff Supervisor MOSS @ YALEVM ******************** Contents - Issue 17 ******************** EDITORIAL PAGE_________________________________________________ Bitnotes / Chris Condon ..................................... 1 The Human Factor / Timothy Stephen .......................... 3 Forty-two / Mike Patrick .................................... 7 Computers and Society Digest / Dave Taylor .................. 8 FEATURES_______________________________________________________ The Bitnet Technical Meeting Agenda ........................ 10 SCUP and the SCUP Newsletter ............................... 12 Domains-style Names in BITNET .............................. 14 The JANET Computer Network ................................. 16 The Listservs with /WHOIS .................................. 17 DEPARTMENTS____________________________________________________ Headlines .................................................. 18 New Mailing Lists .......................................... 19 Helpdesk ................................................... 26 Feedback ................................................... 27 Policies ................................................... 30 * 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. * ----------------------------------------- A publication of the Bitnet Services Library "Because We're Here" 1 Page 1 ********* * * Bitnotes * * * * by Christopher Condon * * * * CONDON@YALEVM ********* "Rolling in the muck is not the best way of getting clean." - Aldous Huxley A roll in the muck is often enlightening, even if it does tend to be a bit messy. I am not, however, suggesting that you lay down in the nearest mud puddle and splash about. Rather, I am using the word "muck" as a synonym for certain animal waste products, the names of which I would most likely be keelhauled for printing. By an odd coincidence, these words serve very well to describe the usual debates concerning students who use BITNET. In a word, muck. The student, it seems, is an anomaly in BITNET. On the one hand he is faced with a globe-spanning network of people and possiblities; on the other he is generally offered little or no guidance on how to access it. When information is provided, it too often answers the question "How?" without ever considering "Why?" I am guilty of this myself. The BITNET USERHELP file and the online BITLIB help system provide plenty of "how-to" information. That, however, is as far as they go. It is up to the user to find an application for this information. For example, a recent addition to BITNET USERHELP was "How to find people in BITNET". The question is valid, but the usefulness of this information is unknown. Who do you want to contact? Why? For the researcher, staff member, faculty member, even graduate student the answer is readily apparent. There is a need for specific information, a task to accomplish. The undergraduate, however, generally has no such need. Presented with the "How-tos" of BITNET, the natural reaction is to explore, experiment, and play. It is this lack of purpose that often makes the student in the network a burden rather than an active member of the BITNET community. The blame for this missing direction does not fall upon the user, of course. The fault lies in the lack of a total plan when institutions join the network. 1 Page 2 If a student is given access to the network, BITNET must be integrated with the curriculum. I have no degree in education, so I am not one to say how this should be accomplished. However, as a recent student, I may be able lend some insight. As a Computer Science major, my interest was not in using BITNET for any particular end, but rather in the network itself and what it offered. A class in telecommunications is idealy suited to this type of information: How the network runs, electronic mail, load issues, Relays, file servers... all of these issues and services are available for hands-on use (virtually speaking). A textbook can't hold a candle to experience. More importantly, an approach such as this gives the student a reason for being here. He may actually learn something in the process. ***** So, how do you like it? This issue launches our big format changes. Some of them are simply cosmetic, and hopefully to your liking. Others are more substantial. The major addition to this issue is the Editorial Page: Thank goodness for kind and interesting people. This month we introduce two regular columnists: The first is Timothy Stephen, one of the people who runs the file/name/what-have-you server COMSERVE@RPICICGE. The title of the column is The Human Factor. This is a play on the title of a branch of psychology called "human factors research" that is concerned with finding out how to make technology easier for humans to use. That will be the central theme of his editorials in coming months. On the other end of the spectrum we have Mike Patrick, a new BITNET user and a good friend of mine. I have brought him onto the staff for the unique reason that he knows nothing about BITNET. Hence, his Forty-two column will present a look at network users from from the outside. This may shed some light on just how absurd what we are doing really is. Of course, as Mike becomes more experienced, he will become just as absurd as the rest of us. Next month we should see Bob Boag (editor of the now-defunct VAX Toolbox) and Judy Molka (of BITNIC fame) emerge as regular or semi-regular columnists as well. 1 Page 3 Of course, all of these people will want to take time off once in a while, so there will be plenty of room for those one-time editorials that I know you are dying to write. As always, I am always open to more regular columnists. Behind the scenes, Glen Overby has been added to the staff to help in keeping BITNET SERVERS up-to-date. Glen came to me with a list of LISTSERV FILELISTS that I had been meaning to put together and never found the time to start. A true BITNET- fan, he will make my life a lot easer, and BITNET servers much more accurate. In the coming weeks we will begin a trial run of weekly magazine, aptly named NetWeek. This will not replace NetMonth, but will rather be a supplement to address our biggest weakness: getting news to you fast. Each Monday NetWeek will summarize the events of the previous week in a brief, concise format. Items covered there will be presented in more detail in more detail in NetMonth. No editorials, no features, just the facts (and a really spiffy logo). Virtually, Chris CONDON@YALEVM ********* * * The Human Factor * * * * by Timothy Stephen * * * * STEPHEN@RPICICGE ********* Bitnet could one day rank as the most important aid to productivity in higher education since the invention of chalk. There's no doubt about this, the net could cause an unparalleled transformation in the business of education. It can link professionals and students who otherwise would never come into contact. By dissolving barriers of distance and time it may irrevocably alter our notion of the university as a physically bounded entity. It can provide, for the first time, a medium for academic interaction where communication is unencumbered by interpersonal barriers such as race, sex, age, and academic status. However, it is a fact that Bitnet remains largely irrelevant in the day-to-day activities of all but a tiny fraction of students and academic professionals. Many don't know of its existence and, of those that do, many don't care to learn how to use it. 1 Page 4 What I want to focus on in this column are some issues that I think are going to determine whether Bitnet evolves, as it should, into an essential academic service or whether it becomes an obscure sideshow, largely irrelevant in the routines of education and research. The data on which I base this discussion are derived from my experiences -- shared with Teresa Harrison, Pete Silvestre, and others -- in the day-to-day operation of Comserve, our file server/listserv combination at RPICICGE. With the exception of Pete, none of us at Comserve claim much expertise in the technology of computing. I've written some messy ForTran programs (the kind that make advanced computer science students like Pete gasp in horror) and I learned enough about CP/CMS and REXX to write the original versions of Comserve and its interface execs. But that's the extent of it. At Comserve we represent and interact daily with that great majority of Bitnet users who care much more about the way Bitnet treats us and the services it provides than about technical issues such as network protocols, domain name structures, data security, RFC822, and similar obscurities. As social scientists and human communication professionals, we tend to be more interested in the social and organizational aspects of Bitnet than in the technical. So my focus in this column is a user's focus rather than that of a system programmer, networking specialist, or site administrator. The fact is that users' concerns and points of view tend to be grossly under-represented in public communications on Bitnet and this is not a healthy indicator for the network's future. The listserv system, for example, entertains all sorts of groups to facilitate the discussion of technology among computing personnel, but not a single list exists for the discussion of users' problems. To be sure, there are lists on which the user is discussed *as a problem* (see some of the recent entries on UG-L, for example), but since the Bitnet Network Information Center (BITNIC) decided last year to stop answering people's requests for information about the network, no other formal channel has emerged to take its place. The naive user is now expected to find out about Bitnet at his or her host site. If the host site doesn't do a good job in supplying this support, well, too bad. Too bad indeed. Our experience at Comserve indicates that host site personnel are often lagging in providing the type of support that users need. There are sites that offer no documentation on Bitnet, that don't provide mailers, and that generally seem uninterested in promoting Bitnet on campus. Although I am probably not unbiased in my view, I 1 Page 5 tend to think of the type of services that organizations such as Psychnet, CSNEWS, and Comserve provide, as, in a small way, revolutionary for the disciplines they serve. For the communication studies discipline, for example, Comserve provides an electronic white pages, a listserv-type discussion system covering various specialties, access to a 400 file database of professional tools and announcements, and some other services. So in December of 1985 we selected 15 sites at institutions with large communication studies programs as targets and sent computer mail to all administrative personnel (an average of about four per site). We included an announcement about Comserve, asked that they consider that faculty and students in their local dept. of communication studies would probably welcome a demonstration of how to use Bitnet to access Comserve, and pointed out that Comserve adds value to their investment in Bitnet access. Not one of the site administrators we wrote to responded or even acknowledged our mail and, as far as we know, not one made contact with their local department of communication studies. Of course site administrators have a lot to do, so why devote staff time to promoting Bitnet? There are two good reasons: one ethical, the other practical. The ethical consideration is that as Bitnet and its services continue to expand, like it or not, site personnel bear an increasing responsibility as the gatekeepers of Bitnet resources. Some have opened the gates widely, heralding Bitnet's capabilities and encouraging faculty and students to try it out. Memoranda are circulated to faculty, announcements are printed in computing center newsletters and staff time is allocated for the provision of workshops, online help packages, documentation, and the maintenance or development of software support systems. But others, for whatever reasons, have failed to effectively communicate about Bitnet to potential campus users. The campus' Bitnet connection is a unique resource because if it is not announced, explained, demonstrated, and otherwise supported, it may as well not exist. At that point it functions merely as a private service for campus computing personnel, a questionable expenditure in these uncertain economic times. On the practical side of this, schools without Bitnet are beginning to lag behind academically. In my field, for example, graduate students and faculty at schools that are not on the net are among the last in the discipline to hear about job openings (they are announced more and more often these days on Comserve and CRTNet) and, of course, whole categories of other services and information are also beyond their reach. But simply establishing Bitnet at a school is not enough. Computer staff need to market it. They need to learn to communicate effectively about it on 1 Page 6 campus and they need to provide the human, textual, software and hardware resources that make it easily accessible and convenient to use. Ultimately, the pay-off for this will come in the form of increased centrality and bigger budgets for campus computing centers. One impact of the fact that this type of activism is not wide spread is that many users are forced to scramble for information on their own. But effective guidance may be hard to obtain, even when proffered by the most well meaning computer center personnel. Here, for example, is an excerpt from a response a systems programmer at one NOS site gave to the question, "What's the largest size file that a user can receive in his/her mailbox?" "At our site, the mailboxes of most users may not exceed 128 PRU's in length. A PRU is basically a disk sector. A PRU is 64 Cyber words in length. A Cyber word, on NOS, is 60 bits long. Upper case characters and most punctuation symbols are represented in 6 bits. Lower case characters and ASCII control characters require 12 bits." Sure, 12 bits. That's a dollar fifty, right? We need to find ways of expressing essential technical distinctions in terms that make sense to a non-technical audience. However good his intentions, the systems programmer who composed this response might as well have not bothered. His conception of the user's frame of reference was so impoverished that he probably generated more confusion that he resolved. Bitnet could be the wave of the future. But whether it arrives on the beach with enough force to make any impact depends upon how effectively its representatives communicate with the academic community and how open they are to soliciting and considering the needs of users. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** ** * * * ** * * * * * ** * * * *** * ** ** ** ** *** ** * * * * ** * * * * * * * * ** *** ***** **** ***** *** ****** *** *** ** *** * ** * *** ** ** *** ********** ***** ********** *** *** ** ***** ** * *** ** ** ******************** ************** ****** ***** **** ****** ** *********************************** ************ *********** ************************************************************* 1 Page 7 ********* * * Forty-two * * * * by Mike Patrick * * * * PATRICK@YALEVM ********* This, the premiere installment of what will probably be a monthly column, will not say anything of pertainance. This is due to the simple fact that at this point I don't know much about what BITNET is, what it does, why it does it. I am somewhat befuddled by Chris Condon's request for me to produce a column for his magazine. Given, I do possess a sparkling wit, and an excellent vocabulary. I'm also a great writer and a vain son-of-a-gun, so it seem I fit in quite well within the editorial context of this publication. Even if my knowledge of computers doesn't go too far beyond Pitfall II on my Commodore 64. Still, if it's a column he wants, it's a column he's going to get. I'll have you know that for the past week (in an attempt to impress you) I've learned more about BITNET than you can shake an abacus at. These are some of my observations thus far: * BITNET users have more knowledge of the computers they use than the people built them. * BITNET users can talk to each other from across continents - a fact in which AT&T would likely be very interested. * BITNET users can very likely break any code and gain entry into any private database in existence (if they so desired). If they banded together for just 10 minutes, they could probably throw the entire world into a perpetual state of higgledy-piggledy. * BITNET users banded together for 10 minutes on a break from the New Orleans NETCON, ans singlehandedly caused the stock market crash. * If you mistakenly dropped a PC Magazine in Hartford, CT, the resulting tremor would cause half the residents of Texas to slide into Charlotte, NC. I told you it wasn't much, but I'm getting there. Last week I couldn't even LIFT a PC Magazine. Honestly, the column will 1 Page 8 become quite a bit more informational as I work to bring myself up to speed on the happenings in and amongst BITNET and its users (Bitnetters? Netties?) while devoting every waking hour to finally becoming "computer literate". But... something just occured to me; an "observation" I failed to observe: * Chris Condon does not get paid to produce this magazine, therefore I will probably not be paid to produce this column. Well, maybe I won't work TOO hard. ********* * * Computers and Society Digest * * * * by Dave Taylor * * * * TAYLOR%ATOM@HPLABS.HP.COM ********* I thought readers of NetMonth might be interested in hearing about The Computers and Society Digest that I have the privilege of editing and publishing electronically on a regular basis. The Digest has been wandering around various networks, with submissions from around the world, for over three years now, and while we try to keep the discussion oriented around the question; What is the Impact of Computer Technology on Society? Extended digressions into other related areas is not unknown. A sample of recent topics include: * BBSing and socialization: A discussion of people that use computers and bulletin-board systems as a replacement for more traditional forms of social interaction, the pros, the cons, etc. * Computer use and the introduction of telephones: This is an extended digression from a discussion about Õpersonalå computers and the third world, where some readers felt that everyone will be thrilled to use a computer once it arrives, and others feel that there is already too much apathy in public-participation issues. The specific is from a 1 Page 9 comparison of the acceptance of the phone system in the early 1900s to the acceptance of computer systems in the closing years of the 20th century. * Education vs. Right Think and Thinking with Hypertexts: What is the purpose of education? Are we supposed to learn how to think, or how to follow the paths of thought and chains of logic of our teachers and peers? How does this relate to HyperText and other systems where the inter-connections between the various sets of information is just as important as the information itself? Specifically, who will be allowed to make connections? * Graduate Programs in Computers & Society: A general information request from a reader. * The Implications of HyperText, and other HyperMedia Systems: Again, more discussion of hypertext. This one is about what it means to our society for our information to be physically linked in specific, well defined ways. * Information and Empowerment: Information, as many people have said, is Power. How does that related to the computer? * Parental Responsibility and Software Piracy: A recent case by Atari demonstrated that the law now considers parents legally responsible for acts committed by their children, regardless of whether they could understand what was going on. Will Atari winning the case and the courts finding the parents of a child software pirate affect the saless of computers to homes? What about the protection schemes? * University Education and Industry Needs: Universities get money from industry to aid in research, but this money has a way of forcing the research to move in more 'marketable' directions rather than simply more interesting or 'promising' directions. How does this affect the ability of our universities to perform reasonable research? What are the long-term ramifications of university research being owned by the company that sponsors the research, rather than the specific university (and by extension the public at large). * What the software market might look like in 1998: Right now it's awkward and trying to find a middle ground between paperback books and the IBM call-your-sales-representative schemes. What about in ten or twenty years? This is a blue sky topic for sure! * Changing Society through activeism and computers: Traditionally, change to society has always been started at the 1 Page 10 grass levels and worked its way up. Now that we have computers and global telecommunications capabilities, can we change this? Specifically, can we utilize our existing technological resources to improve the state of mankind? This discussion is moving to some interesting observations about the lack of a representative demographic cross-section of society too. It's quite an informal discussion forum (but no flames allowed) and I strongly encourage you to either sign up for a few issues or ask the BYUADMIN LISTSERV file archive for a back issue or two: For a sample back issue, send the following command to LISTSERV@BYUADMIN by message or mail: SEND COMSOC-L v3n1 To join the BITNET distribution of the mailing list: SUBSCRIBE COMSOC-L Your_Name ********* * * The BITNET Technical Meeting Agenda * * * * by Scott Earley * * * * EARLEY@BITNIC ********* The BITNIC would like to offer an outline of the topics targeted for discussion. Meetings are held in Working Group format, thus we hope for a particularly high level of commitment into the future. Plans are to run four similar gatherings per year; two preceding each bi-annual DECUS and SHARE meeting. This should allow for maximum participation of the numerous technicians who collectively help to keep BITNET interactive. Objective: To provide a forum for BITNET users to become involved with network-related issues and to develop proposals for submission to the BITNET Board of Trustees. Host: California State University - Fullerton, McCarthy Hall. About eight miles from Anaheim Convention Center, details forthcoming. When: Saturday, February 27, 1988 Time: 8:15 AM for free registration and refreshments 1 Page 11 Structure: The meeting opens with a one-hour Plenary Session at 9:00 after which the Working Groups will break off for the rest of the morning. Following lunch the groups reconvene, allowing time for a summary and wrap-up later in the afternoon. Plenary Session: Chair: BITNET official, TBA Provide an overview of important issues on BITNET; drawing from, but limited to, the topics listed below for discussion by the Working Groups. Working Groups: (please choose one area of interest) 1. Node Management Chair: open * Report on recommendations made at earlier meetings * Essential tags and optimal format for the NAMES/NODES files * Create list of node management tools for BITNET representatives * Discussion of the BITNET/EARN/NetNorth update procedures and coordination * Announcements on new EARN administration * Impact of volume charging on EARN's use of BITNET servers 2. Tools Chair: Jim Gerland * Report on recommendations made at earlier meetings * Determine the appropriate location of servers based on traffic * List the network tools that use the NAMES/NODES files 3. Futures Chair: Bill Rubin * Report on CUNY's new role as SMTP@INTERBIT * Plans for regionalization of Internet gateways * What to do when BITNET reaches a saturation point? * Pinpoint sites to upgrade their lines to 56Kb * What sites should register a domain? * How does one register a domain with BITNET? * Report on BITNIC's registering domains with the SRI-NIC * Status of proposed merge of BITNET and CSNET and/or their NICs? Schedule: 8:30 Free registration, coffee, etc. 9:00 Plenary Session 10:00 Working Groups (3 concurrent tracks, see above) 12:00 Lunch on your own within walking distance 1 Page 12 13:45 Working Groups reconvene 15:30 Break for refreshments 16:00 Summary by Chair of each Working Group 17:00 Wrap-up Arrange BOFs for continuing Working Groups Plans for next BITNET Technical Meeting Review sessions of interest during the week ahead We are looking forward to seeing many of you at the meeting. If you plan to attend please send notice to ATTEND@BITNIC before February 15th. This is not required for attendance, just to provide us with an estimate. ********* * * SCUP and the SCUP Newsletter * * * * by John A. Dunn * * * * SCUP@TUFTS ********* The Society for College and University Planning is an association with a membership of individuals, higher education institutions, related agencies, organizations, and corporations who share an interest in planning in higher education. The society is dedicated to the development of planning to improve the quality and effectiveness of higher education institutions and agencies and to strengthen the planning capabilities of administrators, faculty, and others who have a significant planning responsibility. It provides a forum and promotes activities in which those involved in planning can: advance the state of the art in planning; improve their own and their institution's or organization's understanding and application of the tools, techniques, processes and strategies of planning; exchange information and ideas; advance the professional development of the membership; and widen the base of support for planning in higher education. The mission of the Society will be furthered and its activities supported by frequent and timely exchange of information among members. BITNET seems an ideal medium of electronic communication for this purpose, given the characteristics and purpose of the network and the fact that a large number of SCUP members are at institutions already belonging to BITNET. Use of BITNET will be encouraged in a number of ways: * an initial mailing was sent to all SCUP members inviting them to join BITNET; 1 Page 13 * we will seek opportunities to remind members of the potential benefits of BITNET membership, through mentions in national and regional newsletters and in other publications; * we will encourage the Society's Executive Committee and central office to use BITNET for communications between meetings; * BITNET address requests will be included on Society membership forms and conference registration forms, and the information will be shown in membership directories; * we will compile and maintain a directory of BITNET addresses of SCUP members, to be made available to all SCUP members who request it; and finally * we will publish a periodic newsletter to all members with BITNET addresses. The contents of this newsletter will be selected on the basis of interest and value to the membership, and will evolve over time in response to suggestions. The newsletter is likely to include notices of national and regional SCUP meetings and of other relevant meetings; pertinent news items; identification of useful articles, books, or other materials; requests from members for information on current issues or concerns; job postings of interest to the members; and other time-sensitive information of membership relevance. For a subscription to the SCUP newsletter, send mail to John A. Dunn, SCUP@TUFTS. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** ** * * * ** * * * * * ** * * * *** * ** ** ** ** *** ** * * * * ** * * * * * * * * ** *** ***** **** ***** *** ****** *** *** ** *** * ** * *** ** ** *** ***** **** ***** ********** *** *** ** ***** ** * *** ** ** *** **************** ********** *** *** ** ***** **** *** ** ** *** **************** ********** *** *** ** ***** ******** ** ** ******************** ********** *** *** ** ***** **** *** ** ** ******************** ************** ****** ***** **** ****** ** *********************************** ************ *********** ************************************************************* 1 Page 14 ********* * * Domain-style Names in BITNET * * * * from the BITNET Network Information Center * * * * INFO@BITNIC ********* NOTE: This document has been jointly developed by the BITNET Network Information Center, the Chairman of the BITNET Board's Technical Committee, and Henry Nussbacher. A domain naming convention has been accepted within the ARPANet and the TCP/IP-based networks collectively known as the Internet. Within BITNET, domain-style names are used to provide gateway and routing information to allow convenient mail exchange with non-BITNET connected hosts. This document aims to both facilitate ongoing support of BITNET's domain-style names and to insure that their use does not conflict with Internet-assigned domain names. Within the Internet, domain names indicate administrative organization and not routing, i.e., not transport modes or gateway locations. A formal procedure has been instituted for domain names to be assigned to administrative collections of Internet hosts. Currently the ARPANet Network Information Center has overall responsibility for assigning domain names in the Internet. The Internet and domain names are each documented in ARPANet Protocol Documents known as Requests For Comments (RFCs) available on NICSERVE@BITNIC. The file describing the Internet is named RFC819 STANDARD and the one on domain names is RFC920 STANDARD. Since the Internet domain naming convention provides for mail gateways to non-TCP/IP connected hosts (ref: RFC974 STANDARD on NICSERVE), it is important that the domain- style names used in BITNET not conflict with Internet- assigned domain names. Should the future direction of BITNET warrant it, this would allow the integration of BITNET names within the existing Internet domain naming convention. Feasibility and implementation of such a move are under discussion by the BITNET Board Technical Committee and its Domains Task Force (ref: DOMTASK LISTING on NICSERVE). ARPAnet has requested that all domains that wish to be registered within Bitnet should also be registered within the Internet. 1 Page 15 Domain-style naming conventions have been used within BITNET to allow networks with hierarchical naming structures to coexist with BITNET's flat name space. Typically a BITNET host acts as a gateway into another network with other BITNET nodes routing mail through the gateway host to the other network, based on the network domain name. Support of domain-style names is accomplished using programs (mail transfer agents and mail user agents) that reference tables (ref: BITNET GATES - mail gateway routing information; DOMAIN NAMES - domain routing information) mapping domain-style names to network nodes/gateways to accommodate mail exchange with non-BITNET connected hosts. As such, domain-style names have been used primarily to provide routing information via these tables. This approach to supporting domain-style names should be understood as an expedient and not a long range solution to BITNET's connecting to other networks. (Note also that having a domain-style name entry in one of the mentioned tables does NOT constitute the registration of a domain name; that is, it is NOT equivalent to registering a domain with the ARPANet NIC.) Any site that requests a domain within Bitnet will now be crosschecked against the ARPAnet domain space. Coordination and maintenance of these tables has until now been done on a volunteer basis. In order to meet with the growing demands of the task and to insure the coordination of the BITNET naming scheme with Internet domain names, this process is now being directed by the BITNET Network Information Center (BITNIC). For more information see the document DOMAIN GUIDE from NICSERVE@BITNIC. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** ** * * * ** * * * * * ** * * * *** * ** ** ** ** *** ** * * * * ** * * * * * * * * ** *** **************** ********** *** *** ** ***** ******** ** ** *********************************** ****** ************** ** ************************************************************* 1 Page 16 ********* * * The JANET Computer Network * * * * by Chris Condon * * * * CONDON@YALEVM ********* This article is first in a series on sending mail to other networks. JANET is the Joint Academic NETwork supported by the Science and Engineering Research Council in the United Kingdom. Mail names in JANET, and many other networks, are composed of a set of components which define the target computer. In order of significance the components are: UK this is known as a 'top level domain' AC meaning academic community or CO meaning commercial site for example OXFORD. dept Subsequent components define the machine or a department. Within JANET address components are concatenated with the most significant one first and separated by '.'. For example: ALICE%UK.AC.OXFORD.PHYSICS.VAX This is exactly the opposite of the way in which we are used to dealing with Internet addresses. Normally, the top level domain is at the end of the address. For example: CONDON@VENUS.YCC.YALE.EDU This difference in ordering gives rise to considerable confusion, because the internal JANET address scheme will not work in BITNET. However, your problems will be minimized if you remember this simple rule: Reverse the JANET address so that the "UK" is at the end. For example: ALICE%UK.AC.OXFORD.PHYSICS.VAX would become: ALICE@VAX.PHYSICS.OXFORD.AC.UK There is an id called POSTMASTER at each site for enquiries when attempting to locate somebody. Thus a mail message to POSTMASTER@V1.PH.OX.AC.UK should be received by a human who should be able to reply with useful information. 1 Page 17 ********* * * The Listservs with /WHOIS * * * * by Chris Condon * * * * CONDON@YALEVM ********* All Listservs are not created equal, especially if they are running the new /WHOIS modification by Michael Gettes. The /WHOIS mod adds another area of funtionality to Listserv: that of the name server. The new commands are: /WHOIS where can be a name, userid, or nodename. Use this command to search for information on a person. For example: /WHOIS BITLIB BITLIB is Chris Condon /REGister where is your name. This will add you to the directory of that Listserv. Note that this does not register you in any Listserv other than the one to which you sent the command. Likewise, the /WHOIS command does not search the database of any other Listserv. These commands may be sent either by mail or message. The Listservs which have installed the /WHOIS package thus far are: LISTSERV @ BOSTONU LISTSERV @ CEARN LISTSERV @ ESOC LISTSERV @ FARMNTON LISTSERV @ IBACSATA LISTSERV @ LEHIIBM1 LISTSERV @ MAINE LISTSERV @ OREGON1 LISTSERV @ PORTLAND LISTSERV @ RITVM LISTSERV @ SBCCVM LISTSERV @ SCFVM LISTSERV @ UBVM LISTSERV @ UGA LISTSERV @ YALEVM 1 Page 18 ********* * * Headlines * * * * Smaller pieces of news, but not unimportant. * * * * BITLIB@YALEVM ********* * Last report on the CHRISTMA EXEC: Recently the Associated Press carried a report that CHRISTMA EXEC paid a call on the IBM corporate network, VNET. AP reports that IBM plants in New York, Texas, Kentucky, and Western Europe were affected. They also stated that sections of the VNET network had to be shut down for 45-90 minutes during a production day. (Thanks to John Boncek) * LifeSci Monitor (by Dr. Ami Zakai - RPR1ZAK@TECHNION): Some of you may have noticed a strange phenomenon on Relay lately, mainly a class 0 user called 'LifeSci Monitor'. This user will not answer your questions, which it is hardly surprising since it is a machine. The monitor is part of a larger project called 'LifeSci'. Some of you may have heard about it, I hope all of you will before too long. The LifeSci machine is a research environment consisting of a digest server, a name server, an author server, a BBoard and a conference server. Through out the project we use the available BITNET resources. That is why we chose Relay as our conference machine. RPRLCHT@TECHNION is a crippled Relay machine, written after consulting Jeff Kell, which links to the main relay network and summons a research group to a conference. It then posts a monitor on the channel and logs the conference making the log available to registered LifeSci users. It may also be used in the future to prevent unregistered users from joining closed conferences. I feel that Relay could benefit from the academic usage at this point of its life and hope that projects like LifeSci will help convince the BITNET community that Relay is a valuable research tool and will be used as ammunition against those who try to bring it down. We will welcome your comments, if you want more information about LifeSci feel free to contact us: Yossie Silverman - RPR1YOS@TECHNION or myself, Ami Zakai - RPR1ZAK@TECHNION. 1 Page 19 * New Listserv: Ohio State University (OHSTVMA) now has a LISTSERV. (Thanks to Duane Weaver) * Author's Query (by Terremce Erdt - ERDT@VUVAXCOM): For a directory forthcoming from Paradigm Press, entitled The Electronic Scholar's Resource Guide, I am putting together a section on telecommunications and humanities scholars, which will include bulletin board systems, libraries with catalogs capable of dial-up connections, discussion groups such as HumaNet on ScholarsNet at North Carolina State University, forums such as EPIE on CompuServe, IRList Digest and Humanist on BITNET (HUMANIST@UTORONTO), and bibliographic databases such as BRS and Dialog. I would appreciate any information about additional resources for scholarship in the humanities. ********* * * New Mailing Lists * * * * from List-of-Lists by Rich Zellich * * * * ZELLICH@SRI-NIC.ARPA ********* BICYCLES@BBN.COM Mailing list for topics relating to bicycles including: Racing - How do I get started? What do I need for equiment? Why do they shave their legs anyway? Are there any big races coming to this area? Touring - Where are some great places to ride? Stories of some of your bike trips. What are some of the things I should take for an overnight trip? Commuting - What is the best way to get by major traffic roads? Plus - Equipment, Repairs, Good places to buy a bike, Cars vs Bicycles, Human Powered Vehicles, Fitness, Bike path construction, or anything else you might want to ask or talk about. To be added to the list send mail to BICYCLES-REQUEST@BBN.COM Coordinator: Craig MacFarlane 1 Page 20 CISCO@SPOT.COLORADO.EDU Mailing list for discussion of the network products from cisco Systems, Inc; primarily the AGS gateway, but also the ASM terminal multiplexor and any other relavent products. Discussions about operation, problems, features, topology, configuration, protocols, routing, loading, serving, etc are all encouraged. Other topics include vendor relations, new product announcements, availability of fixes and new features, and discusion of new requirements and desirables. All requests to be added to or deleted from this list, questions, comments, etc., should be sent to CISCO- REQUEST@SPOT.COLORADO.EDU. The list is "slightly" moderated in that you must be validated to send mail to the list. Sending in a request will get you validated, as will reasonable attempts to send reasonable messages to the list. Once you are validated, your messages will be redirected to the whole list without interference. Coordinator: David Wood CMU-TEK-TCP@C.CS.CMU.EDU Mailing list for the discussion of the CMU-TEK TCP/IP package for VAX/VMS. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to CMU-TEK-TCP- REQUEST@C.CS.CMU.EDU. Coordinator: Vince Fuller ETHICS-L Discussions of ethics in computing usually generate more heat than light. This list could do a lot toward generating more light if we do more than trade war stories and opinions of the "I'm right and you're NOT" variety. Of course we can't get any work done without some war stories, since they furnish food for thought. But we shouldn't stop there. Given our experiences, we ought to be able to delineate the basic issues and hot areas in computer ethics. Some current ones have to do with: 1 Page 21 - ownership of information (both data and program files) - what happens when systems programs fail? Is anyone responsible for damage done? Or is the responsibility is the responsibility only for the necessary fix? - responsibility for program failures (Is the company responsible? The programmer? The lead programmer? The project manager? Who's responsible for the "fix"? - how much privacy is reasonable (there are all kinds of levels here; data bases, systems, LANs, networks, etc.) To subscribe, send the following command to LISTSERV@MARIST by mail or message: SUBSCRIBE ETHICS-L your_full_name Coordinator: Gligor Tashkovich GAMES-L%BROWNVM.BITNET@CUMYVM.CUNY.EDU Mailing list dedicated to the discusion of computer games. Games played on any type of system are covered. To subscribe, send the following command to LISTSERV@BROWNVM by mail or message: SUBSCRIBE GAMES-L your_full_name Moderator: Spyros Bartsocas GRiD@STALLER.SPT.TEK.COM AGOG (A GRiD Owners' Group) mailing list. This list is primarily for hobbyist-types who have purchased used GRiD Compass computers. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to jans@TEKCRL.TEK.COM. Coordinator: Jan Steinman 1 Page 22 HYPER-HACKERS@PLAID.SUN.COM Mailing list for folks programming Hypercard on the Apple Macintosh. Please note that this group will be run in conjunction with a soon to be formed USENET group, so if you can read comp.sys.mac.hypercard, you don't need to be on hyper- hackers: it is primarily for the ARPA side of the world that doesn't have USENET. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to HYPER-HACKERS- REQUEST@PLAID.SUN.COM. Coordinator: Chuq Von Rospach IBMTCP-L@CUNYVM.CUNY.EDU IBMTCP-L is intended for discussion of the IBM TCP/IP For VM program offering (5798-FAL). It is also for discussion of the IBM DACU (7170), 8232 LAN Channel Station, 9370 Ethernet adapter and other similar hardware, as they relate to the IBM product, as well as the PC/IP portion of the product. To subscribe, send the following command to LISTSERV@CUNYVM by mail or message: SUBSCRIBE IBMTCP-L your_full_name Coordinator: Bill Rubin INFO-ALLIANT@ANL-MCS.ARPA An unmoderated mailing list for the discussion of Alliant computer systems. Software, programming techniques, and bugs are more than welcome. All requests to be added to or deleted from this list, problems, etc., should be sent to info-alliant-request@ANL- MCS.ARPA Coordinator: Gene Rackow * * * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * ** ** ** * ** *** * * * ************************************************************** 1 Page 23 INFO-CSCHEME%OZ@MC.LCS.MIT.EDU BUG-CSCHEME%OZ@MC.LCS.MIT.EDU CScheme is MIT's main implementation of Scheme, and these mailing lists are implementation specific. There is a Scheme language (implementation independent) mailing list (SCHEME@MC.LCS.MIT.EDU), but CScheme specific messages are often sent to it by mistake. Other subscribers get annoyed, and the volume of network traffic is greater than it should be. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to INFO-CSCHEME- REQUEST%OZ@MC.LCS.MIT.EDU. Maintainer: Chris Hanson INFO-ULTRIX Mailing list for discussion of ULTRIX operating system topics. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to felix!info-ultrix- request@HPLABS.HP.COM. Nanny-Users@XHMEIA.CALTECH.EDU Mailing list for people using the Nanny package written for VAX using VMS. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to Nanny-Users- Request@XHMEIA.Caltech.Edu. Coordinator: Perfect Tommy POLYMERP Polymer Physics Discussion. The topics include meetings, articles, software, theories, materials, methods, tools, polymer properties such as solubility, viscosity, self- diffusion, and adsorption. To subscribre, send the following command to LISTSERV@CUNYVM by mail or message: SUBSCRIBE POLYMERP your_full_name 1 Page 24 Coordinator: Jan Scheutjens ROOTS-L Genealogical Issues: Tools, techniques, and requests for information on genealogical research. The list may also be helpful in doing the research by sharing information on specific ancestors, cooperative research, etc. (See also soc.roots on USENET/NETNEWS news). Monthly public notebooks are kept. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to the Coordinator. Coordinator: Alf Christophersen RSTRAN-L Unmoderated mailing list intended for discussion among RSCS systems programmers who are interested in the Yale Transparent linedrivers for RSCS Version 2 on an IBM 7171. The original modifications made at Yale for release 1 of version 2 are available from the list by requesting RSTRAN-L PACKAGE. It is Yale's hope that interested parties who migrate the mods forward for later maintenance levels will send the updated mods to SUSAN@YALEVM so that they can be made available to all. To subscribe, send the following command to LISTSERV@YALEVM by mail or message: SUBSCRIBE RSTRAN-L your_full_name Coordinator: Susan Barmhall TURBOC-L The TURBOC-L list is for Turbo C questions, tips, code, bug reports and any other Turbo C related areas of interest. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to the coordinator. Coordinator: Jim Ennis 1 Page 25 WEIRD-L Mailing list for all manner of weirdness; the local group with which we started concentrates on cutups and short bizarre stories, but anything strange is welcome. As distinguished from the old Bizarre-People list, we're not looking for humor but more for disturbing things. Requests to be put on the mailing list should be addressed to the Moderator, and should be accompanied by a submission. Moderator: Jeremy Bornstein YTERM-L Unmoderated mailing list intended for discussion of problems or concerns with the Yale Terminal Emulation software package. YTERM is a useful VT100 emulator and may be used with the IBM 7171 protocol converter and previous versions of the Yale ASCII terminal communication system. File transfer with YTERM is accomplished with PCTRANS host software. PC to PC file transfer over an asynch line is also possible with YTERM. To subscribe, send the following command to LISTSERV@YALEVM by mail or message: SUBSCRIBE YTERM-L your_full_name Coordinator: Susan Barmhall * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** ** * * * ** * * * * * ** * * * *** * ** ** ** ** *** ** * * * * ** * * * * * * * * ** *** ***** **** ***** *** ****** *** *** ** *** * ** * *** ** ** *** ***** **** ***** ********** *** *** ** ***** ** * *** ** ** *** **************** ********** *** *** ** ***** **** *** ** ** *** **************** ********** *** *** ** ***** ******** ** ** ******************** ********** *** *** ** ***** **** *** ** ** ******************** ************** ****** ***** **** ****** ** *********************************** ************ *********** ************************************************************* 1 Page 26 ********* * * Helpdesk * * * * a Question and Answer column * * * * BITLIB@YALEVM ********* One of the ideas for the revised NetMonth format was the addition of a column for questions and answers. To start off this series of articles we have decided to take care of the the obvious (if less than serious) questions. Next month I will begin to answer real questions about real problems. I know you have questions. Send them in! If we can't answer them, we'll find someone who can! *Q* How much wood would a woodchuck chuck if a woodchuck would chuck wood? About 2.73 cords per hour, depending upon the type of wood chucked and the softness of said wood. Saplings take slightly less time and are quite a bit more tasty than the older varieties. Petrified wood is unacceptable. *Q* My husband likes to dip himself in Sweet-and-Sour-Sauce and runs around the house, clucking like chicken. What should I do? I think you have me confused with Ann Landers. *Q* Didn't you graduate? Yes, I did. I'm still here. Fancy that! *Q* How long does it take you to produce the typical NetMonth? About 1.21 hours per page, depending upon the type of article produced and the intelligence of said article. Intelligent articles take slightly more time and are quite a bit more readable than the stupid varieties. Totally inane articles are unacceptable. *Q* Why do you do this? Are you crazy or something? Or something. 1 Page 27 *Q* Will we ever get to read real questions in this column? Only if you send them in. *Q* But where do I send them? Send mail to BITLIB@YALEVM. ********* * * Feedback * * * * Yes votes, No votes, Dosey-dotes... * * * * BITLIB@YALEVM ********* From: Frank Elsner Subject: The -new- NetMonth Magazine I'd like to make the following comments on the ideas for a new NetMonth Magazine. I agree to the idea to include a "Question/Answer" section, but be careful, this might reproduce discussion on the INFONETS@BITNIC or on MAIL-L@BITNIC. But, of course, gives the chance to inform all the network people about a problem and the discussion about it in a summarized form. An "Editorial Page" might be a nice place to inform about experiences, tips and tricks or something similar. The encreasing number of questions of the form '... how to reach an user in BONGONET ...' shows the necessity to include informations on other networks. Good idea. (Don't ask me what BONGONET is :-) B U T :- I can't agree to the idea to desktop-publish the magazine. Of course, the possibilities are great, but what about the distribution? The great advantage to distribute via the (fast) network will be lost, you must use Snail Mail. This leads to wonderfully designed info, but it is not up-to-date when it reaches the reader :- * * * * * * * * * * * * * * * ** * * * * * * * * ** * ** ** *** * * * ************************************************************** 1 Page 28 From: Mads Ledet Subject: Comments on November Some general comments which you may edit as you wish. Probably some of these comments should go to POLICY-L but they may be useful here, too. BITNET has grown enormously as a volunteer operation and that success is causing problems. Much of the success may be due to the volunteer factor, i.e., some dedicated people put in many extra hours to make it work because they find it to be useful or interesting to them. But this volunteerism makes it difficult to have and enforce standards. And the end result may be workloads (on volunteers and computers) which increase exponentially? as traffic grows. Some general questions and observations: 1. Every node should be required to have a name server. And I mean a standard name server with standard commands. This requirement could be at an institution (domain?) level instead if the domain agrees to certain levels of service. It should be noninteractive so it can be run late at night. Shouldn't it be possible to have a standard package which can be provided to an institution to minimize the effort involved? 2. To what extent should standards be pushed for other parts of BITNET such as List servers, gateways, relays, domains, special interest groups, etc? The intent here is to promote a level of service which >reduces< the workload on volunteers or, at least, doesn't increase it as network traffic grows. From my perspective, it takes a certain amount of magic to be successful in using BITNET. This magic translates to more work for some volunteer to help me find the right button to push. To what extent does the present freedom create the problems? For those of us that grew up in small rural towns with hundreds of independent telephone companies, the area codes, direct dialing, etc., are light years ahead. BITNET seems to be somewhere in between those two extremes. 3. I applaud your hard work in putting out the newsletter. I think it should remain electronic. Mailing it out may increase readership but that approach doesn't seem to fit BITNET. From: Lynda Sloan Director, Computing Center Iona College Subject: Proposed Format For NetMonth I like your proposal to a hard-copy format of NetMonth. I think it would make the publication more attractive and more 1 Page 29 readable. It would also be something that could be more easily disseminated on my own campus. I read NetMonth regularly and find that the current format is not suitable for dissemination to others. I don't know if it would make a difference to me but some people might be encouraged to contribute to a hard-copy publication rather than an electronic one. From: Eric Thomas Subject: RELAY@TCSVM Note that I had shut my relay down before John. Its CPU use had sprang up from 2h/month to 20h/month, 15 of which were in the last week. The trend was therefore 60h for the next month, which was utterly unacceptable (as a rule of thumb, anything in excess of 4h/month had been had a good reason to exist in this shop). There were also 150 users, etc. Same symptoms. Jeff is working on it, we discussed several possible solutions and he's implementing... From: Judith Molka BITNET Network Information Center Subject: RELAY and BITNIC In the November issue of the NETMONTH electronic mail magazine, 200 lines of material were complaints about how BITNIC was running RELAY. Although these grievances may be legitimate, no one on the BITNIC staff was ever forwarded a copy of this conversation. Your magazine has a wide readership. I realize posting BITNIC flames shows impartiality on your part, and makes interesting reading too, but in this case it was not constructive. It would have been better for one person to forward the groups concerns to Scott Earley (EARLEY@BITNIC) or to myself. Then if our response was not pleasing, and prompted other remarks, that would be news. About RELAY@BITNIC, the software was introduced to the BITNIC machine back in the days when there was a BITDOC at CUNY and a BITNIC at Princeton with a total staff of about 8+ persons. Today there are 4.3 people are working on the BITNIC project. Since we are not at a staff level to properly support RELAY, the BITNIC will be removing the software. If members of the RELAY-L list wish to comment on our decision please contact me thru Jeff Kell. I am not subscribed to RELAY-L@UTCVM and cannot contribute to the list because it is set to Send=Private. 1 Page 30 ********* * * NetMonth Polices * * * * Everything you ever wanted to know... * * * * 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 (BITLIB) staff and contributors from around the network. BITLIB is an online help system designed to provide Yale network users with information about services available to them through Bitnet, as well as instructions and utilities for their use. The BITLIB system is now distributed to more than thirty educational institutions worldwide. In publishing NetMonth the Yale BITLIB staff hopes to promote a productive and enjoyable networking environment for everyone. 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 Internet users may use this method, but must address the mail to LISTSERV%MARIST.BITNET * Back issues: BITNET users may get NetMonth back issues from the file server NICSERVE@BITNIC. NetMonth is also available to Internet users through FTP to GARP.MIT.EDU (login ANONYMOUS, directory PUB). Several back issues are also stored there. A subscriber can delete him/herself from the mailing list by sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command. * Letters to the Editor: If you have questions or comments about BITNET or NetMonth that you would like to see printed 1 Page 31 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. * 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 first copying it to NETMONTH LISTING and then printing the new file. This will allow page-breaks and other formatting to be accepted by your printer. --------------------------------------------------------------- A publication of the Bitnet Services Library "Because We're Here."