* * * * * ** * ** ** * * * * * * * * * * * * * * * *** ***** * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * * * * A monthly guide to BITNET servers and services * ******************************************************* Volume 1 Number 3 - September 1986 Editor: Chris Condon BITLIB@YALEVMX Bitnotes ............................................ 1 The Proposed BITNET Charter ......................... 2 Announcing COMSERVE ................................ 4 New Mailing Lists ................................... 7 The Hewlett Packard Public Networking Newsletter .... 9 CYBSERV ............................................ 10 Coming Soon: GRAND ................................. 11 More New LITSERVs .................................. 11 The RELAY Rules .................................... 13 Feedback ........................................... 16 NetMonth Policies .................................. 17 _______-----___--______________________________________ ____------------------_________________________________ _-----__-----------------______________________________ ---____----__---_----_-----____________=======_________ -_____---___----_----___----________=============______ ______-____----____--_____---______===============_____ _________----________-_______-_____===============_____ _______----_________________________=============______ ______----_____________________________=======_________ ____----_______________________________________________ __-----________________________________________________ ------_________________________________________________ ---------_________________________________________----- -----------------____________________------------------ A complete list of servers and services is available from any NETSERV file server as the file named BITNET SERVERS. News, article submissions, additions to the list of servers and services, subscription requests and letters to the editor should be sent to BITLIB@YALEVMX. Subscribers are also sent BITNET SERVERS updates. Printing this file: VM users can print this magazine by first copying or renaming it to NETMONTH LISTING and then printing it with your local file printing command. ------------------------------------------------------- FuzzyBytes Electronic Publishing "Because We're Here." 1 Page 1 ************************************************************************* * Bitnotes Issue 3 * *************************************************************************** If "everybody knows" such-and-such, then it ain't so, by at least ten thousand to one. - Robert A. Heinlein Everybody knows about the new Relay rules, right? And everybody knows about the proposed BITNET Charter. Hmmmph! Probobly not. Many of the more informed readers out there are aware of these things, and my apologies to you. As for the rest of you, I have taken the liberty of including both documents in this issue of NetMonth for your perusal. But before we go any further, I want to stress that these documents are not (shall I repeat that?) NOT in their final forms. They are still subject to intelligent debate and modification. However, they should prove to be interesting reading. The new Relay rules: I find them to be pretty reasonable. They strike a fair balance between what Relay is generally used for (recreation) and network load. The additional user class (for channels above 999) is good way to highlight Relay's educational possibilities as well. The usage guidelines are well drawn out and nobody should have any problems following them. Best of all, it gioves the Relay Operators the power to enforce them. The BITNET Charter: This will probobly be subject to a lot of change before the year is out. There are a few provisions missing yet (like requiring the Executive Committee to print the minutes of it's meetings, which it does anyway) but those changes are probobly being written as you read this. Most of all there has been a lot of debate over the possibility of annual BITNET membership fees (for the node, not the user) which hasn't been entirely settled. Stay tuned for the final solution. On the lighter side, we have TWO new servers, COMSERVE and CYBSERV. I must say that COMSERVE is the first file server I have used that is easier to use WITH the user interface exec than without. Unfortunately VAX users will have to do without it. CYBSERV, a mail based file server, will provide some much needed support for people using Control Data Corporation Cyber computers. (Cyber sites cannot send interective messages so they miss a lot of the avialable BITNET services. Also among the good news are some more revised LISTSERVS, a preview of the GRAND servers, and an electronic magazine for HP3000 users (all three of you). Somewhere in here is the usual article about new mailing lists. Of course, you'll find the Feedback letters column at the tail end of the magazine. Enough of this. Read on... Virtually, Chris 1 Page 2 ************************************************************************* * The Proposed BITNET Charter * *************************************************************************** The BITNET Executive Committee Post Office Box 364 Princeton, New Jersey 08540 (EXCMTE-L@BITNIC) BITNET CHARTER July 23, 1986 Edition 1.4 Purpose BITNET is chartered by its Class A and B member institutions for the purpose of facilitating non-commercial exchange of information consistent with the academic purposes of its Class A and B members. History BITNET, which originated in 1981 with a link between CUNY and Yale, grew rapidly during the next few years, with management and systems services provided on a volunteer basis largely from CUNY and Yale. In 1984, the BITNET Directors established an Executive Committee to provide policy guidance. Funding from IBM in 1984 to EDUCOM and CUNY for a BITNET Network Support Center provided formalized information, management, and system services for BITNET. At the end of 1986 this funding will end, and alternative sources of support for these activities will be needed. Membership There are four classes of membership: Class A members degree-granting institutions of higher education Class B members certain consortia and affiliates of institutions of higher education Class C members certain non-profit organizations Class D members certain other organizations These and other membership rules may be modified and promulgated from time to time by the Executive Committee. 1 Page 3 Membership Representatives Each member institution or organization will designate 3 representatives as follows: 1. Institutional BITNET Director--official representative to BITNET. 2. Technical Representative--an individual appointed by the Institutional BITNET Director who can speak for the status of all the computers connected to BITNET at that institution. 3. Information Services Representative--an individual appointed by the Institutional BITNET Director who is responsible for disseminating information about BITNET to end-users of each BITNET node at the institution. Executive Committee All responsibility for policy, business, and technical affairs of BITNET is vested in the Executive Committee which consists of eleven Class A or Class B Institutional BITNET Directors plus non-voting representatives from other major academic networks, as invited. The Executive Committee will hold an annual meeting within three months following the annual election, and at any place designated by a majority of the Executive Committee, such designation to be made at least four weeks prior to the meeting. Other meetings will be via BITNET or in person, as required. The Executive Committee will choose its own officers annually. Executive Committee members are normally elected to three year terms beginning on January 1. In order to ensure continuity, the current Executive Committee, functioning prior to ratification of this Charter, will choose four of its members by lot to have their terms expire on December 31, 1986, four to expire on December 31, 1987, and three to expire on December 31, 1988. The electorate for the Executive Committee and those eligible for election comprise the Institutional BITNET Directors of the Class A and Class B members. Elections are held in November of each year as follows: o The Executive Committee will nominate at least two persons for each vacancy and communicate same to the electorate, while simultaneously soliciting additional nominations supported by at least ten petitions from the electorate. o Three weeks will be allowed for petitions. o At the conclusion of the petition period, ballots will be distributed, to be returned within three weeks. 1 Page 4 o For an election with N vacancies, the N highest vote-getters will be declared elected. o Any mid-term vacancies will be filled at the next annual election. Interim appointments may be made by the Executive Committee. o An individual elected to the Executive Committee may continue to serve as long as she/he remains an Institutional BITNET Director at any institution. Membership Fees The Executive Committee has responsibility for establishing membership fees as required to maintain stable electronic communication services with a high degree of academic connectivity. Other Networks The Executive Committee will maintain liaison with other networks having similar purposes, as required to extend BITNET connectivity worldwide. BITNET Services The Executive Committee may enter into an agreement with a suitable entity capable of providing BITNET management, fiscal, and legal services. Ratification and Amendment This charter will be ratified upon affirmative vote of a simple majority of the existing BITNET Directors who return ballots in a special election for this purpose. After ratification, this charter may be amended upon initiation by either the Executive Committee or petition presented by 20% of the Institutional BITNET Directors, and affirmative vote of two-thirds of the Institutional BITNET Directors who return ballots. ************************************************************************* * Announcing COMSERVE by Timothy Stephen & Teresa M. Harrison * *************************************************************************** Comserve is a resource for students and professionals interested in the study of human communication. It is a free information service that you can use to obtain materials to assist your teaching and research activities. You can also use Comserve to locate information about people in the profession, to share your own work, to request information or resources from others, or to advertise your department's programs of study. 1 Page 5 Comserve is an interactive computer program that can intercept and interpret commands sent to it over BITNET. It is capable of reading electronic mail that it receives and acting on commands it finds in the text of the mail message. Comserve can also respond conversationally for users whose computers have this capability. Comserve maintains a growing collection of bibliographies, research instruments, announcements of professional meetings and grant opportunities, syllabi, class exercises, job announcements, and other resources of relevance to the field of communication studies, broadly defined. Comserve also manages an electronic phone book -- much like the SCA Directory -- that you can use to locate information about others in the discipline. You can command Comserve to tell you about its collection of resources, to send you a copy of a particular file (bibliography, syllabus, etc), to add information about yourself to the phone book, or to search the phone book for information about others. In the normal case, Comserve respond to your commands within an interval ranging from about 5 seconds to a maximum of about 20 minutes. You can also use Comserve as a means for advertising your department, yourself, or the conference you are planning, for posting questionnaires that other users can obtain from Comserve and return to you electronically, or for sharing your learning resources. You can start using Comserve now by sending mail or conversational commands to COMSERVE@RPICICGE. Users of IBM VM/SP (CMS) systems should send Comserve the command: SEND EASYCOM EXEC to obtain an interface program that can be used to simplify interaction with Comserve. (After you receive the program, simply type: EASYCOM.) Printed copies of Comserve's documentation can be obtained by sending a request to either STEPHEN@RPICICGE or HARRISON@RPICICGE. An electronic version of the documentation will be available from Comserve soon. The range of commands available to Comserve users is different depending on whether Comserve is being used conversationally or commands are sent as mail messages. Currently, Comserve will recognize the following conversational commands: COMMAND ACTION ADDME Add yourself to the user directory DELETEME Delete yourself from the user directory DIRECTORY Get lists of available files FEEDBACK Send us your comments 1 Page 6 FORTUNE Read a fortune cookie GOODBYE Say goodbye to Comserve HELLO Say hello to Comserve HELP Get help on using Comserve NEWS Read the latest news file NEWFILES Find out if new files have been added PREVIEW Preview a file before requesting it SEARCH Search the user directory SEND Obtain your own copy of one of Comserve's files Specific methods for sending conversational messages over BITNET are different on different computers. Most IBM VM/SP (CMS) computers accomplish this with the "TELL" command. For example: TELL COMSERVE AT RPICICGE HELP sends the Help command to Comserve. Many VAX/VMS systems use the "SEND/REMOTE" command to accomplish the same function. For example: SEND/REMOTE RPICICGE COMSERVE "HELP" Users accessing Comserve through electronic mail may issue any of the following commands: COMMAND ADDME DELETEME DIRECTORY FORTUNE HELP NEWS NEWFILES SEARCH SEND Simply place the command in an electronic note and address the note to COMSERVE@RPICICGE. Comserve is offered through the cooperation of the Center for Interactive Computer Graphics and the Department of Language, Literature, and Communication -- both at Rensselaer Polytechnic Institute. It is sponsored by the Eastern Communication Association and has been endorsed by the Committee for Computer Applications and the Legislative Council of the Speech Communication Association. 1 Page 7 ************************************************************************* * New Mailing Lists * *************************************************************************** INFO-FINITE@ARDEC.ARPA Info-finite is a mailing list for the discussion of problems, solutions and theory in finite element software. All requests to be added to or deleted from this list, problems, questions, etc., should be addressed to info-finite-request@ARDEC.ARPA. Coordinator: Ken Van Camp NL-KR@ROCHESTER.ARPA NL-KR is open to discussion of any topic related to the natural language (both understanding and generation) and knowledge representation, both as subfields of AI. The Moderator's interests are primarily in: Knowledge Representation Natural Language Understanding Discourse Understanding Philosophy of Language Plan Recognition Computational Linguistics Contributions are also welcome on topics such as: Cognitive Psychology (as related to NL/KR) Human Perception (same) Linguistics Machine Translation Computer and Information Science Logic Programming (same) Contributions may be anything from tutorials to speculation. In particular, the following are sought: Abstracts Reviews Lab Descriptions Research Overviews Work Planned or in Progress Half-Baked Ideas Conference Announcements Conference Reports Bibliographies History of NL/KR Puzzles and Unsolved Problems Anecdotes, Jokes, and Poems Queries and Requests Address Changes (Bindings) This list is in some sense a spin-off of the AIList, and as such, a certain amount of overlap is expected. The primary concentration of this list will be NL and KR, that is, natural language (be it understanding, generation, recognition, parsing, semantics, pragmatics, etc.) and how we should represent knowledge (aquisition, access, completeness, etc. are all valid issues). Topics deemed to be outside the general scope of this list will be forwarded to AIList (or other more appropriate list) or rejected. 1 Page 8 All requests to be added to or deleted from this list, problems, questions, etc., should be sent to NL-KR-REQUEST@ROCHESTER.ARPA. DESKTOP-PUBLISHING Discussion group for sharing information on desktop publishing techniques and new technologies used in small publishing projects. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to dtp-request%plaid@SUN.COM. Coordinator: Chuq Von Rospach GAMEMASTERS@RINSO.LCS.MIT.EDU GAMEMASTERS%RINSO@XX.LCS.MIT.EDU Mailing list to serve as a forum for the discussion of adventure game programming, including questions such as player interfaces, multi-player possibilities, text vs. graphics games, etc. All requests to be added to or deleted from this list, problems, questions, etcetera, should be sent to GAMEMASTERS-REQUEST@RINSO.LCS.MIT.EDU or GAMEMASTERS-REQUEST%RINSO@XX.LCS.MIT.EDU. Coordinator: Brad Sagarin MUSIC-RESEARCH%PRG.OXFORD.AC.UK@CS.UCL.AC.UK The Music-Research electronic mail redistribution list was established after a suggestion made at a meeting in Oxford in July 1986, to provide an effective and fast means of bringing together musicologists, music analysts computer scientists, and others working on applications of computers in music research. Initially, the list was established for people whose chief interests concern computers and their applications to - music representation systems - information retrieval systems for musical scores - music printing - music analysis - musicology and ethnomusicology - tertiary music education - databases of musical information The following areas are not the principal concern of this list, although overlapping subjects may well be interesting: - primary and secondary education - sound generation techniques - composition 1 Page 9 All requests to be added to or deleted from this list, problems, questions, should be sent to music-research-request%prg.oxford.ac.uk@CS.UCL.AC.UK Coordinator: Stephen Page WRITERS%PLAID@SUN.COM Mailing list for science fiction writers, both published and unpublished. This list was created for authors to exchange and critique stories, and to hold discussions on any subject pertaining to writing science fiction. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to the Coordinator. Coordinator: Chuq Von Rospach ************************************************************************* * The Hewlett Packard Public Networking Newsletter * *************************************************************************** Last month we announced the publication of a new electronic magazine for Digital Equipment VAX users (the VAX Toolbox), so this month the HP3000 users get their say. Yes, it's the Hewlett Packard Public Networking Newsletter. A little information, courtesy of the editor of HPPNN, Jeff Kell: *********************************************************************** *** The Hewlett Packard Public Networking Networking Newsletter *** *********************************************************************** Greetings all; we are still a small group but I expect it to grow a bit as time goes by, and we have some still locked into land mail. Most of you initially replied to the July Education column in _Interact_ and I think I responded to everyone's inquiry personally with a quick update, but for those who may have missed, let me give some quick background. The University of Tennessee at Chattanooga operates five HP-3000 CPU's and one IBM-4381 which is presently on Bitnet. Three of the five HP's are presently linked to UT-Knoxville's MVS system via MRJE; but bear in mind that the MVS system is NOT Bitnet addressable and is used for primarily batch and IMS activity. The first hope for a Bitnet link was the HP announcement of MRJE support for RSCS, recently released on the MPE-V/E 'T-Mit' product tape. The information presented in the July column actually took place in April; the delay in publication of regular column features in Interact is three months. It is a rather poor forum to conduct news on such an exploratory project. In June we succeeded in connecting the HP with 1 Page 10 Bitnet, and have already begun several software projects to complete the connection. There are still quite a few problems to be resolved, but it does look promising. I will try to present our findings to date along with unresolved problems and currently addressed solutions. The Bitnet link to the HP is rather limited. HP seemingly 'added on' RSCS support when in fact the link will function to some degree without the much renowned RSCS support. MRJE acts like a single user station with a single console, reader, printer, and punch. RSCS, accordingly, treats the HP as though it were a single user work- station. In concept, this is a poor basis for trying to do networking; but it will suffice with proper additional software. MRJE's RSCS 'support' amounts to little more than a kludgy way to get print files onto their proper forms on the HP; it is very oriented to the printer. The punch has little or no additional support. Again, this is exactly the opposite of a primarily networking function. But again, it is functional. This should be enough background on the general problem at hand; neither side's software is really oriented to to networking at all - it is designed to feed print stations. *************************************************************************** Editor's note: That was a brief excerpt from the first issue. To subscribe to Hewlett Packard Public Networking Newsletter, send a mail request to Jeff Kell, JEFF@UTCVM. ************************************************************************* * CYBSERV by Bill Wilder * *************************************************************************** A mail based file server has been established at address CYBSERV@ACADIA. This server will store files of particular interest to Cyber sites. To use the file server send RFC822 mail to the address above (a subject line, if present, will be ignored). Each line of the message may be a command to the file server. The following commands are available: HELP Return help information about this file server. DIR Provide a directory of files maintained by the server. GET filename type Õsetå SEND filename type Õsetå SENDME filename type Õsetå 1 Page 11 Return by mail the specified file where "filename" is the name of the desired file (1-7 characters), and "type" is the type of the file (also 1-7 characters). For some files it may be necessary to specify "set" (yes, 1-7 characters). The directory listing for CYBSERV will indicate whether a set must be specified. ************************************************************************* * Coming soon: GRAND by Judy Molka * *************************************************************************** City University of New York has been developing conferencing capabilities for BITNET under the terms of a jointly defined effort with IBM. GRAND, the conferencing system, and its associated user-interface programs CONVEY (aka CONFER) and GRAIL (for line-by-line terminals), are designed to operate in a distributed fashion over an RSCS network. Users sign on to local or 'near-by' remote GRAND servers which are interconnected, and coordination and distribution of the various conference ('topic' in GRAND parlanc) entries. Zones of influence (a la RELAY) can be built into each system to 'force' users on to the appropriate GRAND server. A set of a dozen GRAND pilot servers will soon be operational. Besides providing distributed conferencing, other applications are being developed which will provide the ability to distribute packages, with subscriptions lists for updates and bug reports. GRAND is currently being used to shadow a number of ARPANET mailing lists and could be used to reduce much of the current gateway traffic due to ARPA mailing list subscriptions. GRAND provides much of the same functionality in terms of reducing network load. It will soon be used to shadow several discussion groups on LISTSERV@BITNIC. GRAND also provides an explicit segregation of group messages from personal messages. GRAND promises lots of functionality, but for non-VM users will require some user interface tools to be as easy as mail to use. ************************************************************************* * More Revised LISTSERVs * *************************************************************************** LISTSERV@UGA - University of Georgia Harold C. Pritchett The University of Georgia is now operating a LISTSERV machine using Eric Thomas' version of LISTSERV. The main service currently being offered is a re-transmittal of most of the popular distributions from BITNIC. Since UGA is located to the West of the BITNIC-CUNYVM-PSUVM-OHSTVMA backbone, any site located west of OHSTVMA can, by deleting their subscription to one of the supported BITNIC lists and subscribing to the same list at UGA, reduce the file load across these already overloaded links. 1 Page 12 Since the BITNIC list server does not support Peer linking, all submissions will still have to be sent to the master list at BITNIC. Several other lists are supported, and where the other listserv is also running Eric's code, they are linked as peers and mail sent to either node will be sent to all subscribers at all nodes. Below is a list of the lists currently being supported on the UGA listserv: List Name Send To Description --------- ------- ---------------------------------------------- APPLICAT BITNIC Applications under BITNET CYBER-L BITNIC CDC computer discussion list FUTURE-L BITNIC Future Developments in BITNET GGUIDE BITNIC BITNET Guide creation discussion IBM-NETS BITNIC IBM Networking discussion IBM7171 Note 1 Protocol Converters LIAISON BITNIC BITNIC Liaison LINKFAIL BITNIC Scheduled outage announcements MAIL-L BITNIC Mail transfer agents and Mail user agents MON-L BITNIC Monitoring and controlling BITNET use MUG Note 2 Discussion of MUSIC/SP operating system RSCSV2-L BITNIC RSCS Version 2 discussion group S-COMPUT Note 1 Super Computer discussion group STD-L BITNIC Standard Environments discussion TRANS-L BITNIC File Transport discussion UG-L BITNIC Usage guidelines discussion USRDIR-L BITNIC User Directory discussion VMPROB-L UGA Discussion of VM/PROBE monitor from UTCVM X400-L BITNIC X.400 Protocol for BITNET discussion Note1 - This list is Peer linked to a list at Tulane University (TCSVM). Mail sent to either list is distributed to the members of both. You should send to the closest site. Note2 - This list is Peer linked to a list at Marist College (MARIST). Mail sent to either list is distributed to the members of both. You should send to the closest site. The Revised LISTSERVs support remote registration. To sign up for any of these lists, from a site which supports messages, send a message to LISTSERV at UGA with the following text: SUBSCRIBE LISTNAME Your Name From a site which does not support messages, send RFC822 mail to LISTSERV at UGA with the following as the first non-blank line of the text: SUBSCRIBE LISTNAME Your Name 1 Page 13 For more information on LISTSERV, use one of the above methods to send the command HELP. For a copy of the LISTSERV users guide, send the command INFO. *************************************************************************** Distribution lists from LISTSERV at CMUCCVMA MD40 Computer Club Information MD41 IBM CC Internal MD42 The VAX Toolbox ÕA BITNET Magazine for VAX userså MD43 XYZZY Distribution MD44 XYZZY Discussion MD47 Computer Club Members Distribution lists from LISTSERV at EB0UB011 ASM370 - ASM370 Forum CHAT-L - Distribution list for the Chat program CIUB-L - Llista Interna del CIUB EARNTECH - EARNTECH List INFOIBMP - Info-IBMPC Digest LINGUA - Programming Languages Digest LINKFAIL - LINKFAIL Distribution List LSTSRV-L - The Revised LISTSERV Distribution List MAILBOOK - MAIL/MAILBOOK subscription list OPSYS - Operating Systems Digest REXXLIST - REXX Digest RSCSMODS - RSCS modifications list ************************************************************************* * The RELAY Rules * *************************************************************************** General Guidelines for Relay Usage 8/04/86 (DRAFT) RELAY provides real-time communication between multiple users at various institutions in the BITNET, EARN, and NetNorth networks. Use of these networks for any purposes not directly related to the research, instructional, and/or administrative tasks for which your userid has been authorized by your institution may result in the termination of your ability to use the Relay. Depending on the network-access policies of your institution and the usage policies of the network in which your institution resides, such unauthorized use of these networks may, alternatively, result in the termination of your userid or its ability to communicate over these networks for ANY purpose. 1 Page 14 INTERNAL use, using and/or limiting the Relay conferencing system for communication either wholly within one node, or within one institution over several nodes and/or servers, is the total responsibility of that institution. NETWORK-WIDE use, using one or more Relay servers to communicate with another Relay server(s) at another institution(s), falls under the established guidelines presented herein. Failure to adhere to these guidelines, or where general network usage guidelines may have been violated may result in the loss of your ability to use Relay; or where such actions are not administered by the local host institution may result in expulsion of that server from the authorized sitelist. *************************************************************************** Background Information and User Responsibilities 9/02/86 (DRAFT) Relay is a distributed message server which, by selective switching and redistribution of messages, provides real-time conferencing capabilities while minimizing the overhead on the network links. Since the potential load of uncontrolled message traffic on the network can affect transfer of files, stringent controls over Relay use are mandatory. Most control measures are enforced by Relay automatically, but some are necessarily the responsibility of the user. These include: o Each Relay server provides service to a specific collection of one or more nodes designated as a "service area". To determine which Relay server(s) you may use, issue the following command: In BITNET : TELL RELAY AT BITNIC /SERVERS In EARN : TELL RELAY AT DEARN /SERVERS In NetNorth: TELL RELAY AT CANADA01 /SERVERS o Excessive queries, channel changes, and other commands which must be processed by Relay generate considerable overhead in some cases and should be kept to a reasonable number. In addition, you should direct your queries to only your assigned Relay(s). o File backlogs, Relay host CPU saturation, link failures, and node downtime may make Relay temporarily unavailable or restricted. In such instances you should wait until your Relay is available; it is not proper to redirect signons or Relay links in such cases where the alternate path will generate a greater network load than the primary path. o Proper and considerate behavior should be observed at all times. Misuses in this category include, but are not limited to: a. Disguising your identity in a /SIGNUP by not specifying your full name, or by specifying someone else's name. b. Transmitting rude or obscene language. 1 Page 15 c. Channel scanning; attempting to locate a private channel without first obtaining an invitation from a user on that channel. d. Annoying other Relay users by transmitting excessive and/or repetitive messages (including the use of 'picture' EXECs). e. Failing to cease an activity in response to a request to do so from any individual designated as the 'Relay Operator' for a Relay server. Repeated violations of the above may result in the termination of your ability to use the Relay. *************************************************************************** Relay User Classification System 9/09/86 (DRAFT) Due to previously high volumes of message traffic and the popularity of the use of Relay for casual conversation, users will be classified into one of two distinct classes: (1) Public user class. Any user may obtain public access to Relay by a standard /SIGNUP command. Public users are limited to the public channels 0-999 and are additionally subject to channel limits, peak period shutdowns, and limited hours of operation. In general, the prime time period (8:00 AM - 6:00 PM local time of the host) will be closed to the public. (2) General user class. A user may, in certain circumstances, be given the general user class for full access to Relay. General users are restricted to only academic conferencing activities. Abuse of the general class will result in the loss of general user priviledge. General user class is usually restricted to faculty/staff/grads. General user class can only be granted by the host Relay contact or his designate. Users from other institutions must submit adequate evidence of authorization to request general classification, usually by a request from the listed administrator or contact from the user's institution. The host Relay contact (or designate) may require additional information or place further constraints on such services. *************************************************************************** Corrective Actions -- Relay Operator Responsibilities 8/21/86 (DRAFT) The day-to-day maintenance and operation of a Relay server is carried out by the "Relay Operator", an individual or group of individuals who are responsible to the institution's network administrative authority. The Relay Operator is also responsible for implementing corrective action to temporarily or permanently terminate a user's access to the Relay in cases of violation of the guidelines described in other sections of this document. 1 Page 16 Actions that can be taken by any Relay Operator against offending users of any and all Relay servers: * sending an offending user a warning notification by message or mail * forcing the offending user from the current Relay session * temporary lockout (2 days or less) of the offending user Actions that can be taken only by the Relay Operator of the offending user's Relay server: * temporary lockout (over 2 days) of the offending user * permanent lockout of the offending user from Relay use Any corrective action taken by a Relay Operator against an offending user of another institution's Relay server, other than single instances of an abusive user being forced as a warning, should be documented by sending mail to that server's Relay Operator outlining the reason for the action. ************************************************************************* * Feedback * *************************************************************************** Date: Sun, 17 Aug 86 09:25:32 IST From: Zvika Bar-Deroma Subject: Netmonth AUG1986 To: Chris Condon Hi Chris, I haven't read it yet, but "hallelujah for the contents part + CC characters "a la VM/COM " ( hope it's as intersting as aesthetical....). Keep up the good work, Zvika *************************************************************************** Date: 18 August 1986, 09:23:54 CDT From: X075ZH at TAMVM1 To: BITLIB at YALEVMX Chris; I also want to say that I do enjoy the new NetMonth format and find it a lot better than the old format.I found the article by Jeff Kell to be very informative and useful and I am sure it will be passed on to other 1 Page 17 users who could use some of the information in it. Thanks for the very informative guide that you put out each month and keep up the good work. Take care; Richard Lee Holbert *************************************************************************** Date: Mon, 18 Aug 86 13:39:49 ADT From: wdw@Acadia (Bill Wilder) To: bitlib@yalevmx Chris, One problem I have in using file servers, and perhaps others have this problem as well, is that I am not at an IBM site and I cannot send interactive messages. I can send RFC822 mail, and I can punch NETDATA format requests to nodes. Would you be able to explain to those of us in the under-developed world (i.e. non-IBM) more about interactive messages, IBM Notes, IBM Profs mail, NETDATA format, SENDFILE format, class M punch etc. Thanks Bill Wilder - Acadia University >> Uh, oh. You found my weak spot... technical questions. I don't know how most of those things work, I just USE 'em. I could explain to you what an interactive message IS, but why it does what it does is a mystery to me! Yes, my major is Computer Science, but with an emphasis on Information Management (as opposed to Scientific Computing where they learn FORTRAN and take lots of Math courses, I took COBOL and lots of Business courses). That doesn't answer your question does it? Oh well... ************************************************************************* * NetMonth Policies * *************************************************************************** If you have questions or comments about BITNET or NetMonth that you would like printed here, mail your letter to BITLIB@YALEVMX. Make sure that you specify in the "Subject:" header or somewhere in the letter that it is for the NetMonth letters column. This doesn't mean that your letter will be printed, but it helps. Your opinion counts! Article Submissions: The only requirements for NetMonth articles are that they be informative, interesting, and deal with BITNET services (or any other good BITNET related topics). The editor will inform you of any changes to your writing and will submit them for your approval, deadlines permitting. Send your articles to BITLIB@YALEVMX. --------------------------------------------------------------------------- FuzzyBytes Electronic Publishing "Because We're Here."