Human-Nets-Request@RED.RUTGERS.EDU (Charles McGrew, The Moderator) (09/25/85)
HUMAN-NETS Digest Wednesday, 25 Sep 1985 Volume 8 : Issue 31
Today's Topics:
Administrivia - Tymnet Access Numbers,
Computers and the Law - The Right to Receive (3 msgs) &
Preserving rights to Email messages (2 msgs),
Computer Networks - Information Networks of the Future,
Computers and People - Renaming So-called "Hackers",
Announcement - Electronic Document distribution experiment &
WG9.1 Conference Planned (IFIP)
----------------------------------------------------------------------
Date: 23 Sep 85 23:12:00 EDT
From: Charles <mcgrew@rutgers>
Subject: Tymnet Access numbers
Thanks to William Daul, the latest Tymnet access numbers are available
for anonymous FTP from <mcgrew.human-nets>tymnet.map from Rutgers.
------------------------------
Date: Monday, 16 Sep 1985 06:51:00-PDT
From: minow%rex.DEC@decwrl.ARPA
From: (Martin Minow, DECtalk Engineering ML3-1/U47 223-9922)
Subject: secrecy of communications
If I remember my communications law -- not likely as I haven't looked
at it for a bunch of years -- there are two motivations for the
"secrecy" clause of the Communications Act of 1934:
1. Anti-Jamming -- the USA says that its citizens my receive any
broadcast signals. This means, in effect, that "we won't jam Radio
Moscow" and thus implies that "The Russians shouldn't jam Voice of
America."
2. Monitoring -- in certain circumstances a radio operator must listen
to signals which are broadcast, but of a private nature. For
example, a ship radio operator must monitor certain frequencies for
distress calls and consequently may overhear communications that
are not broadcast to a general audience. The Act holds that this
is not illegal so long as the radio operator does not divulge the
content of the message (except under certain circumstances, such as
emergency broadcasts).
Although Radio Communications has grown considerably since 1934, it
does not appear to me that it explicitly permits a person to obtain
personal benefit by receiving signals which are not broadcast to a
general audience (even if this benefit extends only to watching WTBS).
I believe also that even the "superstations" charge cable companies a
fee (perhaps $.50 per household per month) for reception.
Martin Minow
decvax!minow @ decwrl.arpa
minow%rex.dec @ decwrl.arpa
------------------------------
Date: 16 Sep 85 13:12:00 EDT
From: "COTTRELL, JAMES" <cottrell@nbs-vms>
Subject: Right to Receive
/*
> I don't know if anyone noticed, but a few weeks ago the Supreme
> Court threw away a right that Americans have had since day one.
Well at least since 1906 :-) Also, several states (notably fascist
Virginia) have declared radar detectors illegal as well. Supposedly,
it is a crime to decrypt secure U.S. communications as well.
jim cottrell@nbs
*/
------------------------------
Date: Fri, 30 Aug 85 10:22 EDT
From: taylor.WBST@Xerox.ARPA
Subject: Re: Loss of Fredom... CC:
To: Paul R. Grupp <GRUPP@MIT-MC.ARPA>
Cc: info-hams@SIMTEL20.ARPA
I AGREE!
I WONDER WHAT THE POSITION OF THE "VOICE OF THE RADIO AMATEUR" = THE
ARRL, IS ON THIS LITTLE EROSION OF FREEDOM.
JIM (W2OZH)
------------------------------
Date: 16-Sep-85 19:01 PDT
From: William Daul / McDonnell-Douglas / APD-ASD
From: <WBD.TYM@OFFICE-2.ARPA>
Subject: Re: preserving rights to Email messages
Cc: Hunter@YALE.ARPA
What happend's to Gs copyrighted material sent by X via a a net to A
and then A uses this material thinking it was public domain...G finds
out about it...what happens now?...comments...
--Bi//
------------------------------
Subject: Re: preserving rights to Email messages
Date: Tue, 17 Sep 85 13:20:31 EDT
From: Larry Hunter <Hunter@YALE.ARPA>
To: WBD.TYM@OFFICE-2
Copyright: Larry Hunter, 1985
What happend's to Gs copyrighted material sent by X via a a net to
A and then A uses this material thinking it was public domain...G
finds out about it...what happens now?...comments...
--Bi//
Like I said, ask a real lawyer if you have real problems. My guess is
that G is entitled to fair compensation for his work and that A should
try to nail any liability on X. If A made lots of money on G's work
and X is some poor bboard op somewhere, then the 'deep pockets' will
probably pay... I'd check into copyrights at your local law library;
at this point there is nothing special about the electronic nature of
the communiation.
Larry
------------------------------
To: veeger!hpcnof!hplabs!Human-Nets@red.rutgers.edu
Date: Wed, 18 Sep 85 12:52:39 MDT
From: Dave Taylor <hpcnou!dat%hplabs.csnet@CSNET-RELAY.ARPA>
Subject: Information Overload
I've been thinking about the current electronic mail
system from an 'in-the-large' point of view and thought I'd bounce
a few ideas off of the people in this group. If anyone has any
thoughts, positive or negative, please don't hesitate to respond!!
The basic issue is 'how?'. We currently have a somewhat
juryrigged electronic mail network that through some miracle works
most of the time. While we could simply use the existing systems as
a basis for future systems, I'd rather see us redesign it to be a
more intuitive system accessable by non-tech-fanatics.
Currently, we have a 'paper' mail system that works very
well and is very well integrated into 'societal' conciousness. While
this isn't necessarily the ideal either, it's certainly true that any
schoolchild can send mail to someone else.
Let's use that as a model then, and see what sort of
information we need to have for electronic communications...
The first data we'd need, obviously, is the persons name. It
would be nice if we could simply type in "Dave Taylor", for example,
as the persons name, rather than decipering some cryptic /etc/password
entry (like 'dat')...
Next, on surface mail, we'd have a company name, something
like "HP - CNO". Let's assume we can do that on this mail too...
The third data point is the street address, then the city,
state and zip code.
So far, my address looks like:
Dave Taylor, HP - CNO, 3404 Harmony Rd, Fort Collins, Co, 80525
Now let's go back to electronic mail and figure out how we
could offer an analogous service...
The simplest way would be to assign 'geographical clearing
house' computers, and this would be parsed backwards - we'd check the
zip code (80525) against a table of codes and find a machine address
from that. This machine would know about the next significant data
point - the street address. (The city and state are implied by the
zip code, I believe). At this point, it might actually use the
company name too, if present.
Finally, it would be routed to a 'master' machine here in
CNO, for example, that would then try to figure out who Dave Taylor
was.
I think the biggest problem with this is that it would
involve a lot of machines knowing about a lot of data. Especially
parsing the street address would be difficult.
(We haven't considered international mail either).
Another alternative is to be able to specify the person by the
equivalent significant data: "dave taylor, hp, fort collins, co" and
parse that backwards.
This has the same problems as the previous scheme, it's just a
little more easy to use. (no mysterious 5/9 digit zip code).
Let's go a bit further...."Dave Taylor, HP, Colorado". This
could be parsed by the sending machine for the state, then, within the
state, by company. If it didn't know the company/state address
combination, it would mail to a default hub machine in that state.
That machine would then be responsible for either knowing the company
name, having special instructions about the individual name (like
"Ronald Reagan, Washington DC") or send the mail back informing the
original sender that the address was unknown.
Each geographic region would then be responsible for having a
hub system that would be able to talk to all the other hub systems
(we'll get to that in a 'sec) and would also know about all the
companies that are in business in that region. (We've changed the
application slightly to 'institutions' (companies and colleges)...)
Mail, then, would always be routed to:
yourmachine - geographic-hub { - other geographic-hub }
{ - their company-hub } - theirmachine
So mail to me from Los Angeles, for example, would go (assume we're
sending from ucla-cs):
ucla-cs - la-hub - colorado-hub - hp-colorado-hub - hp-cno
This would mean that the person mailing from UCLA would have
specified:
Dave Taylor, Hewlett Packard, Colorado
rather than:
ucla-cs!ucbvax!ihnp4!hpfcla!hpcnoe!veeger!hpcnou!dat
considerably friendlier.
There are still some difficulties with this system, mostly to
do with the size of the databases and the traffic that big hubs (like
'silicon-valley-hub' or 'indian-hills-hub') would get, but I'm more
interested in the conceptual layer...the implementation details are
'best left up to the student'.
Well? Any thoughts??
-- Dave Taylor, HP, Colorado
or, if you must: ..hplabs!hpcnof!dat
..ihnp4!hpfcla!d_taylor
hpcnof!dat@HPLABS.CSNET-RELAY
------------------------------
Date: Fri 13 Sep 85 14:01:19-PDT
From: Douglas Edwards <EDWARDS@SU-CSLI.ARPA>
Subject: The Poll on Renaming So-called "Hackers"
The term "cracker" is most appropriate; it's even catchier than
"hacker" and carries the association of safecracking. I've already
started using it in place of "hacker" in conversation, to denote those
who break into computer systems. I had heard the term "hacker" used
for years, to mean simply a clever and/or obsessive programmer, before
I ever heard it used to mean a cracker. We should return it to its
original sense.
------------------------------
From: Jim Guyton <guyton@rand-unix.ARPA>
To: MsgGroup@brl
Cc: IRList%vpi@csnet-relay, rand-docs@rand-unix.ARPA
Subject: Electronic Document distribution experiment
Date: 22 Sep 85 13:50:19 PDT (Sun)
ARPANET ANNOUNCEMENT
The Rand Corporation is conducting an experiment in electronic
publishing. The documents listed below have been fully reviewed and
published as printed Rand publications. By making the same document
(excluding tables and graphics) available on the ARPANET, Rand is
attempting to assess the needs of the electronic user. If you are
interested in copying any of the documents, please contact
RAND-DOCS@RAND-UNIX.ARPA. We will send you an electronic
questionnaire, and as soon as you complete and return it, we will
supply the information you need to access the document. We may also
send you a follow-up questionnaire to get your reaction to the
electronic document.
If you find that the electronic version doesn't meet your needs
because of the missing illustrations and graphics, you can then
contact RAND-DOCS and order a printed copy of the document which will
be sent to you via the U.S. Post.
We welcome any comments or suggestions on this experiment. Just send
all correspondence to RAND-DOCS@RAND-UNIX.ARPA.
AVAILABLE TITLES
R-3283-NSF/RC "Toward an Ethics and Etiquette for Electronic Mail,"
by N.A. Shapiro, R.H. Anderson. July 1985. (95K bytes)
R-3160-AF "ROSS: An Object-Oriented Language for Constructing
Simulations," by D. McArthur, P. Klahr, S. Narain, October
1984. (64K bytes)
R-3158-AF "TWIRL: Tactical Warfare in the ROSS Language," by P.
Klahr, J.W. Ellis, Jr., W.D. Giarla, S. Narain, E.M.
Cesar, Jr., S. Turner, September 1984. (150K bytes)
ABSTRACTS of above documents:
R-3283-NSF/RC. Toward an Ethics and Etiquette for Electronic Mail.
N.A. Shapiro, R.H. Anderson. July 1985, 35 pp., $4.00
This report discusses some important general attributes of
electronic mail and message systems, and the effects of those
attributes on the quality and appropriateness of communication. The
authors discuss the "etiquette" of sending and receiving electronic
mail, drawing on personal observation of inappropriate and
counterproductive uses of these systems. By presenting some initial
guidelines, the authors attempt to accelerate the process by which
social customs and behavior appropriate to electronic mail become
established, and thereby to accelerate the effective use of such
systems.
R-3160-AF. ROSS: An Object-Oriented Language for Constructing
Simulations. D. McArthur, P. Klahr, S. Narain. October 1984, 28 pp.,
Ref., $4.00
This report provides an overview of ROSS, an object-oriented
language currently being developed at Rand. The goal of ROSS is to
provide a programming environment in which users can conveniently
design, test, and modify large knowledge-based simulations of complex
mechanisms. Object-oriented programming languages, and ROSS in
particular, enforce a message-passing style of programming in which
the system to be modeled is represented as a set of objects and their
behaviors (rules for object interaction). This style is especially
suited to simulation, since the mechanism or process to be simulated
may have a decomposition that maps naturally onto objects, and the
real-world interactions between the objects may be easily modeled by
object behaviors and object message transmissions. In addition to
describing some of the basic ROSS commands and features, the report
discusses some software that interfaces directly with ROSS, including
a sophisticated screen-oriented editor and a color graphics package.
Facilities for browsing among objects and their behaviors are also
described, and examples of browsing and editing are presented using
SWIRL, a military combat simulation written in ROSS.
R-3158-AF. TWIRL: Tactical Warfare in the ROSS Language. P.Klahr,
J.W. Ellis, Jr., W.D. Giarla, S. Narain, E.M. Cesar, Jr., S.Turner,
September 1984, 49 pp., Bibliog., $4.00
This report describes TWIRL, a simulation of a primarily ground
combat engagement between two opposing military forces. It was
developed to further experiment with the ROSS language, an
object-oriented simulation language that was successfully used to
develop the SWIRL air battle simulation, and to develop a prototype
simulation that could be used to explore issues in electronic combat.
The authors describe the objects that comprise TWIRL and provide
extensive examples of object behaviors to explain and illustrate the
process of building a simulation in ROSS.
------------------------------
Date: 18-Sep-85 16:39 PDT
From: William Daul / McDonnell-Douglas / APD-ASD
From: <WBD.TYM@OFFICE-2.ARPA>
Subject: WG9.1 Conference Planned (IFIP)
To: DCE.TYM@OFFICE-2.ARPA
Cc: GNOSIS.TYM@OFFICE-2.ARPA, MARKET.TYM@OFFICE-2.ARPA
System Design for Human Development and Productivity: Participation
and Beyond is the title of a conference planned by the IFIP Working
Group on Computers and Work (WG9.1) 12-15 May 1986 in Berlin (DDR).
This is the first conference sponsored by IFIP's Technical Committee
on the Relationship between Computers and Society (TC9) in an Eastern
European country.
The conference will address emerging trends in system design:
strategies of intervention; changes in work organization; new,
flexible technologies; and interests and attitudes of the people
involved.
The Conference and Program chairman is Dr. Klaus Fuchs-Kittowski
(DDR).
For more information, contact--
De. Ernst Muhlenberg
Humbolt-University
Sektion Wissenschaftstheoryie und -organisation
1086 Berlin, German Democratic Republic
------------------------------
End of HUMAN-NETS Digest
************************