|
|
NetMonth, September 1986
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * *** ***** * * * *** **** ***** ****
* * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
* *
* 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."
|
|
