15-Apr-79 12:05:24-PST,7517;000000000001 
Mail-from: STEFFERUD filed at 9-Apr-79 2153-PST  
Date: 9 Apr 1979 2153-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP#1001  SURVEY [ISI]<MSGGROUP>PROCEEDINGS.MSG#951-#1000
From: STEFFERUD at USC-ISI
To: MSGGROUP at MIT-ML
Message-ID: <[USC-ISI] 9-Apr-79 21:53:04.STEFFERUD>
Fcc: <STEFFERUD>SAVED.MESSAGES;1
Redistributed-To: DANIEL at OF1, JBROWN at MIT-MC
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 10 Apr 1979

 -- Messages from file: [USC-ISI]<MSGGROUP>PROCEEDINGS.MSG#951-#1000;1

   50   9 Apr  Pine at SRI-KA (Bud P MSGGROUP#1000  Re: In defense of 
                                     flames (837 chrs)
   49  09 APR  JZS at CCA (Joanne Sa MSGGROUP# 999  MEthics (965 chrs)
   48   9 Apr  Charles Frankston <CB MSGGROUP# 998  ITS headers
                                     (1300 chrs)
   47   8 Apr  Mike at Rand-Unix     MSGGROUP# 997  METHICS (917 chrs)
   46   8 APR  SIRBU at MIT-MC (Marv MSGGROUP# 996  Re: In defense of 
                                     flames (1096 chrs)
   45   8 Apr  Bob Frankston         MSGGROUP# 995  Re: In defense of 
                                     flames (489 chrs)
   44   8 Apr  Feinler at SRI-KL (Ja MSGGROUP# 994  Re: In defense of 
                                     flames (748 chrs)
   43   8 Apr  Feinler at SRI-KL (Ja MSGGROUP# 993  Re: In defense of 
                                     flames (2962 chrs)
   42   8 Apr  Gaines at Rand-Unix   MSGGROUP# 992  Automatic 
                                     redistribution of MsgGroup mail
                                     (1317 chrs)
   41   8 Apr  Feinler at SRI-KL (Ja MSGGROUP# 991  Re: "Not-Logged-In"
                                     use and helpfulness of 
                                     (1051 chrs)
   40   7 Apr  To:BR10 at CMU-10A    MSGGROUP# 990  Re: #981  MsgGroup 
                                     administration (2303 chrs)
   39   7 Apr  Bob Frankston         MSGGROUP# 989  MsgGroup 
                                     administration (926 chrs)
   38  Saturd  Brian K. Reid <BR10 a MSGGROUP# 988  Re: In defense of 
                                     flames (474 chrs)
   37   7 Apr  To:RMS at MIT-AI      MSGGROUP# 987  Re: We're better 
                                     off without the flaming
                                     (1011 chrs)
   36   7 Apr  Robert W. Kerns <RWK  MSGGROUP# 986  Fast Draw!
                                     (2061 chrs)
   35   7 Apr  PBARAN at USC-ISI     MSGGROUP# 985  In defense of flame
                                     (780 chrs)
   34  Saturd  Brian K. Reid <BR10 a MSGGROUP# 984  Manual vs. 
                                     Automatic reforwarding (424 chrs)
   33   7 Apr  Mark Crispin <Admin.M MSGGROUP# 983  flaming (484 chrs)
   32   7 Apr  Richard M. Stallman < MSGGROUP# 982  We're better off 
                                     without the flaming (1069 chrs)
   31  Saturd  Brian K. Reid <BR10 a MSGGROUP# 981  MsgGroup 
                                     administration (2759 chrs)
   30   7 Apr  To:SDSAN-DMS at SRI-K MSGGROUP# 980  Re: Long dry and 
                                     grim message.   (5894 chrs)
   29   7 Apr  To:RWK at MIT-MC      MSGGROUP# 979  Re:  STEFFERUD's 
                                     lack of tact, "Bad Breath", 
                                     (1333 chrs)
   28   7 Apr  Robert W. Kerns <RWK  MSGGROUP# 978  STEFFERUD's lack of
                                     tact, "Bad Breath", indeed!
                                     (894 chrs)
   27   7 Apr  Mark Crispin <MRC at  MSGGROUP# 977  MSG  (2026 chrs)
   26   7 Apr  SDSAN-DMS at SRI-KA   MSGGROUP# 976  Re: Long dry and 
                                     grim message.   (1644 chrs)
   25   7 Apr  Richard M. Stallman < MSGGROUP# 975  Long dry and grim 
                                     message.   (6788 chrs)
   24   7 Apr  lauren at UCLA-Securi MSGGROUP# 974  "Can Implies Shall"
                                     (763 chrs)
   23   6 Apr  To:JNC at MIT-MC      MSGGROUP# 973  Re: Huh???
                                     (1293 chrs)
   22  Fri, 6  Greep at Rand-Unix    MSGGROUP# 972  Re: Mating habits 
                                     of waterfowl (sorry, D.M.)
                                     (1380 chrs)
   21   7 APR  JNC at MIT-MC (J. Noe MSGGROUP# 971  Mating habits of 
                                     waterfowl (sorry, D.M.) (422 chrs)
   20   7 APR  JNC at MIT-MC (J. Noe MSGGROUP# 970  Huh??? (360 chrs)
   19   6 Apr  the tty of Geoffrey S MSGGROUP# 969  Re: "Not-Logged-In"
                                     use and helpfulness of (803 chrs)
   18  Fri, 6  Greep at Rand-Unix    MSGGROUP# 968  Re: How the ITS 
                                     headers escaped and gave birth
                                     (567 chrs)
   17   6 Apr  Charles Frankston <CB MSGGROUP# 967  "Not-Logged-In" use
                                     and helpfulness of (818 chrs)
   16  Fri, 6  Greep at Rand-Unix    MSGGROUP# 966  Re: "Not-Logged-In"
                                     use and helpfulness of (1000 chrs)
   15   6 Apr  Charles Frankston <CB MSGGROUP# 965  RE #964 ITS mail 
                                     reading very primitive?
                                     (2229 chrs)
   14   6 Apr  To:RMS at MIT-AI      MSGGROUP# 964  Re: #962 ITS mail 
                                     reading is very primitive
                                     (603 chrs)
   13   6 Apr  Charles Frankston <CB MSGGROUP# 963  Re: "Not-Logged-In"
                                     use and helpfulness of 
                                     (1088 chrs)
   12   6 Apr  ___074 at MIT-AI      MSGGROUP# 962  ITS mail reading is
                                     very primitive (1551 chrs)
   11   6 APR  KLH at MIT-MC (Ken Ha MSGGROUP# 961  Un(registered-mail-
                                     receipt) (998 chrs)
   10   6 Apr  Bair at SRI-KL (James MSGGROUP# 960  Re:  MSGGROUP 
                                     storage efficiencies  (422 chrs)
   9   Friday  Brian.K..Reid <BR10 a MSGGROUP# 959  ITS headers 
                                     (1203 chrs)
   8    6 Apr  To:rms at MIT-AI      MSGGROUP# 958  Re: In case you 
                                     assumed I knew the insides 
                                     (953 chrs)
   7    5 APR  SIRBU at MIT-MC (Marv MSGGROUP# 957  BBoards (573 chrs)
   6    5 Apr  Stuart McLure Cracraf MSGGROUP# 956  Re: In case you 
                                     assumed I knew the insides 
                                     (701 chrs)
   5    5 Apr  ___023 at MIT-AI      MSGGROUP# 955 In case you assumed 
                                     I knew the insides of COMSAT
                                     (2194 chrs)
   4    5 Apr  To:Zellich at OFFICE- MSGGROUP# 954  Re: #953 Mail 
                                     Storage Efficiency and BBoards
                                     (1351 chrs)
   3    5 Apr  Zellich at OFFICE-1   MSGGROUP# 953  Re: Mail Storage 
                                     Efficiency and BBoards (1048 chrs)
   2   Thursd  Brian K. Reid <BR10 a MSGGROUP# 952  BBoards (3700 chrs)
   1    5 Apr  To:MSGGROUP at MIT-ML MSGGROUP# 951  SURVEY [ISI]<MSGGRO
                                     UP>PROCEEDINGS.MSG"901-#950
                                     (7700 chrs)
15-Apr-79 12:05:25-PST,728;000000000001 
Mail-from: MIT-ML rcvd at 9-Apr-79 1435-PST
From: dcrocker at Rand-Unix
Date: Mon,  9 Apr 79 09:09-PST
To: STEFFERUD at USC-ISI
cc: MsgGroup at MIT-ML,
    BR10 at CMU-10A
Subject: MSGGROUP#1002  Re: #981  MsgGroup administration
In-reply-to: Your message of 7 Apr 1979 1555-PST.
             <[USC-ISI] 7-Apr-79 15:55:26.STEFFERUD>
Redistributed-To: DANIEL at OF1, JBROWN at MIT-MC
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 10 Apr 1979

Most of the studies on user problem-solving behavior with interactive
computing were done by Sackman at Rand.  The sortso of results he
got were as Stef described.  The medium, if not being the message,
seems to urge it.

dave.

15-Apr-79 12:05:25-PST,1257;000000000001 
Mail-from: MIT-ML rcvd at 9-Apr-79 1436-PST
Date:  9 Apr 1979 1043-PST
From: Fylstra at SRI-KL
Subject: MSGGROUP#1003  Re: In defense of flames
To:   Pine at SRI-KA, SIRBU at MIT-MC, Feinler, msggroup at MIT-ML,
To:   PBARAN at USC-ISI
cc:   FEINLER at MIT-MC, FYLSTRA
Redistributed-To: DANIEL at OF1, JBROWN at MIT-MC
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 10 Apr 1979

In response to the message sent  9 Apr 1979 0711-PST from Pine@SRI-KA 

I agree with Bud.  The sociology of using a telephone is surely a good
deal different from that of face-to-face conversations, and computer
mail has to be different for similar reasons.  Our medium is really a
written one, not an oral one.  It is something like a technical journal
without the 5 month turnaround.  Yet like the telephone it provides an
element of anonymity; remember that many of us have never met, face-to-
face.  And like the caller dealing with an airlines reservationist, it
is sometimes too easy to be impolite.

I like Jake's idea, but would prefer to broaden the discussion to
include more generally the sociology of the medium, rather than
developing a code of ethis.  Jake, pls add me to the list...

Dave
-------

15-Apr-79 12:05:25-PST,4969;000000000001    
Mail-from: MIT-MC rcvd at 9-Apr-79 1514-PST
Date: 9 Apr 1979 1438-PST
Sender: DRXAL-HDA at OFFICE-1
Subject: MSGGROUP#1004  METHICS and the Fast Draw
From:  WILLIAM G. MARTIN
To: msggroup at MIT-MC
Message-ID: <[OFFICE-1] 9-Apr-79 14:38:55.DRXAL-HDA>
Redistributed-To: DANIEL at OF1, JBROWN at MIT-MC
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 10 Apr 1979

I, too, add my request to be included in the METHICS mailing
list-- put me on as ROUNDS at Office-1, which is where I will be
shortly, after some directory reshuffling takes place.  I love to
be on mailing lists, unlike those who resent having many
messages, no matter what they are about.  (I get more USPS mail
at home than anyone else on the street, and a lot at the office,
too.  The more stuff that comes in, the better.  Now, if I only
had enough time to read it...)

Regarding the analysis of the Msggroup communication that has
recently been discussed, it seems to me that we see the same
effects in Msggroup exchanges that we see in any communications
medium.  As response time shortens, reactions become more
visceral.  Compare mail exchanges with phone calls; because you
have instant feedback, and a compulsion to say SOMETHING, the
same exchange over the phone can get much more heated than the
more drawn-out written exchange, even if the contents began
equally.  The automatic forwarder system shortens response times.
Instead of reflecting (perhaps even unconsciously) over some time
after you send out a comment or statement, you see someone's
response much sooner, and being still caught up in the mood of
the moment, if that response is critical, it is the same as if
someone says "You're wrong!"  in a conversation.  The instinctive
response is hostility.  If you wait a day to hear "You're
wrong!", it has nowhere near the same impact.  There is even a
good chance that you will respond "You may be right" after
pondering the issue; of course, you may be even more fully
convinced of your correctness and have more arguments in your
favor by then, too.  Depends if you were right in the first place
or not.  Anyway, imposing a time lag will also reduce the
pleasure inspired by favorable responses--there is that to serve
as a compensating benefit.

This doesn't mean, though, that we should delay the transmission
of Msggroup mail just to avoid the possibility of annoyances;
even less does it mean that we should impose the onerous editing
tasks on Stef that caused the delays in the past.  After all, I
seem to have always heard that electronic mail is an informal
medium, which serves to replace telephone calls, for example,
instead of formal mail exchanges, though it may well reduce the
need for the latter.  In informal communication, we all flare up
now and then.  The unique problem we have here is that the medium
strips away all the other clues that are communicated in other
modes of transmission.  In a phone call, the tone of voice means
nearly as much as the words spoken; in face-to-face conversation,
the tone, the gestures, the facial expressions, and the general
body attitude convey large portions of the messages transmitted
and the way they are interpreted.  Here, all we see are words on
paper or a screen, and not even handwritten at that!  What might
be said banteringly becomes spiteful and snide when written,
without the lightening of effect provided by a smile and a light,
cheery tone of voice.  We are left with an edited version of what
was meant, and the editing removes what may be more important
than what remains.

The net result is communication by letter at (almost) telephonic
speed.  All the connotations of written material we have
internalized since childhood come into play in structuring our
response to a letter-- written material must be right, its
official, its legally binding, etc.  It is very hard to transform
our tolerance of what may be (strictly speaking) offensive in
informal communication, especially when moderated by non-verbal
effects, to a tolerance of the same material when we see it in
writing.

The answer may be hard to implement; we have to change the way we
view these exchanges.  Force ourselves to see them as the
informal chatting they really are, not as a formal offering and
criticism thereof.  The hard part in this approach is to take
into account the fact that these are recorded for posterity.  It
is like you knew that your phone was tapped, and everything you
said was being taken down.  Even if you had nothing to conceal
from the tapper, you would still change what you said because of
that.  Yet, as Stef has said, it is worthwhile that all of
Msggroup's exchanges have been recorded for future analysis--that
is a benefit, not a defect.  I don't know the answer to this; we
may well have to just put up with a little flaming for the sake
of the roast it cooks.

Will Martin

15-Apr-79 12:05:25-PST,2072;000000000001 
Mail-from: MIT-ML rcvd at 9-Apr-79 1542-PST
From: Anderson at Rand-Unix
Date:  9 Apr 1979 at 1451-PST
To: STEFFERUD at USC-ISI
cc: MsgGroup at MIT-ML,
    BR10 at CMU-10A
Subject: MSGGROUP#1005  Re: #981  MsgGroup administration
In-reply-to: Your message of 7 Apr 1979 1555-PST.
             <[USC-ISI] 7-Apr-79 15:55:26.STEFFERUD>
Redistributed-To: DANIEL at OF1, JBROWN at MIT-MC
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 10 Apr 1979

Stef -
	The research results on the effects of response delay in
enhancing computer user performance that you mentioned in the
above-referenced message might be those contained in the following
report.

	Bob Anderson

		- - - - - - - - - - - - - - - - -

     Seven, M.J., B.W. Boehm, and R.A. Watson, "A Study
	of User Behavior in Problemsolving with an
	Interactive Computer".  R-513-NASA, The Rand
	Corporation, Santa Monica, CA.  (April 1971)

	An exploratory investigation tested the effects of forced
	temporal lockout intervals on user performance in an
	interactive man-computer problemsolving situation.  Twenty
	subjects performed a planning task using the JOSS
	interactive computer system as a decisionmaking aid.  In
	the lockout conditions, the subject's terminal was
	mechanically locked out of the system for a specified
	length of time after each trial, i.e., after he had received
	a current set of results.

	In general, the subjects having a 5-min lockout period
	after each trial not only achieved better solutions to the
	problem than did the control (no lockout) group, but they
	also used far less computer time and less total working
	time.  A longer lockout period (8 min) appeared to be
	disruptive, especially for more experienced subjects.

	Other findings suggest that self-imposed restraint, such as
	that resulting from a restrictive charge algorithm, can also
	improve problemsolving efficiency, and that the users'
	acceptance of the system is not necessarily a valid predictor
	of system effectiveness.



15-Apr-79 12:05:25-PST,720;000000000001    
Mail-from: MIT-MC rcvd at 9-Apr-79 1553-PST
Date: 9 APR 1979 1539-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: MSGGROUP#1006  Sociology!
To: MSGGROUP at MIT-MC
Redistributed-To: DANIEL at OF1, JBROWN at MIT-MC
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 10 Apr 1979

Actually, I think "Methics" has very much to do with messages (that's
the "M", folks!) and thus is within a reasonable definition of
MsgGroup's teritory.  But if there's to be much discussion on any
individual topic which some people don't want to see (there ARE some
people who aren't interested?) then I think a Methics, or better yet
a Messages-Sociology group as Dave suggests.  Add me!

15-Apr-79 12:05:25-PST,523;000000000001 
Mail-from: MIT-ML rcvd at 9-Apr-79 1758-PST
Date: 9 April 1979 20:47-EST
From: Richard M. Stallman <RMS at MIT-AI>
Subject: MSGGROUP#1007  Effects of permanent record
To: MSGGROUP at MIT-AI
Redistributed-To: DANIEL at OF1, JBROWN at MIT-MC
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 10 Apr 1979

Perhaps we should try out a floating multiple com-link
instead of mail.
I think that GREEP is working on a system for this.
It might make effective communication easier.


15-Apr-79 12:05:25-PST,1938;000000000001
Date:  10 April 1979 01:30 est
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject: MSGGROUP#1008  RFC754 Comments
To:  Postel at USC-ISI
cc:  msggroup at MIT-ML
Message-ID:  <790410063026.016606 at MIT-Multics>

I have finally read RFC 754 (though still not 753) and generally agree
with the solutions.  My main gripes are:

1.  It does not support nesting.  The syntax should generalize to
multiple levels of forwarding.  The alternatives listed on the last
page using .on.  and .and.  exhibit this property (without upsetting
Hermes).  So does the .at.  of recent discussions.  Any of them would
be fine.  (Though which ever one is chosen gets disqualified as a
component of people names unless a character other than "."  is used.

2. It still assumes that the system does the forwarding.  The tendency
to require that features be built into the operating system must be
controlled.  THe operating system should only provide the hooks that
allow less priviliged programs to implement a facility.  In this case,
the "recipient:" field (a formilzation of your suggestion that the ftp
server put the recipient's name in the mail box) would be used by the
serving program which need not be part of the mailer.

The ITS systems already have a facility such that a program can be
associated with an address to immediately procsess mail.  Thus once
"NSW" is parsed out as the local agent for the next network, it can
immediately forward the message if that is appropriate.

One problem of taking this facility out of the system is that the
intermediate hosts cannot do proper acknowledgement for the final
recipient.  This would have to be done by mailing back (through the
reverse path) a deadletter notice, or, if requrest, an aknowledgement. 
The problems of determining the reverse path has been discussed in
recent letters and seems to require parsing of the headers by each
server.

15-Apr-79 12:05:26-PST,394;000000000001
Date:  10 April 1979 03:37 est
From:  Frankston.Frankston at MIT-Multics
Subject: MSGGROUP#1009  Re: RFC754 Comments
To:  Frankston.Frankston at MIT-Multics (Bob Frankston)
cc:  Postel at USC-ISI, msggroup at MIT-ML
In-Reply-To:  Msg of 04/10/79 01:30 from Bob Frankston

WHen it takes MIT-ML 2 hours to forward my letter back to me via
msggroup, I'd hardly call that instantaneOus.

15-Apr-79 12:05:26-PST,502;000000000001  
Date: 10 APR 1979 0920-PST
From: POSTEL at USC-ISIB
Subject: MSGGROUP#1010  Re:  RFC754 Comments
To:   Frankston.Frankston at MIT-MULTICS, Postel at USC-ISI
cc:   msggroup at MIT-ML, POSTEL

In response to the message sent 10 April 1979 01:30 est from
Frankston.Frankston@MIT-Multics


Bob:

Your points are well taken, but please remember that the "solutions"
proposed in rfc 754 are for the short term, and with the goal of
minimal changes to existing software.


--jon.
-------

15-Apr-79 12:05:26-PST,1209;000000000001    
Date:  11 April 1979 00:30 est
From:  Frankston.Frankston at MIT-Multics
Subject: MSGGROUP#1011  Re:  RFC754 Comments
To:  POSTEL at USC-ISIb
cc:  Frankston.Frankston at MIT-Multics, Postel at USC-ISI, 
     msggroup at MIT-ML
In-Reply-To:  Msg of 04/10/79 12:20 from POSTEL

The main point of my remarks was that my proposals were compatable with
yours and imply the same level of effort.  It is just that by saying
"Fred.at.NSW at FRDW" one can extend to "Joe.at.Nextelevel.at.NSW at
FWDR" with no additional effort.  The "Fred.at.NSW" syntax is just a
choice of a specific one of your proposals, but has the advantage of
allowing extensions.  Of course, it would be convenient if the
imlementor of an FTP server that does parsing handles .at.  nesting
from the start.  In any case, one can always register "Fred.at.NSW" as
a user and make no changes to the FTP server.


PS: Palter pointed out that I replied to the wrong mailing list,
apparently this discussion got started on header-people.  Does anyone
object to removing the distinctions between the two sinc I cannot
remember which one a given message came from anyway?  Or at least
allowing one to be a subset of the other.

15-Apr-79 12:05:26-PST,477;000000000000  
Mail-from: MIT-ML rcvd at 10-Apr-79 2256-PST
Date: 10 Apr 1979 2240-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP#1012  Re:  Re: RFC754 Comments
From: STEFFERUD at USC-ISI
To: Frankston.Frankston at MIT-MULTICS
Cc: Postel, msggroup at MIT-ML
Message-ID: <[USC-ISI]10-Apr-79 22:40:16.STEFFERUD>
In-Reply-To: Your message of  10 April 1979 03:37 est

THERE ARE 133 MAILBOXES IN MSGGROUP( 135 WITH THE NEXT INCREMENT).

2 HOURS SOUNDS PRETTY GOOD TO ME.  STEF

15-Apr-79 12:05:26-PST,412;000000000000  
Mail-from: MIT-ML rcvd at 11-Apr-79 1244-PST
Date: 11 Apr 1979 1157-PST
Sender: FARBER at SRI-KA
Subject: MSGGROUP#1013  Re:  Re:  RFC754 Comments
From: FARBER at SRI-KA
To: Frankston.Frankston at MIT-MULTICS
Cc: POSTEL at USC-ISIB, Postel at USC-ISI, msggroup at MIT-ML
Message-ID: <[SRI-KA]11-Apr-79 11:57:04.FARBER>
In-Reply-To: Your message of  11 April 1979 00:30 est

f header-people.

Dave

15-Apr-79 12:05:26-PST,449;000000000000
Mail-from: MIT-MC rcvd at 11-Apr-79 1417-PST
Date: 11 Apr 1979 1359-PST
Sender: FARBER at SRI-KA
Subject: MSGGROUP#1014  A garbled message
From: FARBER at SRI-KATo: frankston.frankston at MIT-MULTICS
Cc: msggroup at MIT-MC
Message-ID: <[SRI-KA]11-Apr-79 13:59:35.FARBER>

I  meant  to  say  that I thought that separate header-people and
mssgroup distribution  lists  would  be  preferable  since  their
interests are separate.

Dave

15-Apr-79 12:05:26-PST,1142;000000000000 
Mail-from: MIT-MC rcvd at 12-Apr-79 1740-PST
Date: 12 APR 1979 1736-PST
From: MACKENZIE at USC-ECL
Subject: MSGGROUP#1015  METHICS and the Fast Draw(cont'd)
To:   ~drxal-hda at OFFICE-1
cc:   msggroup at MIT-MC, malasky at PARC-MAXC

    In regard to your message a few days ago concerning the loss 
    of meaning in this medium: 
 
    I am new here, and thus hesitate to comment, but I too have
    suffered from the lack of tone, gestures, facial expressions 
    etc. May I suggest the beginning of a solution? Perhaps we could 
    extend the set of punctuation we use, i.e: 
 
            If I wish to indicate that a particular sentence is meant 
            with tongue-in-cheek, I would write it so:
 
            "Of course you know I agree with all the current
            administration's policies -)."
 
            The "-)" indicates tongue-in-cheek. 
 
    This idea is not mine, but stolen from a Reader's Digest article 
    I read long ago on a completly different subject. I'm sure there 
    are many other, better ways to improve our punctuation.
 
    Any comments?
 
    Kevin
-------

15-Apr-79 12:05:26-PST,2473;000000000000
Mail-from: MIT-MC rcvd at 12-Apr-79 1900-PST
From: Grm at Rand-Unix
Date: 12 Apr 1979 at 1850-PST
To: mackenzie at Usc-Ecl
cc: Grm at Rand-Unix, msggroup at Mit-Mc
From the tty of: Gary R. Martins
 .:.
Subject: MSGGROUP#1016  Text-ural Tricks
 .:.

Kevin -

        I cannot resist a quick-draw reply to your note on
METHICS &c; please do not be offended if I fail to address your
more favored issues squarely.

        Your suggestion -- for auxiliary notation to express the
author's attitudes etc. in text -- is naive but not stupid.
George B.  Shaw, whose skill with English is beyond dispute,
spent lots of time and money on foolish schemes to 'improve' the
spelling of English; i.e., to tighten the mapping from text to
sounds (without ever fully appreciating the implicit disaster of
further loosening other vital mappings -- historical,
etymological, etc.).  He was very naive, but hardly stupid.

        Your proposal suggests new technological devices to
improve written communication.  My own observations of the
problem suggest a different, less romantic, approach: more
skillful use of the existing technology.  Are the standard
devices of written English not capable of conveying even the most
subtle attitudes and postures ?  In the hands of the masters, it
is an exquisite instrument of expression.  Does Bill Shakespeare
leave us, for a moment, in doubt as to Marc Antony's real
feelings about Brutus -- even as his words display praise and
admiration ?  When Othello mourns his lack of erudition, his
meagre rhetorical skills, the very speech itself contradicts his
unwarranted modesty.  All this without the benefit of such
pragmatical punctuation as you have suggested.

        But from the hands of clods we must expect cloddish text
-- opaque, ambiguous, meandering like the thinking it so
mercilessly depicts.  Those who will not learn to use this
instrument well cannot be saved by an expanded alphabet; they
will only afflict us with expanded gibberish, as untrustworthy
and inconsequential as their current product. (I doubt that even
the so-called Reader's Digest has adopted any such notational
shift.)

        The Danish comedian Victor Borge used to punctuate his
speech with odd whistles and clicks to denote the extra apparatus
(parentheses etc.) available to the writer but not,
conventionally, to the speaker.  While funny in short doses, it
somehow never caught on!


				Gary

15-Apr-79 12:05:27-PST,955;000000000000    
Mail-from: MIT-ML rcvd at 13-Apr-79 1155-PST
Date: 13 Apr 1979 1059-PST
Sender: FARBER at SRI-KA
Subject: MSGGROUP#1017  really I didnot say
From: FARBER at SRI-KA
To: msggroup at MIT-ML
Message-ID: <[SRI-KA]13-Apr-79 10:59:27.FARBER>

I have heard suspicion that my "famous" note ( a copy of which is
enclosed) was a mistyping of a certain 4 letter word.  It was the
result  of  hermes  or  someone  looping off a line.  I am really
innocent.

The text was intended to say  that  msggroup  and  header  people
should be separate mailing lists.

Dave

I am sure some will not believe me but it is really true and from
now on I will read before sending

Dave

Date: 11 Apr 1979 1157-PST
From: FARBER at SRI-KA - - Sender: FARBER at SRI-KA
To: Frankston.Frankston at MIT-MULTICS
Cc: POSTEL at USC-ISIB, Postel at USC-ISI, msggroup at MIT-ML
In-Reply-To: Your message of  11 April 1979 00:30 est

f header-people.

Dave



15-Apr-79 12:05:27-PST,433;000000000000 
Mail-from: MIT-ML rcvd at 13-Apr-79 1213-PST
Date: 13 APR 1979 1156-PST
From: POSTEL at USC-ISIB
Subject: MSGGROUP#1018  Re: really I didnot say
To:   FARBER at SRI-KA, msggroup at MIT-ML
cc:   POSTEL

In response to the message sent 13 Apr 1979 1059-PST from FARBER@SRI-KA


Dave:

i was sure that was the case all along, but i am having a little
trouble inventing the missing line, what was it ?

--jon.
-------

15-Apr-79 12:05:27-PST,934;000000000000
Mail-from: MIT-ML rcvd at 13-Apr-79 1245-PST
Date: 13 APR 1979 1228-PST
From: JMCHUGH at USC-ECL
Subject: MSGGROUP#1019  Re: really I didnot say
To:   FARBER at SRI-KA, msggroup at MIT-ML
cc:   JMCHUGH

In response to the message sent 13 Apr 1979 1059-PST from FARBER@SRI-KA

Dave, you have added a chuckle to the day.  I guess that I don't have a
dirty mind or I would have gotten the chuckle on the original message.

I think that your experience emphasizes the need for a function that
may not be easily available to all of us, i.e., the ability to see the
message as it will be sent/received.  For example, I'm now answering
you in MSG (under TENEX) and cannot easily see a copy of the message as
it will be sent.

Can you imagine a manager in a commercial enterprise doing what I am
doing, that is, sending a communication without seeing the exact
spelling and placement, etc.

Cheers  -    Jim
-------

15-Apr-79 12:05:27-PST,497;000000000000  
Mail-from: MIT-ML rcvd at 13-Apr-79 1309-PST
Date: 13 Apr 1979 1222-PST
Sender: FARBER at SRI-KA
Subject: MSGGROUP#1020  Re: really I didnot say
From: FARBER at SRI-KA
To: POSTEL at USC-ISIB
Cc: msggroup at MIT-ML
Message-ID: <[SRI-KA]13-Apr-79 12:22:23.FARBER>
In-Reply-To: Your message of 13 APR 1979 1156-PST

It was:

I believe that msggroup and headers people should be separate due
to the pragmatic nature o

(at that point things broke and so the f header-people.

Dave

15-Apr-79 12:05:27-PST,755;000000000001    
Date:  9 Apr 1979 1239-PST
Subject: MSGGROUP#1021  New RFC 754 Available
From: POSTEL at USC-ISIE
To: [isie]<Mamie>Request-For-Comments.List:
Redistributed-To: STEFFERUD
Redistributed-By: NMA at BBN-TENEXA
Redistributed-Date: 13 Apr 1979
Mail-from: BBN-TENEXA rcvd at 13-Apr-79 1534-PST


      RFC 754 is now available in the NIC online library at SRI-KL.

         Title:   Out-of-Net Host Addresses for Mail
         Author:  Jon Postel
         Pages:   10

            pathname: <NETINFO>RFC754.TXT

      Public access files may be copied from the NIC library at SRI-KL
      via FTP with username NICGUEST and password ARPA (actually SRI-KL
      allows copying of public access files via FTP without a login).

      --jon.
15-Apr-79 12:05:27-PST,892;000000000000  
Mail-from: MIT-ML rcvd at 13-Apr-79 1510-PST
Date: 13 APR 1979 1457-PST
From: JMCHUGH at USC-ECL
Subject: MSGGROUP#1022  Viewing Messages
To:   MSGGROUP at MIT-ML

Followup to message from JMcHugh to Dave Farber@SRI-KL SENT 13 APR 1979
1228-PST

For those of you who responded with the helpful suggestions on the
CONTROL-S (to display a message body) and the CONTROL-R (to display a
line) in MSG --- Thank You!  I was not aware of the CONTROL-S command.
The help documentation appears to be somewhat inadequate for the
novice. . . .

However, this still leaves the problem that I tried to communiicate in
my message to Dave:  I would like to see the WHOLE message including
addresses, etc.  A user (manager) in sending a message is in effect
"signing" the document --- and he really would like to see the whole
thing before committing himself.

Cheers -  Jim
-------

15-Apr-79 12:05:27-PST,421;000000000001   
Mail-from: MIT-ML rcvd at 13-Apr-79 1533-PST
Date: 13 Apr 1979 1522-PST
From: Bair at SRI-KL (James Bair)
Subject: MSGGROUP#1023  Re: really I didnot say
To:   JMCHUGH at USC-ECL, FARBER at SRI-KA, msggroup at MIT-ML
cc:   BAIR

In response to the message sent 13 APR 1979 1228-PST from JMCHUGH@USC-
ECL

Jim,  What about control E? (retypres entire msg).

s  , Jim (I may choose not to edit it.)
-------

15-Apr-79 12:05:27-PST,592;000000000000  
Mail-from: MIT-ML rcvd at 13-Apr-79 1633-PST
Date: 13 Apr 1979 1618-PST
Sender: GEOFF at SRI-KA
Subject: MSGGROUP#1024  Re: Viewing Messages
From: the tty of Geoffrey S. Goodfellow
To: JMCHUGH at USC-ECL
Cc: MSGGROUP at MIT-ML
Message-ID: <[SRI-KA]13-Apr-79 16:18:13.GEOFF>
In-Reply-To: Your message of 13 APR 1979 1457-PST
Reply-to: Geoff @ SRI-KA

The solution to your WHOLE message problem is to use the "SHOW"
command in HERMES.  It is the only mailsystem that runs on TENEX
that allows for this that i am aware of, with the exception of MM
which runs on TOPS-20's only.

15-Apr-79 12:05:27-PST,1001;000000000000  
Mail-from: MIT-ML rcvd at 13-Apr-79 2111-PST
Date: 13 Apr 1979 2055-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP#1025  Re: Viewing Messages
From: STEFFERUD at USC-ISI
To: GEOFF at SRI-KA
Cc: JMCHUGH at USC-ECL, MSGGROUP at MIT-ML
Message-ID: <[USC-ISI]13-Apr-79 20:55:02.STEFFERUD>
In-Reply-To: <[SRI-KA]13-Apr-79 16:18:13.GEOFF>

Close Goeff, but no cigar ... maybe a cigarillo?

Under certain conditions, when connected to other than your login
directory, depending on your profile switch settings, HERMES will
insert the connected directory name in the FROM field in place of the
login directory name.

Use of the SHOW command will not warn the user of this impending event,
as I learned with frequent disgrace until I changed my switch settings
to always put my login name in the FROM field.

Without the warning to be obtained via the SHOW command, the profile
switch settings are worse than useless.  They are definitely
disfunctional in my world.

Best - Stef

15-Apr-79 12:05:28-PST,1128;000000000000
Mail-from: MIT-ML rcvd at 13-Apr-79 2131-PST
Date: 13 Apr 1979 2116-PST
From: Stuart McLure Cracraft <McLure at SRI-KL>
Subject: MSGGROUP#1026  Hairy HEERMES syntax
To: STEFFERUD at USC-ISI, GEOFF at SRI-KA
Cc: JMCHUGH at USC-ECL, MSGGROUP at MIT-ML
In-reply-to: Your message of 13-Apr-79 2055-PST

Who the hell cares about hairy HERMES internals anyway? I certainly
don't. It is a hungus monster of a program that should never have been
given birth.  Any mail program that brings the system to a screeching
standstill whenever it is started and any program whose core image is
almost as big as INTERLISP's is a crime against nature. It is the most
inelegant program I have ever seen.

What TENEX badly needs is some wizard to come along and convert MM to
run on it. It could be done but would require an extraordinary effort.
Then and only then will TENEX have an efficient, powerful system for
mail handling. All these mail systems such as MSG and HERMES, written
in high-level languages do more for overloading KA's and KL's all over
the network than practically any other popular subsystem. 
-------

15-Apr-79 12:05:28-PST,605;000000000000    
Mail-from: MIT-ML rcvd at 13-Apr-79 2149-PST
Date:  14 April 1979 00:37 est
From:  Frankston.Frankston at MIT-Multics
Subject: MSGGROUP#1027  Re: Hairy HEERMES syntax
To:  Stuart McLure Cracraft <McLure at SRI-KL>
cc:  STEFFERUD at USC-ISI, GEOFF at SRI-KA, JMCHUGH at USC-ECL, 
     MSGGROUP at MIT-ML
In-Reply-To:  Msg of 04/14/79 00:16 from Stuart McLure Cracraft

And all these mail systems written in lower level language continue to
polute the world with random local syntaxes.  Twould be nice to have a
mail program available without having to buy a unique system on which
to runit.

15-Apr-79 12:05:28-PST,448;000000000000 
Mail-from: MIT-ML rcvd at 13-Apr-79 2205-PST
Date: 13 Apr 1979 2139-PST
From: Stuart McLure Cracraft <McLure at SRI-KL>
Subject: MSGGROUP#1028  Re:  Re: Hairy HEERMES syntax
To: Frankston.Frankston at MIT-MULTICS
Cc: STEFFERUD at USC-ISI, GEOFF at SRI-KA, JMCHUGH at USC-ECL, 
Cc: MSGGROUP at MIT-ML
In-reply-to: Your message of 14-Apr-79 0037-PST

Then you should dream up a truly portable and efficient language!
Good luck.
-------

15-Apr-79 12:05:28-PST,1326;000000000000  
Mail-from: MIT-ML rcvd at 13-Apr-79 2225-PST
Date: Saturday, 14 April 1979 0046-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: MSGGROUP#1029  Re: Hairy HEERMES syntax
To:   MsgGroup at MIT-ML
Message-ID: <14Apr79 004618 BR10@CMU-10A>
In-Reply-To: Stuart McLure Cracraft's message of 14 Apr 79 00:16

I think that programs like Hermes are very necessary.  It is
unfortunate that Hermes is slow, but a program that pushes on the state
of the art is better written in a high-level language.

It's pretty fuzzy in general what constitutes "research" in our
business, but writing programs that do things that have never been done
before is certainly research.  Hermes does lots of things that no other
message program on the net (save possibly CMU's Rdmail; thank you Phil
Karlton) does.  It is not the job of a research venture to be
efficient.

On the other hand, it is a tribute to Hermes' power that so many people
use it in spite of its size and speed.  Yes, there should exist fast
and efficient system software.  While I don't think that assembler is
necessary (BLISS-11, for example, generates better code than most
hackers), I think that efficiency is necessary.  But only after
experience with state-of-the art programs like Hermes can we know what
to make the efficient ones do.

Brian

15-Apr-79 12:05:28-PST,1421;000000000000  
Mail-from: MIT-ML rcvd at 13-Apr-79 2248-PST
Date:  14 April 1979 00:49 est
From:  Frankston.Frankston at MIT-Multics
Subject: MSGGROUP#1030  Re:  Re: Hairy HEERMES syntax
To:  Stuart McLure Cracraft <McLure at SRI-KL>
cc:  Frankston.Frankston at MIT-Multics, STEFFERUD at USC-ISI, 
     GEOFF at SRI-KA, JMCHUGH at USC-ECL, MSGGROUP at MIT-ML
In-Reply-To:  Msg of 04/14/79 00:39 from Stuart McLure Cracraft

Pascal and PL/I are two strong contenders for a mail system
implementation language.  The problem is getting DEC to provide
effective versions on their machines.  I assume that there is a
reasonable Pascal on the 10.  My preference is for PL/I and I don't
expect to see it on the 10's in the near future, but Pascal might be a
coporomise.  BCPL is another choice, but not very high level.  Other
universal languages?  C?

In any case, the problem is not the lack of languages, but the lack of
standard language/operating system environments that one can assume
when providing such software.

TO the extent that such an environment does exist, at least a common
subset, the implementation of a "common" mail program that can be
assumed would be in the interest of getting past some of these local
issues.  BUt in a sense we are back in the early days of mail system.
While people recognize their utility, it is not obvious that ARPA is
ready to fund the development of a new program.

15-Apr-79 12:05:28-PST,1099;000000000000    
Mail-from: MIT-ML rcvd at 13-Apr-79 2305-PST
Date: 13 Apr 1979 2157-PST
From: Stuart McLure Cracraft <McLure at SRI-KL>
Subject: MSGGROUP#1031  Re:  Re:  Re: Hairy HEERMES syntax
To: Frankston.Frankston at MIT-MULTICS
Cc: msggroup at MIT-ML
In-reply-to: Your message of 14-Apr-79 0049-PST

The basics of the languages for such programs will always have to be
system dependent. You can't get around that. P-20 on TOPS-20 is a
fairly efficient implementation of PASCAL, but its method for
accessing files is not nearly powerful enough to make an efficient
mail system.

I wouldn't hold my breath for PL/I to become a major language for
implementing subsystems on TENEX or TOPS-20.

C sounds interesting but not nearly enough work has been done on it
outside of UNIX.

Thus far, the only language that I have seen that seems to be fairly
high-level, efficient, and will run on TOPS-20 is BLISS. I could see a
very advanced mail system written in it, but its portability would be
extremely limited. 

(Btw, your mail system still has the reproducing RE:'s lossage.)
-------

15-Apr-79 12:05:28-PST,1565;000000000000   
Mail-from: MIT-ML rcvd at 13-Apr-79 2324-PST
Date:  14 April 1979 01:25 est
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject: MSGGROUP#1032  Ye Olde Higher Level Language Debate.
To:  McLure at SRI-KL, BR10 at CMU-10a
cc:  msggroup at MIT-ML
Message-ID:  <790414062535.334027 at MIT-Multics>

The fact that Pascal doesn't have the necessary file handling
mechanisms is irrelevent.  One defines the language for a mail system
by defining the apPropriate primitives and then programming using them.
At some level the local implementor will need to bring his/her system
up to the level necessary to support the langugae used.  Most commonly
this can be done by a set of subroutines and data objects (Pascal
records, PL/I structures etc) (and in better languages there is little
distinction between the active and passive entitites).  Thus to build
the universal mail system, define the primitives such as "get next
letter" and "edit text buffer" and then impleemnt the higher level
structure.  Assuming the system implements the chosen source language.

While I am against assembler for the simle reason that I have better
uses for my time than moving little tiny bits around a limited number
of registers or whatver the random base structure of the given machine
is, I am more concerned about the 30th implementation of the same damn
program.  Each a little different as we know in the case of various
text processors, even when they call themselves runoff.  This is an
amazing waste of a scarce resource -- progrmamers.

15-Apr-79 12:05:28-PST,913;000000000000 
Mail-from: MIT-ML rcvd at 13-Apr-79 2342-PST
Date: 13 Apr 1979 2238-PST
Sender: GEOFF at SRI-KA
Subject: MSGGROUP#1033  Re: Hairy HEERMES syntax
From: the tty of Geoffrey S. Goodfellow
To: BR10 at CMU-10A
Cc: MsgGroup at MIT-ML
Message-ID: <[SRI-KA]13-Apr-79 22:38:11.GEOFF>
In-Reply-To: <14Apr79 004618 BR10@CMU-10A>
Reply-to: Geoff @ SRI-KA

Re:  your last paragraph.

Basicly the only reason why we are all (stuck with) using HERMES to
process our mail can best be compared to using Listerene to combat bad
breath:  We use it (one or more times daily) because it is the only
thing available on the market/TENEX&TOPS-20 that does what it does,
albeit we don't like its taste, but we are stuck with it because there
ain't nothing else.  Give us a new product/mailsystem that'll do the
same (and even more?)  with a better taste, and we'll all happyly
abandon our HERMES's and Listerene's.

15-Apr-79 12:05:29-PST,1467;000000000000 
Mail-from: MIT-ML rcvd at 14-Apr-79 0013-PST
Date: 13 Apr 1979 2352-PST (Friday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: MSGGROUP#1034  Message System Standards
To: MSGGROUP at ML

I am not at all sure I really want to say this, but I'm going to
go ahead anyway...

Perhaps what we need is (sigh) a "standard" for message systems
(i.e. message reading/replying/sending systems) as differentiated
from a standard for messages themselves.  This puts aside
the question of implementation languages (which I'm sure will not
be settled for a LONG time yet), and concentrates instead on
the real issue -- how the message system looks to the user.
I submit that the two standards, while having much in common, would
be largely of different content.  Such issues as "what sort
of features, options, defaults, etc." would be expected in a
"lowest common denominator" message system, as well as more 
advanced ones, could all be defined.

Now that I've said this, I will admit that the whole idea is no
doubt doomed to failure for a number of reasons ...
1) Nobody wants more standards that nobody will pay attention to.
2) Nobody would want to alter existing message systems to fit
   the new standards.
3) We would probably never be able to agree on such topics as
   what must be included in the "least common denominator"
   message system.

You can all no doubt add additional items to the list.

--Lauren--
-------


15-Apr-79 12:05:29-PST,2683;000000000000
Mail-from: MIT-ML rcvd at 14-Apr-79 0042-PST
Date: 14 Apr 1979 0029-PST
From: Mark Crispin <MRC at SU-AI>
Subject: MSGGROUP#1035  assembly vs. high-level languages 
To:   MsgGroup at MIT-ML    

This debate is going on for ages.  The two "sides" seem to be:

 .  High-level languages are alright, but to do X in the most
    efficient manner possible exercising the functionality of the
    operating system to its fullest extend I need to program in
    assembly language.  My interactive program depends upon fast and
    friendly response, and needs to be efficient if I am going to run
    at all well on this machine with 80 other users on it.
 .  Assembly language is intrinsicly evil.  People should not be
    allowed to program in assembly language.  Programs have to be
    rewritten if it is to be taken to a different machine if written
    in assembly language.  The efficiency difference between assembly
    and high-level language code is unimportant; computers are cheap
    and people should buy more computers.

I think it is fairly common knowledge that I am in the first school of
thinking.  I have never advocated assembly language as the thing for a
person to learn in learning how to program.  Neither have I advocated
it for most user application purposes, especially for user-maintained
and debugged software.  But I do not believe that I am evil because
most of my programming is in assembly language.  There is a place for
everything in this day and age, including assembly language
programming.

I believe that today the idea of a machine-independent programming
language is a myth.  Few programs that I've seen can be transported
from one machine to another without modification.  The closest is
COBOL; is anybody suggesting that message systems should be written in
COBOL?  I also don't see what is so evil about having to rewrite
programs written on another machine.  Hardware and software technology
continually changes.  Programs should not be patched to death; they
should be rewritten.  Or is anybody weeping over the lack of
tranportability of an IBM 1130 compiler to the System/38 (or of the
PDP-1 to the DECsystem-20)?

I am not arguing "for" assembly language as much as I am arguing
against the mentality that insists that people must be FORCED to use
PL/I, etc., and that implementation efficiency is unimportant.
Fortunately for the world of computing, must users don't give a damn
about what language the program is written in - they care about
performance, functionality and human engineering.  The sooner attention
is put on P,F&HE, and less on implementation languages, the better!



15-Apr-79 12:05:29-PST,278;000000000000 
Mail-from: MIT-ML rcvd at 14-Apr-79 0057-PST
Date:  14 April 1979 03:40 est
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject: MSGGROUP#1036  Weeping
To:  mrc at SU-AI
cc:  msggroup at MIT-ML
Message-ID:  <790414084042.173848 at MIT-Multics>

I weep.

15-Apr-79 12:05:29-PST,2258;000000000000
Mail-from: MIT-ML rcvd at 14-Apr-79 0130-PST
Date: 14 APR 1979 0111-PST
Sender: AHENDERSON at PARC-MAXC2
Subject: MSGGROUP#1037  Re: Message System Standards
From: AHENDERSON at PARC-MAXC2
To: lauren at UCLA-SECURITY
Cc: MSGGROUP at ML
Message-ID: <[PARC-MAXC2]14-APR-79 01:11:21.AHENDERSON>
In-Reply-To: Your message of 13 Apr 1979 2352-PST (Friday)

Those who don't know history, ...

In December of 1975, Steve Walker of IPTO, DARPA held a meeting
of people interested in message systems: I think it was one of
the only meetings of CAHCOM.  One agenda item - the only one
being really pushed for by Steve - was just such a "least common
denominator" for DARPA-sponsored message systems as you suggest.
An agreement was reached on the names of the commands, the
arguments they would take, and the defaults intended by omission
of arguments.  What seemed less important to those at the meeting
was the need to reach an agreement on the model of the objects
and the message systems, so that the intents of the commands -
the semantics of the various systems - would agree.  Thus for
example it was agreed there should be a NEXT command, which moved
the system's attention on to the next message and printed (typed,
showed, ?) it.  Implied in this description is the idea of a
"point of attention" - the so-called current message.  This
notion was never formally agreed upon (although some were pushing
for such an agreement).  The result was there was no push to
agree on what the effects of the OTHER commands in the "core"
system on that "point of attention" were to be.  For example, if
I PRINT a message, does that message become the current one?  How
about PRINTing a bunch of messages; or LISTing a single message;
or a bunch?  It is just such finicky details which makke moving
between systems hard.  In fact, it is aoten easier to move
between systems which are obviously different from one another,
than to move between systems which are close (eg.  Multics to
TENEX, vs.  TENEX to TOPS-20); the psychological term is
"interference".

The agreement caused some short-term changes in some systems, but
the lack of agreement on the underlying model led quickly back to
anarchy.  And here we are.

Austin

15-Apr-79 12:05:29-PST,1560;000000000000   
Mail-from: MIT-ML rcvd at 14-Apr-79 0147-PST
Date: 14 APR 1979 0122-PST
Sender: AHENDERSON at PARC-MAXC2
Subject: MSGGROUP#1038  "The same program" again and again.
From: AHENDERSON at PARC-MAXC2
To: MSGGROUP at MIT-ML
Message-ID: <[PARC-MAXC2]14-APR-79 01:22:54.AHENDERSON>

It is true that there are many programs doing very similar jobs
of helping users handle their messages.  These programs differ in
small but important ways.  The designers and implementers of
these progrmas think the differences matter.  I agree that they
do.

Unforunately users will continue to want changes, and new
features.  Tempers will run high on issues of taste ("religious
issues").  This will be a never-ending battle until we start
handing to our users ways to tailor systems to their own tastes.
Some systems, like Hermes, attempt to provide such tailoring
capacity throught the "switches" which have been recently
discussed.  I think this is a good step (I would, of course: I
was in on the design of Hermes a few years ago).

But I think the time has come to explore another direction: give
me a message system having a set of primitive commands, and some
"glue" for sticking them together to make more complex commands
to suit my fancy.  The glue would include control structures
(sequences, conditions, loops).  I may even need variables.  Keep
it clean and simple, but elegant and sophisticated.

To do this well is a HARD task.  I submit that such a program is
the one we (or some of us) ought to be trying to write next.

Austin

15-Apr-79 12:05:29-PST,813;000000000000 
Mail-from: MIT-ML rcvd at 14-Apr-79 0210-PST
Date:  14 April 1979 04:58 est
From:  Frankston.Frankston at MIT-Multics
Subject: MSGGROUP#1039  Re: Message System Standards
To:  AHENDERSON at PARC-MAXC2
cc:  lauren at UCLA-Security, MSGGROUP at MIT-ML
In-Reply-To:  Msg of 04/14/79 04:11 from AHENDERSON

In some of my earlier letters I was going to suggest th eidea of the
least common denominator mail program, but remembered that there was a
network standard editor defined.  This was actually implemented on a
few systems and, at Multics, it was called "neted".  Unfortunately it
was a pitiful editor and has fortunately fallen into disuse.

I did forget about the early attempts at editor standards.  In fact,
the current Multics editor evolved from attempts at implementing such
standards.

15-Apr-79 12:05:29-PST,1424;000000000000    
Mail-from: MIT-ML rcvd at 14-Apr-79 0309-PST
Date: 14 Apr 1979 0246-PST (Saturday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: MSGGROUP#1040  message system "primitives"
To: MSGGROUP at ML

The closest I've seen to the approach of having a set of "primitives"
for a message system is the (officially unreleased) "mh" program
developed at Rand for Unix.

It basically consists of a whole slew of separate little programs
that can be strung together to perform more complex tasks.

It should be noted, however, that when I discussed this concept with
a number of people locally who are used to our local variant
of MSG (a Unix version written in "C" tailored after the TENEX
version), they expressed the opinion that they much preferred
the "integrated" approach of MSG instead of the "primitives"
apprach of "mh".  There are also a number of technical issues
of little direct interest to MSGGROUP.

I don't know what could really be done about standards.  I well
remember NETED.  It was just like network television -- when
you go for the lowest common denominator you may well end
up with nothing but mush when you're finished!  Whether this could
be avoided in a "message systems standard" is certainly
unclear -- I suspect that a simplistic message system would
still be of more utility to most users than a simplistic
"neted" type editor would be ...

--Lauren--
-------


15-Apr-79 12:05:30-PST,688;000000000001 
Mail-from: MIT-ML rcvd at 14-Apr-79 0322-PST
From: FFM@MIT-MC 
Date: 4/14/79 06:08:43
Subject: MSGGROUP#1041  Re: NLS and journal systems
To: msggroup at MIT-ML

I think the ajor problem with NLS is that it eats PDP10s
; the version I have seen have convinced me that it is wonderfully
powerful but suffers from exremely high overheadd. It seems
to take quite awhile to start up even at low system loads and
to get full beneift form requires expensive terminals and other
stuff. 

Perhaps some of the ideas from the NLS journal system can be
used as inspiraion for the development of a better
mail handling and reply system. 

Have fun
sends Steve

curse this adm3

15-Apr-79 12:05:30-PST,709;000000000000
Mail-from: MIT-ML rcvd at 14-Apr-79 0716-PST
Date: Saturday, 14 April 1979 1004-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: MSGGROUP#1042  Basically the only reason.....
To:   Geoff @ SRI-KA
CC:   MsgGroup at MIT-ML
Message-ID: <14Apr79 100444 BR10@CMU-10A>
In-Reply-To: <[SRI-KA]13-Apr-79 22:38:11.GEOFF>

You objected to my saying that Hermes is laudable for its 
power, then go on to explain that the only reason you use it
is because no other program does what you want.  I guess that's
what I was trying to say:  people might not like hermes, but
everybody uses it because of what it can do, in spite of
there being some 10 mail-reading programs that run on 
tenex-like systems.

15-Apr-79 12:05:30-PST,722;000000000000  
Mail-from: MIT-ML rcvd at 14-Apr-79 0731-PST
Date: Saturday, 14 April 1979 1007-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: MSGGROUP#1043  Re: Message System Standards
To:   lauren at UCLA-Security (Lauren Weinstein)
CC:   MSGGROUP at ML
Message-ID: <14Apr79 100715 BR10@CMU-10A>
In-Reply-To: Lauren Weinstein's message of 14 Apr 79 02:52

I suspect that we don't want a standard so much as we want a list
of desiderata.  What characteristics of mail systems have been found
to be terrible, and which ones have been found to be wonderful.
I cannot imagine that there is anybody on the net who has become
an experienced user of more than one or two such systems in order
to be able to compare them.

15-Apr-79 12:05:30-PST,569;000000000000
Mail-from: MIT-ML rcvd at 14-Apr-79 0748-PST
Date: Saturday, 14 April 1979 1015-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: MSGGROUP#1044  System primitives and glue
To:   AHENDERSON at PARC-MAXC2
CC:   MSGGROUP at MIT-ML
Message-ID: <14Apr79 101534 BR10@CMU-10A>
In-Reply-To: <[PARC-MAXC2]14-APR-79 01:22:54.AHENDERSON>

I think that system integration is a harder (but not grubbier) task
than programming, and that the tinkertoy approach (here are the parts;
build your own) to building sophisticated and heavily-used systems is
not a good one.

15-Apr-79 12:05:30-PST,1894;000000000000    
Mail-from: MIT-ML rcvd at 14-Apr-79 0812-PST
Date: 14 Apr 1979 0728-PST
From: Zellich at OFFICE-1
Subject: MSGGROUP#1045  Re: message system "primitives"
To:   MsgGroup at MIT-ML

There are 2 serious problems with using primitives to build a
message system (or ANY system) - actually more like 2 basic approaches,
each of which has 1 major problem:

  If you take the approach of having the ADP shop "write" the message
  system for the users (remember, the users are less and less the
  CS people these days - we have a whole buncha secretaries, managers,
  engineers, etc. using our systems), then you will still have the
  problem of many people being unhappy with the choice of included
  features, the command syntax, etc., just as we have today.

  If you take the approach of each user sticking the primitives
  together to build his/her own private tailored system, then you
  really run up against the thing mentioned above - the users ain't
  all programers anymore and they CAN'T intelligently build their
  own message system no matter how easy you think you made it for
  them.  I work with several people who can barely read and send
  mail with MSG.  I know one person (intelligent, but unused to
  online working, and right now a naive beginner in interactive
  systems - he'll learn) who hasn't yet caught on to the trick of
  using the Q<CR> (Quit command in MSG) when he's done.  He just
  hangs up the phone while still in the mail program!

Cheers,
Rich

(Personally, I AM building my own mail system - I'm using somebody
 else's "primitives" [some of them are pretty high-level] to tailor
 a sending and reading/filing system exactly the way I like to
 work.  I don't expect other people to particularly like my choice
 of features, though - I don't really plan to turn my system over
 to the rest of my community to use.)
-------

15-Apr-79 12:05:30-PST,1112;000000000000 
Mail-from: MIT-ML rcvd at 14-Apr-79 0833-PST
Date: 14 Apr 1979 0750-PST
From: Stuart McLure Cracraft <McLure at SRI-KL>
Subject: MSGGROUP#1046  Re: System primitives and glue
To: BR10 at CMU-10A, AHENDERSON at PARC-MAXC2
Cc: MSGGROUP at MIT-ML
In-reply-to: Your message of 14-Apr-79 0745-PST

I agree with integration over building from small blocks.  We are
entering the age when many users of systems will not be 'hackers' or
even people remotely familiar with the concept of basics contributing
to a whole.  They will be regular people, who merely want to use a
message system to communicate with other people.  In instances like
this, we should strive for integration rather than cleverness.  Keep
the building blocks message systems for the hackers who want more power
in their systems.  However, it is not clear to me that this is even
desirable.  We run the MM system on our KL-10, and its integration has
made it completely usable to both novice and experienced user alike,
even though the more experienced user definitely uses more of the
command set than the the former.
-------

15-Apr-79 12:05:30-PST,1165;000000000000   
Mail-from: MIT-ML rcvd at 14-Apr-79 0852-PST
Date: 14 Apr 1979 0758-PST
From: Stuart McLure Cracraft <McLure at SRI-KL>
Subject: MSGGROUP#1047  Re: Hairy HEERMES syntax
To: geoff at SRI-KA, br10 at CMU-10A
Cc: MsgGroup at MIT-ML
In-reply-to: Your message of 13-Apr-79 2238-PST

Please, let's not say that 'HERMES is the only thing available on the
market /TENEX&TOPS-20 ...'  This is just not the case.  Maybe for
TENEX, but on TOPS-20 we have MM which is far more desirable as a major
subsystem.  Many of the features of MM are the same.  The most notable
changes were casting off hairy template stuff (not really necessary,
and slows the program down since it has to look up the template
database of the profile) and implementing much better interfaces to
EMACS and trimming the help system to the HELP command that takes one
argument, usually a command at the particular level of interest rather
than a depth as is done in HERMES.

I feel that MM has everything that any reasonable person would want to
have in a mail system.  It is powerful, compact, and more importantly
extremely efficient and a working set size of 23 pages.
-------

15-Apr-79 12:05:30-PST,530;000000000000    
Mail-from: MIT-ML rcvd at 14-Apr-79 1208-PST
Date: 14 Apr 1979 1143-PST
Sender: FARBER at SRI-KA
Subject: MSGGROUP#1048  Re: Viewing Messages
From: FARBER at SRI-KA
To: JMCHUGH at USC-ECL
Cc: MSGGROUP at MIT-ML
Message-ID: <[SRI-KA]14-Apr-79 11:43:54.FARBER>
In-Reply-To: Your message of 13 APR 1979 1457-PST

There  is  another  problkem when you are hanging on the end of a
300 baud connection (soon and currently changing).  It is painful
to see it again.  yet it was clearly painful not to have looked.

Dave

15-Apr-79 12:05:30-PST,1780;000000000000   
Mail-from: MIT-ML rcvd at 14-Apr-79 1304-PST
Sender: Kiessig at Rand-Unix
Date: 14 Apr 1979 at 1242-PST
To: lauren at Ucla-Security
cc: MsgGroup at Ml
From: Kiessig at Rand-UNIX (Rick Kiessig)
Subject: MSGGROUP#1049  Re: message system "primitives"
In-reply-to: Your message of 14 Apr 1979 0246-PST

        Here at Rand we also used the TENEX-like MSG for some time (it's
still  around, in fact).  Since MH is still in the refinement stages, it
has not yet been installed as the "system standard".  Yet nearly all  of
our  users  (including the naive ones) use MH to handle their mail.  The
reasons are simple:

        1) You only need to remember 3 commands (inc, show, and comp) to
           be able to do all of the basic functions required to read and
           compose mail.

        2) A user "profile" is present  for  each  person.  This  allows
           some  very complex tailoring (at virtually no cost) for users
           who are "in the know".  This includes being able  to  specify
           which  editor and template to use in composing a message, for
           example.

From an implementation point of view, this system also some nice features:

        1) It is all written in a high level language called  "C".  This
           allows  us  to  respond  much more quickly to changes in user
           needs.

        2) All messages exist as individual files in a  named  "folder".
           This  eliminates  the  need  for the slower, almost data base
           features of MSG or MS.

        3) Since each individual program is relatively small, the system
           as a whole runs fairly quickly.

I really prefer using these "tinker toys" to the more "4 x  4"  approach
of most TENEX mail systems.

15-Apr-79 12:05:31-PST,4399;000000000000    
Mail-from: MIT-ML rcvd at 14-Apr-79 1348-PST
Date: 14 Apr 1979 1303-PST
From: Geoff Goodfellow <GFF at SU-AI>
Subject: MSGGROUP#1050  Carter / Privacy 
To:   Msggroup at MIT-ML    

 
AM-PRIVACY
Carter Proposes Privacy Protection for Financial, Medical, Press
Records
By MARTIN TOLCHIN
c.1979 N.Y. Times News Service
    WASHINGTON - President Carter asked Congress Monday for legislation
to protect Americans from computer-age threats to privacy that he
called ''undreamed of 200 years ago.''
    As part of his legislative package, the president reversed his
original position and sought legislation to reverse the Supreme Court
decision in the Stanford Daily case, which upheld the
constitutionality of police searches of newspaper offices. He said
that the decision ''poses dangers to the effective functioning of our
free press.''
    Vice President Walter Mondale told a White House news briefing that
''personal information about millions of Americans is being flashed
across the nation from computer to computer.''
    To counter the ensuing loss of privacy, Mondale said, the
administration had formulated, for the first time in American
history, ''a comprehensive national policy to protect the privacy of
Americans.''
    Civil rights leaders gave cautious approval to the legislative
package, which seeks privacy protection for medical and financial
records, and federally funded research records. The president also
opposed a proposal to allow federal officials below the rank of
assistant attorney general to apply to the courts for wiretaps, and
proposed limits to the use of lie detectors in private employment.
    The president's reversal of the administration's original position
in Zurcher v. Stanford Daily involved a case in which police searched
the Stanford University student newspaper offices in Palo Alto,
Calif., for photographs of a student demonstration in which several
police officers were injured. The police had obtained a search
warrant to inspect the Stanford Daily newsroom.
    The administration had filed a friend of the court brief supporting
the position that the First Amendment did not ban police searches of
reporters' notes, film and interview files, even when the reporters
themselves were not suspected of any wrongdoing.
    Monday's proposed legislation would ban such searches and seizures
of the work of newsmen, scholars, novelists and others involved in
the dissemination of information to the public. Exceptions would be
made only in those cases in which the person holding the material was
suspected of having committed a crime, or in ''life-endangering
situations'' involving documents such as ransom notes.
    The poposed bill would delineate a civil right of privacy and civil
penalties, such as punitive damages, but does not contemplate
criminal penalties.
    In proposing privacy protection for medical and financial records,
Carter told Congress that he was basing his privacy policy on two
principles involving fair information practices and limits on the
government.
    He said that individuals should be told what kind of information is
being collected about them, how it would be used, and to whom it
would be disclosed. They should be able to see and obtain a copy of
the records and correct any errors. They should be told the basis for
an adverse decision that may be based on personal data, and should be
able to prevent improper access to the records.
    The Privacy of Medical Information Act would allow indivduals to
participate in decisions to disclose their medical records, with some
limited exceptions for emergency uses. Government access to those
records would be limited and individuals would have the right to see
their own records.
    The Privacy of Research Records Act, would grant subjects of medical
research confidentiality except in some cases involving a medical
emergency.
    The Fair Financial Information Practices Act, consumers would have
the right to see and copy credit and investigative reports about
them. Creditors would be required to inform individuals about their
information collection and disclosure practices.
    The act also would create ''a clear, legally enforceable expectation
of confidentiality, regarding disclosue of records,'' the
administration said.
    
ny-0402 1935est
***************



20-Apr-79 19:00:44-PST,6930;000000000001   
Mail-from: MIT-ML rcvd at 15-Apr-79 1311-PST
Date: 15 Apr 1979 1216-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP#1051  SURVEY [ISI]<MSGGROUP>PROCEEDINGS.MSG#1001-#1050
From: STEFFERUD at USC-ISI
To: MSGGROUP at MIT-ML
Message-ID: <[USC-ISI]15-Apr-79 12:16:55.STEFFERUD>
Redistributed-To: FEINLER at KL
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 19 Apr 1979

 -- Messages from file: [USC-ISI]<MSGGROUP>PROCEEDINGS.MSG#1001-#1050;1

   50  14 Apr  Geoff Goodfellow <GFF MSGGROUP#1050  Carter / Privacy 
                                     (4399 chrs)
   49  14 Apr  Kiessig at Rand-UNIX  MSGGROUP#1049  Re: message system 
                                     "primitives" (1780 chrs)
   48  14 Apr  FARBER at SRI-KA      MSGGROUP#1048  Re: Viewing Message
                                     (530 chrs)
   47  14 Apr  Stuart McLure Cracraf MSGGROUP#1047  Re: Hairy HEERMES 
                                     syntax (1165 chrs)
   46  14 Apr  Stuart McLure Cracraf MSGGROUP#1046  Re: System 
                                     primitives and glue (1112 chrs)
   45  14 Apr  Zellich at OFFICE-1   MSGGROUP#1045  Re: message system 
                                     "primitives" (1894 chrs)
   44  Saturd  Brian K. Reid <BR10 a MSGGROUP#1044  System primitives 
                                     and glue (569 chrs)
   43  Saturd  Brian K. Reid <BR10 a MSGGROUP#1043  Re: Message System 
                                     Standards (722 chrs)
   42  Saturd  Brian K. Reid <BR10 a MSGGROUP#1042  Basically the only 
                                     reason..... (709 chrs)
   41  4/14/7  FFM@MIT-MC            MSGGROUP#1041  Re: NLS and journal
                                     systems (688 chrs)
   40  14 Apr  lauren at UCLA-Securi MSGGROUP#1040  message system 
                                     "primitives" (1424 chrs)
   39  14 Apr  Frankston.Frankston a MSGGROUP#1039  Re: Message System 
                                     Standards (813 chrs)
   38  14 APR  AHENDERSON at PARC-MA MSGGROUP#1038  "The same program" 
                                     again and again. (1560 chrs)
   37  14 APR  AHENDERSON at PARC-MA MSGGROUP#1037  Re: Message System 
                                     Standards (2258 chrs)
   36  14 Apr  Frankston.Frankston a MSGGROUP#1036  Weeping (278 chrs)
   35  14 Apr  Mark Crispin <MRC at  MSGGROUP#1035  assembly vs. 
                                     high-level languages  (2683 chrs)
   34  13 Apr  lauren at UCLA-Securi MSGGROUP#1034  Message System 
                                     Standards (1467 chrs)
   33  13 Apr  the tty of Geoffrey S MSGGROUP#1033  Re: Hairy HEERMES 
                                     syntax (913 chrs)
   32  14 Apr  Frankston.Frankston a MSGGROUP#1032  Ye Olde Higher 
                                     Level Language Debate. (1565 chrs)
   31  13 Apr  Stuart McLure Cracraf MSGGROUP#1031  Re:  Re:  Re: Hairy
                                     HEERMES syntax (1099 chrs)
   30  14 Apr  Frankston.Frankston a MSGGROUP#1030  Re:  Re: Hairy 
                                     HEERMES syntax (1421 chrs)
   29  Saturd  Brian K. Reid <BR10 a MSGGROUP#1029  Re: Hairy HEERMES 
                                     syntax (1326 chrs)
   28  13 Apr  Stuart McLure Cracraf MSGGROUP#1028  Re:  Re: Hairy 
                                     HEERMES syntax (448 chrs)
   27  14 Apr  Frankston.Frankston a MSGGROUP#1027  Re: Hairy HEERMES 
                                     syntax (605 chrs)
   26  13 Apr  Stuart McLure Cracraf MSGGROUP#1026  Hairy HEERMES synta
                                     (1128 chrs)
   25  13 Apr  Stefferud at USC-ISI  MSGGROUP#1025  Re: Viewing Message
                                     (1001 chrs)
   24  13 Apr  the tty of Geoffrey S MSGGROUP#1024  Re: Viewing Message
                                     (592 chrs)
   23  13 Apr  Bair at SRI-KL (James MSGGROUP#1023  Re: really I didnot
                                     say (421 chrs)
   22  13 APR  JMCHUGH at USC-ECL    MSGGROUP#1022  Viewing Messages
                                     (892 chrs)
   21   9 Apr  POSTEL at USC-ISIE    MSGGROUP#1021  New RFC 754 Availab
                                     (755 chrs)
   20  13 Apr  FARBER at SRI-KA      MSGGROUP#1020  Re: really I didnot
                                     say (497 chrs)
   19  13 APR  JMCHUGH at USC-ECL    MSGGROUP#1019  Re: really I didnot
                                     say (934 chrs)
   18  13 APR  POSTEL at USC-ISIB    MSGGROUP#1018  Re: really I didnot
                                     say (433 chrs)
   17  13 Apr  FARBER at SRI-KA      MSGGROUP#1017  really I didnot say
                                     (955 chrs)
   16  12 Apr  Grm at Rand-Unix      MSGGROUP#1016  Text-ural Tricks
                                     (2473 chrs)
   15  12 APR  MACKENZIE at USC-ECL  MSGGROUP#1015  METHICS and the 
                                     Fast Draw(cont'd) (1142 chrs)
   14  11 Apr  FARBER at SRI-KATo: f MSGGROUP#1014  A garbled message
                                     (449 chrs)
   13  11 Apr  FARBER at SRI-KA      MSGGROUP#1013  Re:  Re:  RFC754 
                                     Comments (412 chrs)
   12  10 Apr  Stefferud at USC-ISI  MSGGROUP#1012  Re:  Re: RFC754 
                                     Comments (477 chrs)
   11  11 Apr  Frankston.Frankston a MSGGROUP#1011  Re:  RFC754 Comment
                                     (1209 chrs)
   10  10 APR  POSTEL at USC-ISIB    MSGGROUP#1010  Re:  RFC754 Comment
                                     (502 chrs)
   9   10 Apr  Frankston.Frankston a MSGGROUP#1009  Re: RFC754 Comments
                                     (394 chrs)
   8   10 Apr  Frankston.Frankston a MSGGROUP#1008  RFC754 Comments
                                     (1938 chrs)
   7    9 Apr  Richard M. Stallman < MSGGROUP#1007  Effects of 
                                     permanent record (523 chrs)
   6    9 APR  RWK at MIT-MC (Robert MSGGROUP#1006  Sociology!
                                     (720 chrs)
   5    9 Apr  Anderson at Rand-Unix MSGGROUP#1005  Re: #981  MsgGroup 
                                     administration (2072 chrs)
   4    9 Apr  WILLIAM G. MARTIN     MSGGROUP#1004  METHICS and the 
                                     Fast Draw (4969 chrs)
   3    9 Apr  Fylstra at SRI-KL     MSGGROUP#1003  Re: In defense of 
                                     flames (1257 chrs)
   2   Mon,    dcrocker at Rand-Unix MSGGROUP#1002  Re: #981  MsgGroup 
                                     administration (728 chrs)
   1    9 Apr  Stefferud at USC-ISI  MSGGROUP#1001  SURVEY [ISI]<MSGGRO
                                     UP>PROCEEDINGS.MSG#951-#1000
                                     (7517 chrs)

20-Apr-79 19:00:44-PST,516;000000000000   
Mail-from: MIT-ML rcvd at 14-Apr-79 1514-PST
Date: 14 April 1979 1737-EST (Saturday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: MSGGROUP#1052  standard message systems
To:   MSGGROUP at ML
Message-ID: <14Apr79 173745 RG02@CMU-10A>
In-Reply-To: Lauren Weinstein's message of 14 Apr 79 05:46

Why bothr with standards?  BBN won't implement them anyway, so TENEX
users will still have all the problems they have now.  Lets just all go
home and huddle in our own private caves.

		Rick

20-Apr-79 19:00:45-PST,578;000000000000 
Mail-from: MIT-ML rcvd at 14-Apr-79 1529-PST
Date: 14 Apr 1979 1517-PST
Sender: GEOFF at SRI-KA
Subject: MSGGROUP#1053  Re:.standard.message.systems
From: the.tty.of.Geoffrey.S..Goodfellow
To: Rick.Gumpertz at CMU-10A
Cc: MSGGROUP at ML
Message-ID: <[SRI-KA]14-Apr-79 15:17:54.GEOFF>
In-Reply-To: <14Apr79.173745.RG02@CMU-10A>
Reply-to: Geoff @ SRI-KA

Well,.almost...You.left.out.one.very.small,.but.important.thing.
Its.called."FUNDING"...Give.BBN.some.of.that,and.they'll.be.happy
to.implement.the.world.for.you...Perhaps.they.might.even.do.it
with.a.smile.

20-Apr-79 19:00:45-PST,453;000000000000 
Mail-from: MIT-ML rcvd at 14-Apr-79 1557-PST
Date:  14 April 1979 18:46 est
From:  Frankston.Frankston at MIT-Multics
Subject: MSGGROUP#1054  Re:.standard.message.systems
To:  Geoff at SRI-KA
cc:  Rick.Gumpertz at CMU-10a, MSGGROUP at MIT-ML
In-Reply-To:  Msg of 04/14/79 18:17 from 
In-reply-to:  the.tty.of.Geoffrey.S..Goodfellow

Would one want the world that BBN implements.  It probably won't work
Outside of Tenex (and maybe Twenex).

20-Apr-79 19:00:45-PST,600;000000000000    
Mail-from: MIT-ML rcvd at 14-Apr-79 1613-PST
Date: 14 Apr 1979 1556-PST
Sender: GEOFF at SRI-KA
Subject: MSGGROUP#1055  Re:  Re:.standard.message.systems
From: the tty of Geoffrey S. Goodfellow
To: Frankston.Frankston at MIT-MULTICS
Cc: Rick.Gumpertz at CMU-10A, MSGGROUP at MIT-ML
Message-ID: <[SRI-KA]14-Apr-79 15:56:28.GEOFF>
In-Reply-To: Your message of  14 April 1979 18:46 est
Reply-to: Geoff @ SRI-KA

Well, after all, they did for the most part implement the ARPANET
which is letting us send these notes back and forth, then of
course, that was done with much, much, FUNDING.

20-Apr-79 19:00:45-PST,1790;000000000000   
Mail-from: MIT-MC rcvd at 14-Apr-79 1949-PST
Date: 14 APR 1979 1937-PST
From: MACKENZIE at USC-ECL
Subject: MSGGROUP#1056  Text-ural tricks revisited
To:   grm at RAND-UNIX
cc:   msggroup at MIT-MC

    Gary,
 
    Sorry I've taken so long to reply. 
 
    I agree wholeheartedly that an expanded alphabet or punctuation
    system will never replace the well thought out, properly 
    organized and interestingly presented written communication of 
    which your message is such an excellent example. 
 
    I have a question though. Is an electronic message system's sole 
    purpose that of replacing the post office? Is it's sole benefit
    the speedy delivery of the same sort of written communication
    that we've been preparing for each other for thousands of years? 
    If it is, if all we are doing is sending each other quickly
    delivered business letters and journals, than my suggestion was
    ridiculous. I thought there could be more to it than that. One 
    of the largest benefits I see in electronic mail is that it
    enables us to communicate nearly as quickly as the telephone,
    more conveniently, and leaves a ..w.r.i.t.t.e.n.. record of the
    communication. I think you will agree that using EM in this sort 
    of conversational manner is only cumbersome when a poor typist 
    sits down at a keyboard. If we can create some method of aiding
    the poor written communicator, the poor typist, and even the 
    good typist who is time pressed in getting their meaning across
    quickly, easily and without spending an inordinate amount of 
    time in composition, we will find a much larger group of users 
    ready and willing to use this system.
 
    Did I miss the point again?
 
    Kevin
-------

20-Apr-79 19:00:45-PST,596;000000000000   
Mail-from: MIT-MC rcvd at 14-Apr-79 2020-PST
Date:  14 April 1979 23:14 est
From:  Frankston.Frankston at MIT-Multics
Subject: MSGGROUP#1057  Re: Text-ural tricks revisited
To:  MACKENZIE at USC-ECL
cc:  grm at Rand-UNIX, msggroup at MIT-MC
In-Reply-To:  Msg of 04/14/79 22:37 from MACKENZIE

What is so important about a written record.  One can keep a voice
record, possibly in digital form insted.  Thishas already been done in
IBM's Speech Filing System -- a surprisingly good elctronic mail system
using digitalized voice.  It has a snumber of nice human interfacing
touches.

20-Apr-79 19:00:45-PST,1501;000000000000  
Mail-from: MIT-ML rcvd at 15-Apr-79 0645-PST
Date: 15 Apr 1979 0616-PST
Sender: SDSAN-DMS at SRI-KA
Subject: MSGGROUP#1058  HERMES, GOD OF POST
From: SDSAN-DMS@SRI-KA
To: MSGGROUP at MIT-ML
Cc: SDSAN-DMS
Message-ID: <[SRI-KA]15-Apr-79 06:16:42.SDSAN-DMS>

I have been watching the messages flow by for sometime and it
seems to me that if all the digs at HERMES were converted to
code, you folks might have already spent enough time to build
something you consider better.

HERMES does almost everything I want a mail system to do, and
does it better than any other system I have used.  There are
definitely some impacts on the system and there are some delays
at times, but I feel that anything that good is worth waiting on.

As for the comments on the templates, if HERMES could keep only
one feature, I would prefer that it be the templates.  I can
convert one message to numerous report formats with the
templates, with little work on my part.  I can also prepare a
template that will send repetitive messages without effort.

I feel that those that do not like HERMES should not use it and
should have no objection to those who have taken the time and
effort to evaluate and adopt it using it if they choose.

It is quite apparent from the comments that almost all those
people knocking HERMES have little or no knowledge of it.

Finally, you might keep in mind that the large majority of
terminals in use on ARPANET are non-display terminals.

Tom Bowerman

20-Apr-79 19:00:45-PST,671;000000000000   
Mail-from: MIT-ML rcvd at 15-Apr-79 1141-PST
Date: 15 April 1979 14:28-EST
From: "Marvin A. Sirbu, Jr." <SIRBU at MIT-MC>
Subject: MSGGROUP#1059  Message System Standards
To: lauren at UCLA-SECURITY, MSGGROUP at MIT-ML

The major objection to a standard mail/message system is that
message systems are still very much research objects.  That is,
I doubt whether we know enough about the man-machine interface
issues to design a "standard" message system any more than
we know how to design a "standard" editor.  I look forward
to continuing advances in our understanding of these issues,
and to their incorporation in ever improving mail/message
systems.

20-Apr-79 19:00:45-PST,334;000000000000
Mail-from: MIT-ML rcvd at 15-Apr-79 1342-PST
Date: 15 April 1979 16:01-EST
From: J. Noel Chiappa <JNC at MIT-AI>
Subject: MSGGROUP#1060  Hermes modifications
To: MSGGROUP at MIT-AI, sdsan-dms at SRI-KL

        If you would be so kind as to supply the source, I think
hackers could be found to work on it.  Deal?
			Noel


20-Apr-79 19:00:45-PST,573;000000000000 
Mail-from: MIT-ML rcvd at 15-Apr-79 1359-PST
Date: 15 Apr 1979 1336-PST
Sender: SDSAN-DMS at SRI-KA
Subject: MSGGROUP#1061  Re: Hermes modifications
From: SDSAN-DMS at SRI-KA
To: JNC at MIT-AI
Cc: MSGGROUP at MIT-AI, sdsan-dms
Message-ID: <[SRI-KA]15-Apr-79 13:36:16.SDSAN-DMS>
In-Reply-To: Your message of 15 APR 1979 1601-EST

The hundreds and hundreds of satisfied HERMES users do not want
hackers working on HERMES.  They are basically satisfied with it.
It is the non-users wanting to hack it up.  I, for one, am glad
the source is protected.

Tom


20-Apr-79 19:00:45-PST,1103;000000000000
Mail-from: MIT-ML rcvd at 15-Apr-79 1428-PST
Date: 15 Apr 1979 1414-PST
Sender: GEOFF at SRI-KA
Subject: MSGGROUP#1062  Re: Hermes modifications
From: the tty of Geoffrey S. Goodfellow
To: SDSAN-DMS
Cc: msggroup at ML
Message-ID: <[SRI-KA]15-Apr-79 14:14:24.GEOFF>
In-Reply-To: <[SRI-KA]15-Apr-79 13:36:16.SDSAN-DMS>
Reference: I, for one, amd glad the source is protected.
Reply-to: Geoff @ SRI-KA

That's the wrong attitude to take, Tom.  Boo and hiss to you.
What makes YOU think that "HERMES users don't want HACKERS
working on HERMES"?  If it weren't for hackes working on things,
something as wonderful as EMACS (which I know you use and are an
avid fan of) wouldn't be where it is today with its feature rich
command set and superior functionality to any other system editor
available anywhere.

Instead, you put your faith in the almighty dollar, and you must
get FUNDING to make HERMES work.  Just wait'll next time you ask
for a HERMES feature and you get back "we are not funded to do
that in our current contract", we'll see about putting it in our
1984 proposal.

20-Apr-79 19:00:46-PST,977;000000000000  
Mail-from: MIT-ML rcvd at 15-Apr-79 1447-PST
Date: 15 Apr 1979 1410-PST
From: Stuart McLure Cracraft <McLure at SRI-KL>
Subject: MSGGROUP#1063  Hacking HEERMES
To: SDSAN-DMS at SRI-KA, JNC at MIT-AI
Cc: MSGGROUP at MIT-AI
In-reply-to: Your message of 15-Apr-79 1336-PST

What you fail to realize is that since we all use timesharing systems,
the efficiency or non-efficiency of programs like HERMES can have a
direct impact on people who do not use it. I have the right to object
to any major subsystem which consumes so much memory and is so slow.
I thought our KL, with 1 million words, and the latest upgrades to the
KL-10 processor was fast; but HERMES, in all grandeur, is still just
as slow and crunchly as ever. What I find amusing is that HERMES has to
maintain a preparsed file (user option) of the message file since if
it had to reparse the message file each time it was started, it would
take too long. Now that is really featureful.
-------


20-Apr-79 19:00:46-PST,1020;000000000000   
Mail-from: MIT-ML rcvd at 15-Apr-79 1505-PST
Date: 15 Apr 1979 1431-PST
Sender: SDSAN-DMS at SRI-KA
Subject: MSGGROUP#1064  Re: Hermes modifications
From: SDSAN-DMS at SRI-KA
To: GEOFF
Cc: SDSAN-DMS, msggroup at ML
Message-ID: <[SRI-KA]15-Apr-79 14:31:00.SDSAN-DMS>
In-Reply-To: <[SRI-KA]15-Apr-79 14:14:24.GEOFF>

Geoff, I agree with what you say, except that I feel HERMES
already does what it is designed to do and does it very well.I
really am a fan of EMACS and I also like vmail on MIT-MC.  I
guess my objection to hacking on HERMES is that I feel it is too
integrated and subject to winding up with loose ends.  The
documentation in Describe, Explain, Document, Outline, etc, would
never be current and/or accurate.  I agree that folks like you
hacking is what got us where we are, but there are some systems
where it might not be so successful.  Maybe I am also predjudiced
by the fact that I have asked for about fifteen changes so far
and got 14 of them within a reasonable time.

Tom

20-Apr-79 19:00:46-PST,942;000000000000  
Mail-from: MIT-ML rcvd at 15-Apr-79 1520-PST
Date: 15 Apr 1979 1429-PST (Sunday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: MSGGROUP#1065  M.S.S.
To: SIRBU at MC,MSGGROUP at ML

I agree fully that we are very much in the research mode when it
comes to message systems.  However, I still tend to feel that
there would be considerable utility to agreeing on the functions
of at least a primitive mail reading/sending system -- along the
lines (sigh) of the NETED concept.  This would not prohibit
system builders from creating as many and varied message
systems as their hearts and/or funding desired.  It would simply
mean that some sort of standard existed for the bottom line
system -- something that a guest or relative novice on a system
could use to send or receive mail.  I do think this would be
of more utility to the bulk of users than the standard editor
turned out to be.

--Lauren--
-------


20-Apr-79 19:00:46-PST,859;000000000000
Mail-from: MIT-ML rcvd at 15-Apr-79 1545-PST
Date: 15 April 1979  15:12-PST (Sunday)
From: WANCHO at SRI-KA
To: MsgGroup@MIT-ML
Cc: Wancho@SRI-KA
Subject: MSGGROUP#1066  Hermes Mods

It seems to me (from Tom's last statement of success with getting
change requests for HERMES actually installed) that BBN listens to its
paying customers (and rightly so).  Thus, all the wind in these
messages should be boiled down to specific requests for changes to be
made by a paying customer and be done with it.  I know Charlotte is on
this list.  Whether she actually reads these is neither here nor
there.  Requests for changes properly come from customers, not from a
discussion group.

Incidentally, from the rare BCPL error messages I get in HERMES, I am
led to believe that is the language in which it (or part(s) of it) are
written.

Frank

20-Apr-79 19:00:46-PST,3002;000000000000 
Mail-from: MIT-ML rcvd at 15-Apr-79 1941-PST
Date: 15 APR 1979 2220-EST
From: JNC at MIT-AI (J. Noel Chiappa)
Subject: MSGGROUP#1067  Programs and money.
To: wancho at SRI-KA
CC: msggroup at MIT-ML

        There are several problems with that statement.  First,
legalisticly, it's not clear what the law with respect to the HERMES
source is.  While I'm not a lawyer, as far as I know if it was
developed with ARPA money, then it's the property of the US government
and BBN cannot keep it a secret, unless they had some special contract
saying that they were only supposed to supply binary and could keep the
source.  If the government wanted to keep it from being released, that
would I guess provide an interesting court case.
        The second and related problem (if it was developed with ARPA
money again) is that in a sense we are all paying customers.  No real
effort is made to evenly allot the costs of running the ARPAnet and the
associated systems.  (I know everybody sort of pays for the IMP/TIP,
etc., but you know what I mean.)  I havn't seen RMS saying that he wont
fix any EMACS bugs unless the person bitching pays the AI lab for it...
        My third point is related to a general philosophical feeling
about how the world should work, and I tend not to aggree with the
class of people who won't do something themselves (for what ever
reason) and won't let ME do it.  My collection of entities in this pet
peeve includes such people as trade unions in some states (there are
states where it is ILLEGAL to work on your house wiring, even if you
have a BSEE, unless you are a member of the Electricians Union) and
software companies who are overly paranoid about sources.  I don't
think that BBN's reluctance in this case is fear of getting ripped off
- HERMES was presumably developed under contract and they must have
charged someone for it, so they won't lose money if they never see
another cent from HERMES.  I don't use HERMES, so I have no complaints,
but if I did and I had to pay BBN to fix lossages/problems I would be
extremely annoyed.
        I think it is downright rude and discourteous of anyone to act
in such a fashion.  (I know that such castigations have little effect
in this enlightened age, but.....)  If BBN is a nonprofit organization,
that's OK with me (although I don't like large non profit
orginizations).  If they won't work on HERMES unless I pay them, that's
cool.  But stopping ME from working on it is uncouth.
        Does anybody out there know if the US govt (i.e.  you and me)
paid for HERMES?  If so how is BBN (a private corp) allowed to get away
with making money off people (that's what they want before they will
work on it) by using an advantage (they have the source) that was paid
for with OUR money?
		Noel

PS For those who remember Geoff's message speculating on the whereabouts
of the source, you may be amused to know that I saw that message
(reprinted) on BBN bulletin boards!


20-Apr-79 19:00:46-PST,1216;000000000000  
Mail-from: MIT-ML rcvd at 15-Apr-79 2046-PST
Date: 15 Apr 1979 2027-PST
Sender: GEOFF at SRI-KA
Subject: MSGGROUP#1068  Re: Programs and money.
From: the tty of Geoffrey S. Goodfellow
To: JNC at MIT-AI
Cc: wancho, msggroup at MIT-ML
Message-ID: <[SRI-KA]15-Apr-79 20:27:22.GEOFF>
In-Reply-To: Your message of 15 APR 1979 2220-EST
Reply-to: Geoff @ SRI-KA

No one knows anything real about the diggs on who has what on
HERMES and who it belongs to, etc.  except what has flowed thru
the MSGGROUP in previous msgs from tid-bits picked up here and
there.  Many have repeatetly ask of powers that be in the ARPA
office and of BBN who are on this mailing list, and do have the
authority of "say so" just what is policy on HERMES vis-a-vis all
of this flak, but both ARPA and BBN have been mighty tight
lipped.  Oh and by the way, BBN is a FOR profit orginization,
however, they seem to have a lot of govy contacts that might make
you think otherwise, unlike SRI which is a non profit orig and
doesn't put their faith or hide behind the almighty dollar like
BBN seems to.

What a shame it is that BBN was just given something as wonderful
as EMACS for "free"; they should have paid MIT for it.

20-Apr-79 19:00:46-PST,2179;000000000000    
Mail-from: MIT-ML rcvd at 15-Apr-79 2323-PST
Date: 15 Apr 1979 2309-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP#1069  USERS are not CUSTOMERS
From: STEFFERUD at USC-ISI
To: MSGGROUP at MIT-ML
Message-ID: <[USC-ISI]15-Apr-79 23:09:57.STEFFERUD>

A USER is not a CUSTOMER.

  .  A CUSTOMER makes value judgements, and has real money tradeoffs
     to make among alternative purchases.

  .  A USER does not make such tradeoffs because he has no real
     dollars to commit among alternative spending choices.  Thus a
     USER need not make value judgements, and is privileged to behave
     like an infinite sink for resources.

BBN knows the difference when they listen to suggestions, requests, and
complaints.  I know this from long and arduous experience.  Frustrating
too, because I am a HERMES USER, not a HERMES CUSTOMER.

But BBN is right in favoring their CUSTOMERS over their USERS, just as
any of you are right when you give higher priority to direct funding
source requests than to other requests.  If you don't believe me, then
ask your favorite Lab Director.

For those who subsrcibe to my thesis, I include the following plaque,
suitable for framing and hanging on your office wall:




             If you like it and you want it,

                Then you buy it!

             If you cannot afford it,

                Then you learn not to want it!

             If you will not learn not to want it,

                Then someone will decide for you!



My earliest writing on this subject is published in COLLEGE AND
UNIVERSITY BUSINESS, October 1970.  Another article appeared in
DATAMATION, March 1971, and the topic has been visible in many of my
published papers since then because it is a central issue in any
resource sharing network.  My primary work domain is in the area of
shared resource management policies and organization structures for
shared resource facility management.

I will be pleased to mail reprints to those who send me a properly
formatted US Postal Address that I can cut out and paste on an envlope.
I will not retype my whole spiel into a message.

Best - Stef

20-Apr-79 19:00:46-PST,2044;000000000000    
Mail-from: MIT-ML rcvd at 16-Apr-79 0008-PST
Date: 15 Apr 1979 2356-PST
Sender: GEOFF at SRI-KA
Subject: MSGGROUP#1070  Re: Hermes modifications
From: the tty of Geoffrey S. Goodfellow
To: SDSAN-DMS
Cc: msggroup at ML
Message-ID: <[SRI-KA]15-Apr-79 23:56:24.GEOFF>
In-Reply-To: <[SRI-KA]15-Apr-79 14:31:00.SDSAN-DMS>
Reply-to: Geoff @ SRI-KA

Tom, I'm pretty sure that HERMES does what it was designed to do
as well, since if it didn't that would be breach of contract, eh?
However, weither HERMES does it in the most efficient and cost
effective manner remains to be seen.  In my opinion as a TENEX
hacker, HERMES is much to large for what it does.  Something
(again, in my opinion) coded thoughtfully, efficiently and with
cost effectiveness in mind in machine language or perhaps even a
decent high level language (which i don't consider BCPL to be)
would be half to a third the size of HERMES at least.  Take for
example TOPS-20 MM, which basicly has all the same functionality
of HERMES minus the TEMPLATES (which, incidentally is one of my
favorite HERMES features too) is only 34 disk and core pages
compared to HERMES which currently weighs in at 290 disk
pages(!), and when started grows to aprox.  400 pages of core!!!!
Its no wonder that SRI-KA needed to have 256K added to our
already existing 256K, or you would be in sad shape here with
your daily HERMESSing.

As for your point with documentation, perhaps, however, there are
some very good systems around the network maintained by hackers
which have very good up to date documentation, take SAIL's E for
example.  I do tho find HERMES's documentation a bit VERBOSE at
times.  It is sort of like asking for the time of day and
getting the history of watch making....

Lastly, i take the most offense to your "I agree that folks like
you hacking is what got us where we are, but there are some
systems where it might no be so successful".  I'd almost be
willing to bet you my Jensen Interceptor that you can't site one
example.

geoff

20-Apr-79 19:00:46-PST,2598;000000000000
Mail-from: MIT-ML rcvd at 16-Apr-79 0028-PST
Date: 16 April 1979 03:16-EST
From: Richard M. Stallman <RMS at MIT-AI>
Subject: MSGGROUP#1071  Standard Free-market Dogma
To: MSGGROUP at MIT-AI

We have just seen another copy of the mass-produced Appeal to the Free
Market.  This argument, which says that if a person can't afford
something then he doesn't deserve to have it, is really no argument at
all.  It is just one way of defining what is "fair", and nothing
compels one to agree with it.  It is usually found as the flip side of
the statement that the free market is good because it always leads to
the fairest result.

In this particular case, however, it isn't conclusive even if you
believe it.  For example, why does the dogma of the free market require
that a user who is not a customer not be able to make changes himself?
Does HERMES belong to BBN or to the US govt, and what officially
constitutes a request to get HERMES for "a purpose of the US govt" of
the relevant sort?  It's not clear what side the law is on, nor what
side a laissez-faire believer ought to be on.  An actual person need
not agree with either of those, however.  It's possible to consider
someone a bad neighbor even if he doesn't break any laws.

The standard free-market dogma works out to be effectively equivalent
to "might makes right, as long as it's laundered".  I mean
"effectively" in that the former can be used to argue for anything that
is a case of the latter.  If someone can afford to buy all the land
surrounding your house and then say you are trespassing if you enter
his land, according to this principle he is within his rights, you have
no right to go from your house to any distant place, and deserve to
starve to death.  The reply would usually be that it would not be in
his interest to do such a thing, but that is no help if he is just
slightly irrational enough to do it anyway.  Or do proponents of the
free-market dogma actually qualify it to apply only when all parties
are acting in their rational self-interest (as defined by whom?)?

In fact, our legal system probably does give you some recourse in that
situation.  Which just shows that the law doesn't completely believe in
the free-market dogma to the exclusion of all other ethical principles.
Not that one must necessarily agree with the law, but this does show
that a lot of people disagree with the dogma.

The free-market dogma is an example of the sort of ethical
oversimplification that we would be better off without.

Ps.  What about paying off judges and jurors?


20-Apr-79 19:00:47-PST,697;000000000000  
Mail-from: MIT-ML rcvd at 16-Apr-79 0245-PST
Date: 16 Apr 1979 0237-PST
Sender: SDSAN-DMS at SRI-KA
Subject: MSGGROUP#1072  Re: Hermes modifications
From: SDSAN-DMS at SRI-KA
To: GEOFF
Cc: SDSAN-DMS, msggroup at ML
Message-ID: <[SRI-KA]16-Apr-79 02:37:44.SDSAN-DMS>
In-Reply-To: <[SRI-KA]15-Apr-79 23:56:24.GEOFF>

Geoff, if I had any examples I would have fired them off in the
first round.  I was speculating that HERMES might be such an
animal.

On the other hand, if you try to move MFEXEC to another host, you
can.  But when you initiate it, you are lectured for stealing it
and logged out.  This indicates that even KA has certain systems
they do not want hacked.

Tom

20-Apr-79 19:00:47-PST,1211;000000000000  
Mail-from: MIT-ML rcvd at 16-Apr-79 0830-PST
Date: 16 Apr 1979 0813-PST
Sender: GEOFF at SRI-KA
Subject: MSGGROUP#1073  Re: Hermes modifications
From: the tty of Geoffrey S. Goodfellow
To: SDSAN-DMS
Cc: msggroup at ML
Message-ID: <[SRI-KA]16-Apr-79 08:13:31.GEOFF>
In-Reply-To: <[SRI-KA]16-Apr-79 02:37:44.SDSAN-DMS>
Reply-to: Geoff @ SRI-KA

Well, Tom, I guess you don't get the Jensen then.  Sorry.

Re: your comment about MFEXEC.  I did not have a thing to do with
that feature.  One of the authors (who was at the Univ.  of Utah)
put that in for some reason or another.  It can easyly be taken
out with a patch, and in fact, if you'd like to run MFEXEC on
another host, I'll be happy to do that for you if you're not
familer with DDT.  N.B.  there are only a handful of hosts that
can actually run MFEXEC,since it uses some special SRI only
system JSYS's and hence won't run on other systems.  Also, the
development of MFEXEC was a completely unfunded one, and it is
availble to anyon who wants it.  Our version as a matter of fact
hasn't been reassembled since '75, and i believe that the
maintainers (now at ISI) have taken the logout hack out.

Hope this clears that one up.

20-Apr-79 19:00:47-PST,1234;000000000000    
Mail-from: MIT-ML rcvd at 16-Apr-79 1158-PST
Date: 16 APR 1979 1129-PST
Sender: AHENDERSON at PARC-MAXC2
Subject: MSGGROUP#1074  Re: System primitives and glue
From: AHENDERSON at PARC-MAXC2
To: BR10 at CMU-10A
Cc: MSGGROUP at MIT-ML
Message-ID: <[PARC-MAXC2]16-APR-79 11:29:39.AHENDERSON>
In-Reply-To: <14Apr79 101534 BR10@CMU-10A>

My intent was badly phrased in the one aspect of neglecting the
idea that a user language would be most productive when added to
a system which is already integrated - and therefore sets a
direction.  Usually what I want is a small mod of something
alreazdy there.

Admittedly I could create terrible messes.  Let's take a chance.

In addition to direction, an existing system provides a way to
get started without building anything.  It's only when mods are
desired that the programming tools would be unsheathed.  One
might also discover at that point that many of the commands which
one had been using up to that point as though they were
"built-in" were in fact non-primtive constructions set up by the
system builders to aid in getting started.  (The Lincoln Reckoner
on TX-2 at Lincoln Labs - may it rest in peace - had just such an
appearance to users.)

Austin

20-Apr-79 19:00:47-PST,6545;000000000000   
Mail-from: MIT-ML rcvd at 16-Apr-79 1609-PST
Via: <Rand-Unix>
Date: 16 Apr 79 18:07-EST
From: Dcrocker at UDEE
Reply-to: Dcrocker at Rand-Unix
Subject: MSGGROUP#1075  Corrections of Fact and Fiction
To:  msgGroup@mit-ml

    [I am beginning to think that Delaware's ability to receive
Arpanet mail is a mixed blessing.  I walked in today at noon to
find that, since Friday, I had received about 55 messages, and
they were shipped here from Rand at 300 baud (effective data rate
of about 1200bytes/minute)...]  [By the time I read the messages
and wrote this one, I had another 15 message to read.]

    The following comments pertain to the discussion(s) about
tailoring of message systems, standardizing their behaviors and
on some comments made about Arpanet history.

    First, neted came FROM Multics and did NOT migrate TO it.
There was a group, called USING (Users interest network working
group) which is the closest functional predecessor to MsgGroup,
which sought to make life a little easier for users who bounced
between several different operating systems.  The goal was simply
(and only) to provide a minimum capability and the thing did just
that.  The particular editor was recommended by Mike Padlipsky
(then of MIT and now at Ford Aerospace) because its code just
happened to be the programming example in the Multics
Programmer's Manual and that made it VERY well documented.
Versions of it appeared on a remarkably large number of different
operating systems within a remarkably short period of time and it
was used, appreciatively, by a discernible, if small, population
for some time.  There probably is still a user group for it.

    Second, Rand's MS message system is documented as functional
primitives (well, higher than primitive, really) and is the
immediate predecessor to MH.  It is the ONLY system I know of
that has anything like a public specification of functionality
which is independent of user interaction style.  However, the
spec is not written in a formal specification language because I
didn't know about them (tho I remember trying to invent one, for
about 2 hours one afternoon).  The report containing the spec and
other discussions about MS (including a proposal for tailoring,
using the message model as a framework for presenting switches
and their settings to users, which is now implemented in MH) is
available from Rand as R-2134-ARPA (November, 1977).

    As to the performance of mail systems on Unix, the
competitors are 1) simply dumping the mailbox onto the terminal
(yes, there are still a few users who do that), 2) the
Berkeley/Rand/... msg, 3) ms, and 4) mh.  Of the latter three,
the Berkeley/Rand msg is easily the quickest, for processing a
batch of received mail in a moderately-sized folder.  However, it
doesn't have a reply command.

    I suspect that there are a fair number of us who have used a
fair number of message systems.  I have lived with 3 on tenex, 3
on unix, and the nls journal system (in a class by itself).
Making generalities based on that experience is extremely
unsatisfying.

    With respect to standardizing message systems, I claim that
essentially all of us have almost exactly the wrong set of
experiences and backgrounds to do the job properly.  Our tendency
is to judge a feature based on our personal preference for it.
This is appropriate, to the extent that we are representative of
the people who will end up living with the system, and is exactly
the wrong thing to do otherwise.  Most of us are a) experienced
programmers and b) working in a place which is filled with
experienced programmers.  Ergo, even the "non-technical" users
have access to a degree of local expertise which is completely
unrealistic for the rest of the world.

    In addition, most of us like our work and are interested in
it.  Most of the clerical workers at best tolerates their work
and are rarely "interested" in the job.  The environment is not
conducive to "thinking" and the workers are generally resigned to
(or prefer?) that state of affairs.

    Now I am not, personally, very happy with the existance of
this intellectual/professsional class distinction in the working
world, but its presence is very palpable, and any attempt to
design for workers in non-intellectual jobs needs to be aware it.
Two very direct implications are the KISS rule of simplicity and
the requirement that innovation within most organizations needs
to be kept at a minimum and phased-in very carefully.  (The
latter translates into the dictum that workplaces be kept
basically stable, the Hawthorne effect notwithstanding.)

    Tailoring.  The above paragraph contains the major argument
about (rather than against) tailoring.  The majority of workers
(I claim) will not appreciate being required to expend great
effort at changing a new product before they can use it.  My
premise, here, is that a) the product does not have a useable set
of defaults, b) any system with enough tailoring capabilities
will probably have too many tailoring capabilities, and c) new
users will not normally have a good descriptive model (available
for introspection as opposed to direct use) of the application
domain and therefore can't be expected to choose system behaviors
very well.

    Switches are a particularly deceptive idea for systems.  They
embody the philosophy that, in the absence of a clearly correct
choice, the designer should give the choice over to the user.  As
stated, the idea is reasonable.  As practised, it is quite
dangerous, because it can lead the designer to be unconcerned
about making the default be the most reasonable choice.  Much,
much more importantly, it deludes us into using a summative model
of human factors in user interface design.  This model says that
one merely needs to identify the individual factors affecting
human performance in the use of computer systems and then control
each factor to its optimal setting (for that user, user
population, or whatever).  The problem is that a) there are
likely to be several million factors, if that few, and b) the
factors interact in ways that we don't understand.

    Ergo, switches are a stop-gap measure to be used in the
presence of enormous ignorance and their presence can make life
better than their absence, but only if their cost is limited
(e.g., not increasing the cognitive complexity of the interface
to a point beyond the tolerance of the user).

Cheers.  Dave.

20-Apr-79 19:00:47-PST,1787;000000000000 
Mail-from: MIT-ML rcvd at 16-Apr-79 1836-PST
Date: 16 April 1979 21:06-EST
From: Richard M. Stallman <RMS at MIT-AI>
Subject: MSGGROUP#1076  Let's do what we're suited for
To: MSGGROUP at MIT-AI

     Ergo, even the "non-technical" users
   have access to a degree of local expertise which is completely
   unrealistic for the rest of the world.

This was stated to show how we must really think in an unnatural
fashion if we are to do what the rest of the world would want.  A
different conclusion which can be drawn from this is that the real
world standards do not apply to our sites, and for us to give our sites
something designed to real world goals and specifications would not be
the best thing for them.

There are plenty of people in Xerox working on making what's best for
the real world's lowest common denominator.  There is no danger that
the real world will not be catered to if we don't do it.  So we need
feel no guilt if we ignore it and do what is best for out own
communities, in which even non-technical users do not behave like real
world people.  As an analogy, must technical journals have nothing in
them to offer most of the audience of Newsweek.  Does this mean that
only Newsweek is worthy and that people who work on technical journals
are misdirecting their efforts?

One can go so far as to say that the efforts being made to adapt
systems to the lowest common denominator of human have as a necessary
counterpart the formation of nucleii for the spread of a higher level
of computer literacy.  If that's what we find ourselves tending to be,
why resist?  If a person finds himself inclined and suited to teach in
college, should he feel guilty for not teaching in elementary school?
College teachers are needed, too.


20-Apr-79 19:00:47-PST,1889;000000000000    
Mail-from: MIT-ML rcvd at 17-Apr-79 0017-PST
Date: 17 APR 1979 0001-PST
From: JMCHUGH at USC-ECL
Subject: MSGGROUP#1077  Re: Corrections of Fact and Fiction
To:   DCrocker at RAND-UNIX
cc:   MSGGROUP at MIT-ML

In response to your message sent Mon, 16 Apr 79 18:07-EST

Yes, we indeed may have the wrong set of experiences and backgrounds to
standardize message systems PROPERLY.  But it appears to me that we
still have a professional responsibility to translate our experience
and knowledge from the current environment into meaningful guidance to
the multitude who will be using electronic mail systems in the future.

If the future of EM systems goes the way of word processing, we will
have many many frustrated users whose expectations (built by the sales
folks) will never be met.  You are correct --- our environment with
knowledgeable people handy is a lot different than some poor soul
trying to implement a new system that was sold to the boss.

I was interested in a conversation with the manager of a new shared
logic word processing center installed about nine months ago.  Having
gained some experience with the complexity of the equipment and the
compromises involved with enhancements, they do NOT want to just
specify a couple of features for improvement; instead, they want an
expert who understands the tradeoffs between response time and
function, etc., to TELL THEM what the optimum solutions are for their
specific production environment.

Regardless of whether our objective is standards, evaluations, or just
discussion, maybe the best that we can do is to keep the naive user in
mind --- to keep looking into the future clerical environments where
these systems will be used.  Dave, it seems to me that you have
expressed this viewpoint in your detailed comments (and I did
appreciate your comments).

Best - Jim 
-------

20-Apr-79 19:00:47-PST,595;000000000001    
Mail-from: MIT-MC rcvd at 17-Apr-79 0340-PST 
Date: 17 APR 1979 0638-EST 
From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)  
Subject: MSGGROUP#1078  Cheap timesharing 
To: MSGGROUP at USC-ISI
Redistributed-To: msggroup at MIT-ML
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 17 Apr 1979

A few weeks ago someone mentioned that DBC was planning to offer a
cheap time sharing service:  $2.75/hour after 6:00 p.m.  Last week
Telenet filed for permission to offer a special "night rate".
$.75/hour and no packet charges, minimum of $10,000 per month.

20-Apr-79 19:00:47-PST,645;000000000000    
Mail-from: MIT-MC rcvd at 17-Apr-79 0423-PST
Date: 17 April 1979 06:54-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: MSGGROUP#1079  The Size of the Universe
To: MSGGROUP at MIT-MC
cc: POURNE at MIT-MC

I've often wondered how many total people are served by network mail.
I figure that the ITS sites provide network mail facilities to
aproximately 2500-3000 people total.  Of course, many of these have
accounts elsewhere as well.  I don't have any idea how many people
there are at all the rest of the sites.  Does anyone out there have any
idea of the size of this universe?  Like what percentage of the US
population...?

20-Apr-79 19:00:48-PST,538;000000000000 
Mail-from: MIT-MC rcvd at 17-Apr-79 0807-PST
Date: 17 April 1979 1054-EST (Tuesday)
From: Brian K. Reid <BR10 at CMU-10A>
Subject: MSGGROUP#1080  Re: The Size of the Universe
To:   Robert W. Kerns <RWK at MIT-MC>
CC:   MSGGROUP at MIT-MC
Message-ID: <17Apr79 105454 BR10@CMU-10A>
In-Reply-To: Robert W. Kerns's message of 17 Apr 79 06:54

Well, there are 781 users at CMUA, 403 at CMUB, and 417 at CMUD.
There are about 1000 message files on our three machines combined,
which would indicate about 1000 distinct mail users.

20-Apr-79 19:00:48-PST,265;000000000000    
Mail-from: MIT-ML rcvd at 17-Apr-79 1625-PST
Date: 17 APR 1979 1610-PST
From: POSTEL at USC-ISIB
Subject: MSGGROUP#1081  Shaw's Principle
To:   msggroup at MIT-ML


Build a system that even a fool can use,
and only a fool will want to use it.

-------

20-Apr-79 19:00:48-PST,363;000000000000 
Mail-from: MIT-ML rcvd at 17-Apr-79 1744-PST
Date: 17 April 1979 2033-EST (Tuesday)
From: Brian K. Reid <BR10 at CMU-10A>
Subject: MSGGROUP#1082  Systems even a fool can use
To:   POSTEL at USC-ISIB
CC:   msggroup at MIT-ML
Message-ID: <17Apr79 203327 BR10@CMU-10A>
In-Reply-To: POSTEL's message of 17 Apr 79 19:10

IBM has gotten very rich that way.

20-Apr-79 19:00:48-PST,391;000000000000   
Mail-from: MIT-ML rcvd at 17-Apr-79 1820-PST
Date: 17 Apr 1979 1810-PST
From: Meyers at SRI-KL (Harris A. Meyers)
Subject: MSGGROUP#1083  Re: Systems even a fool can use
To: BR10 at CMU-10A, POSTEL at USC-ISIB
Cc: msggroup at MIT-ML
In-reply-to: Your message of 17-Apr-79 1742-PST

I think IBM comes closer to:
only a wizard can use, only a fool would want to

harris
-------

20-Apr-79 19:00:48-PST,3973;000000000000
Mail-from: MIT-ML rcvd at 18-Apr-79 0852-PST
Date: 18 April 1979 11:15-EST
From: Charles Frankston <CBF at MIT-MC>
Subject: MSGGROUP#1084  Corrections of Fact and Fiction
To: MsgGroup at MIT-ML

I have been watching the recent discussion of various message systems
and message system goals with some amusement recently.  The amusement
stemmed mainly from watching all these Tenex/Twenex users shouting at
each other about their favorite mail systems.  I could put in my 2
cents about ITS's mail systems, but I don't think it would contribute
any more than people yelling what a good or lousy mail system Hermes
is.

Dave Crocker's message made some points, which I have not really
noticed a response to, and I think a couple of his points ask to be
disputed.

1) Dave implies that most of the user interfaces in existing network
mail systems are acceptable only because most of the users either
themselves have strong intellectual backgrounds or have such persons
readily avaiable to ask questions of.  (The word "intellectual" is his
choice, I believe generally most people in discussion thus far have
used terms like "hackers").

I don't think this imlication is exactly insulting the average, let's
say, secretarial worker, but it comes close to being so.  All that I
can say is that I believe it to be quite wrong.  I don't know what sort
of office worker's Dave Crocker has met in his lifetime, but I think
most of the ones I have ever known could learn to use effectively, most
any mail system I have seen yet.  In fact, many of them could do so
better than I, because if someone told me that to see the next message
I had the sum the message numbers of the previous message numbers and
divide by 2 (yes, I am being intentionally ludicrus) I would rebel (and
probably demand the source of the crock (hmm, Hermes?)).  However, most
secretaries I know would simply try their best to memorize the idiocy
without blinking an eye.  In fact, memorize ludicrous sequences of
instructions is something they are trained for.  This is not to say
that I feel all message systems should have ludicrous commands.  The
point here is that the programmer probably cares more for a consistent
clear command set than most users.

2) Dave Crocker also more than implies that any programmer who leaves
options ("switches") in a program designed for the commercial office
environment is shirking his duty of carefully thinking out all the
options and then fixing the "right" ones for all time in concrete.  I
think this probably stems logically from the notion I have already
attacked that most of these people have limited mental sets.  However,
I think the notions that the options should be removed is stupid.  The
point to consider is that many options are available to provide ways of
doing useful things that might not otherwise be possible.  If the
system is well designed and has proper documentation for novice use,
then the options need not have any bad effects such as confusing the
user or providing potentially dangerous commands.  However, through
options one can provide those features that can indeed save hours of
work to those who find they are capable of perhaps wading through the
second level user manual.  Again, I can attest to many cases of non-
programmers finding and availing themselves of supposedly advanced
features of systems.

By the way, as an obvious case in point, electronic mail has not quite
reached that many real world offices, but word processing has.  I
believe many of the word processing systems on the market are not as
well polished as most of the mail processing systems available on the
network (this is a very subjective and sweeping judgment of course,
but..).  In fact, for doing something like producing a large report,
many of them have instructions that are probably as difficult as
pieceing together your own mail reading system from a set of primitive
tools!


20-Apr-79 19:00:48-PST,4395;000000000000   
Mail-from: MIT-ML rcvd at 18-Apr-79 2156-PST
From: FFM@MIT-MC
Date: 04/19/79 00:11:31
Subject: MSGGROUP#1085  Re: Technological Literacy, Message Systems,
Subject:                     ourselves and clericals
To: msggroup at MIT-ML

WHY AREN'T PEOPLE TECHNOLOGICALLY LITERATE???


Probably because they have never been exposed to an enviorment in which
computers are fun or useful to them.  The professionals are the one
that in most places in the real world or unreal world as one sees it,
that get to use computers in ways that are useful or fun to them as
individuals.

In many cases they(clericals) are not even told that a computer can be
used for personally beneficial purposes like sending mail or else they
are made to believe that sending mail for personal reasons is a sin of
somesort Some are trapped on crummy and hard to use equipment or
software designed by people who think all software has to be hard to
use because that is the nature of computer work and that only things
that are hard to do are worthwhile and valuable.

Until people are encouraged to use computers for personal reasons and
they view computer usage in the same way that they view car usage then
real technological literacy won't arrive.  I found in my various forays
in teaching people like secretaries EMACS and other things that they
are just as willing to learn as anyone else and that if it is
approached in reasonable humane joyfull manner (excuse the spelling but
this is hard to edit in present situation).  This does not mean
throwing a dull boring manaul full of dull boring secretary exercises
at them or looking down upon them or such.  Some professional people as
they are called exude a "high-wizard" atitude and naturally frighten
away anyone who would dare ask them normal mortal questions.

Also people should be aware that most of us who use computers and llike
it have had very pleasent expierences on computers.  One has to
remember that others may have for whatever reasons the most frightful
fears of computers.  I knew of one secretary whose only thought of
computers came from the movie "Demon Seed" and she was bound to be
paranoid.  After some assurences that my any possible desires for her
were most likely to be held by me and not the PDP10 she became much
more relaxed.

One must also remember that most clerical workers are women and have
been taught they shouldn't be too bright or aggressive or know a lots
about computers cause computers are 'definitly a masculine thing'.
This in addition is why suggestions that clerical workers (and it
applies to clerical workers of either sex) are happy being dumb (i am
exaggerating and charicturizing here) are so obnoxious; however in the
case of female clerical workers such a suggestion is extremly
obnoxious.

It would be nice if people would start relating to people as people and
getting to know the people they work with.  If one knew these people
one would realize they are not dumb, not happy being dumb or anything
of the like.  If the workplace were place where people share skills for
mutualistic benefit (this concept is meant to be as broadly construed
as possible) then one would see the productivity of many people
'magically increase'.  It is depressing to see that as much as people
know about technical hacking around that they have often have very few
skills for dealing with people in a reasonable humane way.

We who have access to technology should try as far and as much as
possible to see that it is beneficially spread about the world and used
for as humane things as possible.  Much of this may seem like
pipedreaming it really isn't and if properly done we could have a much
better workplace with happier and more productive people.

I don't think we are in a place because of our 'superior' skills and
backround to force any message system on anyone, however we are in a
position to demonstrate the winning and losing features of the systems
we use and thus aid people in determining with our aid what would be
the characteristics of a really good message system might be.  It
hasn't been developed yet.  We should stop thinking like Ayn Rand and
statrt thinking like people for once and not worry about cruft like
user customer/user etc if at all possible.

Well this is my soapbox statement ....

Have fun all, Sends Steve

20-Apr-79 19:00:48-PST,1198;000000000000
Date: 17 Apr 1979 0939-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: MSGGROUP#1086  The Size of the Universe
To:   msggrp at MIT-ML

There are somewhere in the vicinity of 3600 + - names in
the NIC Identfile.  A few of them do not have mailboxes.

Jake

P.S.  If you are not in the NIC Identfile and would like to be
and are a legitimate Arpanet user, send your full name including
middle initial, phone number, U.S. Mailing address (company
not home address), online mailbox, and host affiliation to
Feinler@SRI-KL with cc: to JOJO@SRI-KL and we will add you to
the data base.
-------
[For some reason related to COMSAT operations at MIT-ML this mesage was
not delivered in sequence to all members.  It was manually resent with
the following new envelope.]

Date: 20 APR 1979 0043-EST
From: MOON5 at MIT-ML (David A. Moon)
Subject: Manually forwarded mail
To: MSGGROUP at MIT-ML

COMSAT@MIT-ML 04/17/79 12:42:26 Re: Msg of 12:42:25
To: NET-ORIGIN at MIT-ML
CC: MAIL-MAINTAINERS at MIT-ML
WARNING - "MSGGRP" at MIT-ML is an unknown recipient, but
sending will be attempted to the file "USERS3;MSGGRP MAIL".
Your message follows, in case you goofed:
-------

20-Apr-79 19:00:49-PST,810;000000000000    
Date: 17 Apr 1979 1250-PST
Sender: DRCMS-IS at OFFICE-1
Subject: MSGGROUP#1087  Text Editing Capabilities
From: Nate Sternberg
To: msgroup at MIT-ML
Message-ID: <[OFFICE-1]17-Apr-79 12:50:20.DRCMS-IS>

I am involved with identifying features that can be included in a text
editor.  Anyone interested or have any suggestions?  If so let me know.
Nate


[This msg was misaddressed and manualy forwarded into
the proceedings with the following new envelope.]  
Date: 20 APR 1979 0043-EST
From: MOON5 at MIT-ML (David A. Moon)
Subject: Manually forwarded mail
To: MSGGROUP at MIT-ML

COMSAT@MIT-ML 04/17/79 15:58:43 Re: Msg of 15:58:35
To: NET-ORIGIN at MIT-ML
CC: MAIL-MAINTAINERS at MIT-ML
WARNING - "MSGROUP" at MIT-ML is an unknown recipient.
Your message is being returned:
-------

20-Apr-79 19:00:49-PST,5260;000000000000   
Date: 18 Apr 1979 1045-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: MSGGROUP#1088  More corrections to fact and fiction
To:   msggrp at MIT-ML

Having taken up the banner for network etiquette I will try to be as
restrained as possible at the many put-downs of secretaries and birds
of that feather in previous messages.  From experience with many user
groups using all sorts of office equipment of which a subset is
terminals and computer-related peripherals, I would say that the group
that has the most problems with this sort of thing are Managers and
what has come to be known as 'Knowledge Workers' - most secretaries and
administrative assistants manage very well (with the exception of
learning situations where they have been made to feel very stupid and
are afraid of 'breaking' something).  The knowledge workers (and for
that matter the secretaries also) are frequently not absorbed by the
mechanism whereby they get to a result they are after.  To put it in
other terms they are goal oriented and will use whatever tool happens
to be lying around to get them to their goal.  Ideas are just as good
(or bad) if captured with a pencil or captured with the jazziest
elctronic gadgets - it makes no nevermind to them.  I have often heard
(and feel that way myself sometimes) that the clicks and clacks and
feeps and switches involved with using electronic devices for writing
and editing interfer with the train of thought and are considered more
of a nuisance than a help.  (There are other trade-offs that make the
use of these devices palatable, of course).  The average Manager,
Knowledge Worker, or Secretary will say to themselves, 'Here is the job
I want to get done', 'Here is an electronic tool that can help me', 'If
I use the tool will it be faster, easier, cheaper, more interesting,
(or at least one of these considerations)'.  Ultimately it boils down
to 'Is it worth my time and/or my money or is it what I am saddled with
and better make the best of if I expect to achieve my goal'.

As some of you are aware I drive a 20 year old VW of which I happen to
be rather fond because it has ALWAYS gotten me where I am going (i.e.,
gotten the job done), it is cheap to run, and fun to drive.  I have a
friend (whom some of you may know) who has a beautiful, expensive,
elegantly engineered automobile called a Jensen.  It also gets the job
done in high style but requires considerable attention to upkeep, fine
tuning, and the like but gives high performance in return.  I have a
third friend who has bought an elegant old car which he is
refurbishing.  He spends many hours shining the chrome, adding just the
right classic touches, overhauling the motor which is often out of the
car and laid out on the grass, and which someday (he says) will really
be perfect in every way.

In my opinion (Note well those words, folks) most mail system users are
analogous to a VW driver.  They are pleased with a system that gets
them there reliably, at a reasonable speed, at a reasonable cost and
without too much hassle.  They dream of using a very elegant system but
are more concerned with getting to the corner to get groceries than
with the vehicle that gets them there.  A few users need to go long
distances or get there very fast or need to put their vehicle through
grueling paces or are in a position to have the most elegant system and
they are analogous to the Jensen drivers.  Still other users (and here
one might add an aside of 'Programmers, know thyself') never really
want to get the job done or have a machine that runs reliably as they
are get pleasure out of the doing of the job, not the doneness of it.
They wish to explore many possibilities of how the parts fit together
and how to hone down and polish up and are not concerned with the
reality of the end result but rather with the promise of greater
performance or more elegance.

With computer mail systems as with automobiles there will be all of
these categories of users, but with computer mail users as with
automobiles the majority will be 'VW drivers', a few will be 'Jensen
drivers', and some will not drive much but will be putting together a
system or the ideas for one 'in the garage' (i.e., in the laboratory)
which will lead to the next iteration where the VWs may drive like
Jensens and the Jensens may orbit - who knows!

Designers must needs use the systems they design to test their designs
and in so doing often become super users, but they are a different
breed of cat from users who only wish to use the system and are not
deeply concerned with the mechanism of how it runs.  It is important to
keep these distinctions in mind.

Thank you, amen, and I'll take vanilla please!

Jake
-------

[Originally misaddressed and manully forwarded to msggroup]

Date: 20 APR 1979 0042-EST
From: MOON5 at MIT-ML (David A. Moon)
Subject: Manually forwarded mail
To: MSGGROUP at MIT-ML

COMSAT@MIT-ML 04/18/79 13:47:57 Re: Msg of 13:47:51
To: NET-ORIGIN at MIT-ML
CC: MAIL-MAINTAINERS at MIT-ML
WARNING - "MSGGRP" at MIT-ML is an unknown recipient, but
sending will be attempted to the file "USERS3;MSGGRP MAIL".
Your message follows, in case you goofed:
-------
20-Apr-79 19:00:49-PST,1946;000000000000  
Mail-from: MIT-ML rcvd at 18-Apr-79 2358-PST
Date: 18 APR 1979 2341-PST
From: JMCHUGH at USC-ECL
Subject: MSGGROUP#1089  Re: Corrections of Fact and Fiction
To:   Charles Frankston <CBF at MIT-ML
cc:   JMCHUGH, MsgGroup at MIT-ML

In response to your message sent 18 April 1979 11:15-EST


      "I don't know what sort of office worker's Dave Crocker has
       met in his lifetime, but I think most of the ones I have ever
       known could learn to use effectively, most any mail system I
       have seen yet.  In fact, many of them could do so better than
       I, . . .  In fact, memorize ludicrous sequences of
       instructions is something they are trained for. . . .  The
       point here is that the programmer probably cares more for a
       consistent clear command set than most users."


With our present interview and testing tools, it has proven very
difficult to predict whether an applicant without word processing
experience will be successful in the operation of word processing
equipment, i.e., whether the applicant has the ability to visualize
files she can't see or whether she can translate between one visual
display on the CRT and another on the printer, etc.  This appears to
relate to an innate ability rather than their desire to do a good job
or other abilities which would make a secretary successful.  (too bad
we can't just hire from the group that you have known?)

Though not formally trained in human factors analysis, many seasoned
programmers seem to realize the value of consistency and clarity in
commands (and how they help any user --- even the "intellectual" ---
to use the system easily and with a minimum of error).

Users may be able to quickly tell you that a system is awkward to use,
but my observation is that they generally lack the perspective to tell
you why it is awkward, e.g., lack of consistency in the command set.

Best -   Jim
-------

20-Apr-79 19:00:49-PST,1771;000000000000  
Mail-from: MIT-ML rcvd at 19-Apr-79 0026-PST
Date: 19 Apr 79 00:08-PST
Subject: MSGGROUP#1090  Re: Technological Literacy, Message Systems,
Subject:                     ourselves and clericals
From: Greep at Rand-Unix
To: MsgGroup at Mit-Ml
Message-ID: <Greep.79.108.000804 @ Rand-Unix>

I have had the experience (as have  probably  the  rest  of  this
group)  of  teaching  secretaries  to  use  text editors, message
systems, etc., and have gotten positive reactions from  some  and
negative from others.  I think FFM comes close to pinpointing one
major factor with  his  description  of  computers  as  having  a
"masculine"  image,  although  I would not put it quite that way.
Rather, I would say  that  people  consider  computers  to  be  a
"scientific  gadget"  sort of thing that they are not expected to
understand, and that it is largely this attitude, rather than the
actual complexity of something like a mail system or text editor,
that inhibits learning.  (Obviously I  am  not  talking  about  a
"hacker's  system" like DDT or TECO.) For example, I believe that
the difficulties in learning to  use  a  reasonable  text  editor
(such as NED) for a person already familiar with a typewriter (as
secretaries should be) are considerably less than those  involved
in  learning  to drive a car.  Yet virtually everybody drives (at
least in California), and a person would be ashamed to admit that
learning  to  drive  was  too difficult.  My point is that people
think they are expected to be capable of learning  to  drive,  so
they  don't  give  it  a second though, whereas they do not think
they are expected to learn computers, so they imagine  it  to  be
more difficult than it really is.

Pardon the lengthy message.

20-Apr-79 19:00:49-PST,2575;000000000000   
Mail-from: MIT-MC rcvd at 19-Apr-79 0556-PST
Date: 19 APR 1979 0840-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: MSGGROUP#1091  Systems even a fool can use
To: MSGGROUP at MIT-MC
CC: POURNE at MIT-MC

Actually, IBM systems ONLY a fool can use.  The rest of us get
frustrated and quit.  If it came down to using IBM stuff, I think I'd
stop hacking computers.  Seriously.

FFM's message brings up points I've long believed in very strongly.
To me, the value of the computer lies in how it augments the
capabilities of the individual, whether in performance of a task,
communication with another individual or group of them, or in the
creation of something new.  Thus, it's interactiveness and
responsiveness to my wishes that I find valuable and are my main
criterion for quality in systems.  And I think it's these same
qualities which make a system easy to present to others.  For
example, in EMACS, you type a character, you see it on your screen,
it's there in your buffer.  What could be easier to teach a
secretary?  What you experience should be as close as possible to
some model of what is going on.  And what is going on should be as
close as possible to what the user's model of what he wants
accomplished.  More complicated EMACS commands still produce
immediate and obvious results.  If you follow this philosophy, I
think you have a system that even a fool can use, but which a hacker
or intellectual or genius or just someone ordinary with lots of
practice from everyday use (we're still the primary place where you
find people with everyday experience with message systems!) can use
better than the fool or the novice.  (A fool is a novice who's too
timid to learn, and thus stays a novice.)

Another point has been touched upon:  people perform as they're
expected to perform.  This has been confirmed in studies of children
in gradeschool...if a teacher thinks a student is retarded, it's a
good bet the student soon will, and at that point, he might as well
be, since he's not going to trust anything he understands, and thus
can't expand on his knowledge.  So I think bringing our winning
features to the world will first require that we adjust our thinking
to where we approach people as individuals, think in their framework
enough to communicate with them, rather than talking in our own
gibberish to them.  I've found that when approached in this way,
people respond, even women with the "dumb blond complex".  First, you
have to SHOW them that they can do it!  Step by step, and then they
love it!

20-Apr-79 19:00:49-PST,6085;000000000000   
Mail-from: MIT-ML rcvd at 19-Apr-79 0723-PST
Date: 19 April 1979 0926-EST
From: David.Lamb at CMU-10A
Subject: MSGGROUP#1092  Re: Corrections of Fact and Fiction
Sender: RdMail at CMU-10A
To:   Charles Frankston <CBF at MIT-MC>
CC:   MsgGroup at MIT-ML
Message-ID: <19Apr79 092605 RD00@CMU-10A>
In-Reply-To: Charles Frankston's message of 18 Apr 79 11:15

In an earlier message, Dave Crocker said
     Switches are a particularly deceptive idea for systems.  They
     embody the philosophy that, in the absence of a clearly correct
     choice, the designer should give the choice over to the user.
     As stated, the idea is reasonable.  As practised, it is quite
     dangerous, because it can lead the designer to be unconcerned
     about making the default be the most reasonable choice.  Much,
     much more importantly, it deludes us into using a summative
     model of human factors in user interface design.  This model
     says that one merely needs to identify the individual factors
     affecting human performance in the use of computer systems and
     then control each factor to its optimal setting (for that user,
     user population, or whatever).  The problem is that a) there are
     likely to be several million factors, if that few, and b) the
     factors interact in ways that we don't understand.

     Ergo, switches are a stop-gap measure to be used in the presence
     of enormous ignorance and their presence can make life better
     than their absence, but only if their cost is limited (e.g., not
     increasing the cognitive complexity of the interface to a point
     beyond the tolerance of the user).

to which Charles Frankston replied
     Dave Crocker also more than implies that any programmer who
     leaves options ("switches") in a program designed for the
     commercial office environment is shirking his duty of carefully
     thinking out all the options and then fixing the "right" ones
     for all time in concrete.  I think this probably stems logically
     from the notion I have already attacked that most of these
     people have limited mental sets.  However, I think the notions
     that the options should be removed is stupid.  The point to
     consider is that many options are available to provide ways of
     doing useful things that might not otherwise be possible.  If
     the system is well designed and has proper documentation for
     novice use, then the options need not have any bad effects such
     as confusing the user or providing potentially dangerous
     commands.  However, through options one can provide those
     features that can indeed save hours of work to those who find
     they are capable of perhaps wading through the second level user
     manual.

I interpreted Dave's remarks differently.  In most large systems
there are many different choices to be made in how small portions of
the system work.  When faced with the fact that different groups of
users will want those choices to be made in different ways, it is
fairly common to either provide a set of building blocks (tinker
toys?)  from which all of the possible ways of doing things can be
constructed, or to have options or switch settings on each facility
to make it behave in all of those ways.

Dave's first point was that this built-in flexibility often makes the
designer less careful about chosing appropriate defaults for those
facilities, believing that if anyone dislikes any particular facility
they can change their switch settings to make things behave however
they want, or recombine the building blocks however they want.
However, if the system design has neglected to provide a consistent
world view, it is difficult to learn and change.  Not impossible,
note, but difficult.  Secretaries at CMU learned to use PUB but hated
it; they became much happier when SCRIBE arrived.  Even though such a
system has all those switches it may be difficult to tailor, if the
designer didn't spend some time thinking about the ways people would
want to use and flex his system.

Dave's second point, about human factors, was that in
human-engineering a system it is important to start off from a global
view of how the total system should appear to a user, rather than
starting by designing the low-level facilities to be provided.

I am not arguing against flexibility, and I don't think Dave was
claiming that defaults should be cast in concrete.  I think we're
both claiming that the building-blocks or switches approach attacks
human engineering from the wrong point of view.

The argument is typified by the contrast between SCRIBE and PUB that
I mentioned above.  PUB provided a set of tools out of which you
could construct a document formatter; it spoke in terms of low-level
options like "indent this paragraph by so much" and "send this
character string to a file called CONTENTS".  SCRIBE speaks in terms
of the abstractions a user has built up, such as chapters,
quotations, and bibliographic references.  A lot of hackers hate
SCRIBE because they can't program it procedurally, and because there
are some things it just can't do.  On the other hand, one of the CMU
secretaries (who was interested in computers because her husband was
a student in the department, and who was Phi Beta Kappa in Latin and
therefore no dummy) told me that SCRIBE was the first computer system
she'd been exposed to that she felt confident she knew how to use.
For all of the text editors, data base managers, document formatters,
and other random computer systems she learned in the four years she
was here, she memorised magic command sequences people had shown her
without being able to build up a consistent, useable picture of what
was going on.  The picture secretaries build up of what SCRIBE is
doing bears only casual resemblance to what's going on in the bowels
of the current SCRIBE processor, but I don't see anything wrong with
that; the view they have is consistent and useable.

		David Alex Lamb

20-Apr-79 19:00:50-PST,555;000000000000    
Mail-from: MIT-ML rcvd at 19-Apr-79 1047-PST
From: Grm at Rand-Unix
Date: 19 Apr 1979 at 1034-PST
To: ffm at Mit-Mc
cc: msggroup at Mit-Ml
From-the-tty-of: Gary R. Martins
 .:.
Subject: MSGGROUP#1093  All Kinds of Literacy...
 .:.


	Well, literacy is jest one of them problems !

	Meanwhile, the world will be happy to learn that
we have fixed the RAND-UNIX mail system so that it can
now cope with illiterate headers like those that MIT
emits with contemptuous insistence.

	Fire away, ye illiterates --- we're ready!


				Gary

20-Apr-79 19:00:50-PST,2274;000000000000    
Mail-from: MIT-ML rcvd at 19-Apr-79 1321-PST
Date: 19 Apr 1979 1234-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: MSGGROUP#1094  Re: Corrections of Fact and Fiction
To:   JMCHUGH at USC-ECL, Charles Frankston <CBF at MIT-ML
cc:   MsgGroup at MIT-ML, FEINLER

In response to the message sent 18 APR 1979 2341-PST from 
JMCHUGH@USC-ECL

A command set may be consistent with respect to the programming but
totally nonsensical with respect to the job being peformed...this is
where programmers and users often diverge.  Also, often the programmer
is forced to use things that aren't conceptually clear because of
system constraints.  I remember a command (that has since been changed)
that is in an old version of AUGMENT (nee NLS) which was used to split
the screen.  The command was 'I[nsert] E[dge]' and was chosen because
there were few commands starting with 'E' and many starting with 'S',
consequently using a command with an 'E' was preferred by the
programmer but using a command that said 'Insert Edge' usually made
users say, 'What????'  as it doesn't make much sense.  Although error
messages are not commands they often totally blow the mind of a person
not familiar with the system that sees some idiotic string flash by and
tries to decide what should be done.

Also, programmers have their own way of saying things.  A command that
is perfectly clear to programmers or users that have been indoctrinated
is not necessarily clear to users who speak a different 'language'.  I
now know that most systems have at least two commands to get rid of
something and that there are two because one might goof up and really
not want to get rid of something, thus the second chance.  I found this
very annoying and confusing when I first started and still can't
remember sometimes whether I want to 'delete', 'expunge', 'exit and
delete', etc.  Same for things like 'Quit', 'Kill', 'Logout',
'Exit','pop',etc.  Reminds me of the time I was bringing some non-
scientific visitors through the hall and as we walked down a given
corridor I said, 'This is where we do research on Artificial
Intelligence.'  and the visitor said, 'Artificial Intelligence?  How
could that be?'  (Search me fella, I just work here!)

Jake
-------

20-Apr-79 19:00:50-PST,495;000000000000    
Date: 20 APR 1979 0103-EST
From: MOON5 at MIT-ML (David A. Moon)
Subject: MSGGROUP#1095  Mail troubles
To: MSGGROUP at MIT-ML

Due to various network and mailer problems, a large number of msggroup
messages directed to the following hosts were lost:
	UCLA-SECURITY
	UTEXAS
	SRI-KA
Anyone who cares can find the messages in the log file, "CBF;MSG LOG"
on MIT-ML.  Also, I deleted JWalker@NBS-10 and Dunlavey@NBS-10 from the
group mailing list, since they apparently no longer exist.
20-Apr-79 19:00:50-PST,4169;000000000000    
Mail-from: MIT-MC rcvd at 20-Apr-79 0545-PST
Date: 20 APR 1979 0737-EST
From: CBF at MIT-MC (Charles Frankston)
Subject: MSGGROUP#1096  Good programmers and bad programmers
To: MSGGROUP at MIT-MC

Jake,

I feel your examples of a programmers point of view differing from a
users point of view are merely examples of poor programming.  There are
certainly enough of those around.  If the command set is consistent
internally in a program but not from the point of view of the user,
then in my view that is not a consistent program.  You didn't state why
it was that the programmer thought that NLS already had too many
commands on the letter "E".  I am all too afraid to hear that it is
because the table search for the letter "E" was already long enough.
Even if it isn't lets presume that for the moment, because efficiency
issues are all too often the reasons for doing things in crockish or
confusing manners.  My only answer to that, is thank God I am
programming in the age where more and more I can increasing expend the
extra CPU cycles to do something right.

You also state that programmers have their own way of stating things.
Again, I would respond poor programming.  In writing a program to do
something that was formerly done by hand, I tend to view the programmer
as an efficiency expert.  Everyone knows that the first thing an
effeciency expert does when he is hired to improve something is to
first go the people that are currently doing the job and study very
carefully how they do it.  I think it is clear a programmer has the
same responsibility to carefully understand the problem domain he is
dealing with.  Often it is best to simply model the manual system that
existed.  Often because of the way in which programmers tend to learn
how to organize things and come up with algorithms they can have much
the same effect as an efficiency expert in improving something (perhaps
even if they don't computerize it!).  It is sad however that all too
often programmers take the most obvious routes to implement something,
running roughshod over tradition, human engineering, and usually
robustness and other considerations also.

However, as I said, bad programs are not hard to find.  Even good
programmers often find that some system they quickly put together for
some particular task has been stretched well beyond its intended
limits.  I think though, for perspective I should probably state that
it is my personal opinion that something on the order of 98% of the
people in the computer industry today are either partially, or usually
completely incompetent.  When you couple this statement with the fact
that there is a shortage of trained personal in the industry today, you
indeed have a sitution which is not condusive to turning out quality
software.  Lest I too much more elitist than I am, there are probably a
decent number of intelligent people out there programming who could be
competent.  However, they have either not been well trained before
being released to write production code (how many people know someone
who felt they could write any program in the world after taking a 1
semester programming course?), or they are working on systems so
inadequete that producing quality software is a task beyond the scope
of mere mortals.  You can perhaps substitute "professional" for
competent.

Lastly Jake, a reliable 20 year old VW is fine for basic
transportation, and a Jensen may be difficult to maintain, but some of
us like our cake and eat it too.  I just went shopping for my first new
automobile.  My criterea included a whole host of items including
performance and comfort that I don't think your 20 year old bug gives,
and a service record that I don't think your friend's Jensen has within
a budget that probably couldn't afford the Jensen anyway.  I believe I
was succesful.  Considering myself a "computer professional" I believe
it is my duty to apply the same sound engineering principles that the
manufacturer of my automobile used to computer systems I design.  I
find most good engineering principles are a direct result of using
common sense.

20-Apr-79 19:00:50-PST,1924;000000000000    
Mail-from: MIT-ML rcvd at 20-Apr-79 0821-PST
Date: 20 APR 1979 0647-PST
From: JMCHUGH at USC-ECL
Subject: MSGGROUP#1097  Re: Text-ural Tricks
To:   Grm at RAND-UNIX
cc:   JMCHUGH, MsgGroup at MIT-ML

In response to your message sent 12 Apr 1979 at 1850-PST

Gary, have you seen "The Editor's Page" in the April 23, 1979, issue
of U.S. NEWS & WORLD REPORT?  The following is extracted:

DUE DISMAY ABOUT OUR LANGUAGE
By Marvin Stone

  We'd like to say a word for the campaign being waged by Bill
Gold, a <Washington Post> columnist, to help save the English
language.
  We are cheering Bill on because we see an explosive increase in
the number of writers and speakers who can't be bothered about
meanings of words, singulars and plurals of nouns, tenses and moods of
verbs, the right places to put punctuation, or ways to arrange
sentences to show what goes with what.
  Largely, we are paying a penalty for what we have allowed to
happen in our schools since World War II.  By the early 1960s, it was
found that a third of the English teachers in secondary schools were
unfit to teach their subject. . . .
  Sloppy writers regard all this as a narrow concern of scholars,
whereas, as a matter of fact, regard for good English is central to
accurate communication.
  . . .
  Worst of all, in our estimation, is the kind of writing that
results from confused thinking and thus promotes further such
thinking.  We spotted this example on the editorial page of an
influential newspaper:
  "There is no cause for undue dismay."
  We suspect that the author is trying to fool us into false
security.  If dismay is undue, there's no cause for it, but what about
the dismay that may be due?
  With the help of today's teachers and their dictionaries, we may
advance into the twilight of the English tongue, voicing our grief in
grunts.  But there is no cause for undue dismay.
-------

20-Apr-79 19:00:50-PST,983;000000000000 
Mail-from: MIT-ML rcvd at 20-Apr-79 1501-PST
From: Grm at Rand-Unix
Date: 20 Apr 1979 at 1445-PST
To: stefferud at Isi
cc: msggroup at Mit-Ml
From-the-tty-of: Gary R. Martins
 .:.
Subject: MSGGROUP#1098  Hdr Crud
 .:.

Stef -

	I am still your friend, Stef !  My accouncement
that Rand-Unix has modified its mail system to cope with
the garbage headers that come from ITS machines was NOT
intended to encourage more bad breath from those lazy
folks....it was intended to illustrate the level of effort
that honest people have to expend in order to accommodate
our less enlightened brethren.

	If I were running MSGGROUP, I would simply throw
away wild char strings -- such as headerless crud from ITS.
They are no more fun for others than they are for you; so
why send them along ?  Our mods to Rand-Unix were done in
the spirit of self-defense, that's all.

	DISCARD !  That's the correct play, I belive.

	(private msg follows shortly)


				Gary

20-Apr-79 19:00:50-PST,1947;000000000001 
Mail from MIT-ML rcvd at 20-Apr-79 1545-PST
Date: 20 Apr 1979 1826-EST
Sender: NMA at BBN-TENEXA
Subject: MSGGROUP#1099  Re: Mail troubles
From: NMA at BBN-TENEXA
To: MOON5 at MIT-ML
Cc: MSGGROUP at MIT-ML, STEFFERUD at ISI, CBF at MIT-ML
Message-ID: <[BBN-TENEXA]20-Apr-79 18:26:42.NMA>
In-Reply-To: Your message of 20 APR 1979 0103-EST

HI DAVID - FOR SME REASON THE MESSAGES FOR THE ENCLOSED HEADERS
DID NOT SEEM TO MAKE IT TO MSGGROUP@ISI DIRECTLY.

I HAVE FORWARDED THEM NOW FROM HERE AT BBNA.  LATER MESSAGES HAVE
GOTTEN THROUGH SO THE PLUG SEEMS TO BE GONE.  HOW ABOUT SOMONE
CHECKING THE [ISI]<MSGGROUP>MESSAGE.TS
XT SURVEY AGAINST THE
MSGGROUP@ML LOG?  I WILL SUPPLY A SURVEY LISTING OF THE RECEIVED
MSGS AT ISI AND SEND IT ALONG TO MOON5 AND CBF.

THANKS - STEF


- - - - - - - - - - - - - - - - - - - - 5242 chars/  1
Subject: Manually forwarded mail

Date: 20 APR 1979 0042-EST
From: MOON5 at MIT-ML (David A. Moon) - - 
To: MSGGROUP at MIT-ML
*** TRAILER *** 
Mail from MIT-ML rcvd at 20-Apr-79 0147-EST
*** END Manually forwarded mail /#  1 
- - - - - - - - - - - - - - - - - - - -  730 chars/  2
Subject: Manually forwarded mail

Date: 20 APR 1979 0043-EST
From: MOON5 at MIT-ML (David A. Moon) - - 
To: MSGGROUP at MIT-ML
*** TRAILER *** 
Mail from MIT-ML rcvd at 20-Apr-79 0209-EST
*** END Manually forwarded mail /#  2 
- - - - - - - - - - - - - - - - - - - - 1053 chars/  3
Subject: Manually forwarded mail

Date: 20 APR 1979 0043-EST
From: MOON5 at MIT-ML (David A. Moon) - - 
To: MSGGROUP at MIT-ML
*** TRAILER *** 
Mail from MIT-ML rcvd at 20-Apr-79 0229-EST
*** END Manually forwarded mail /#  3 
- - - - - - - - - - - - - - - - - - - -  524 chars/  4
Subject:  Mail troubles

Date: 20 APR 1979 0103-EST
From: MOON5 at MIT-ML (David A. Moon) - - 
To: MSGGROUP at MIT-ML
*** TRAILER *** 
Mail from MIT-ML rcvd at 20-Apr-79 0246-EST
*** END Mail troubles /#  4 

20-Apr-79 19:00:50-PST,426;000000000000   
Mail-from: MIT-ML rcvd at 20-Apr-79 1804-PST
Date: 20 April 1979 20:50-EST
From: Richard M. Stallman <RMS at MIT-AI>
Subject: MSGGROUP#1100  Other headers are strange too
To: MSGGROUP at MIT-AI

What are the ".:."'s supposed to mean?

From: Grm at Rand-Unix
Date: 19 Apr 1979 at 1034-PST
To: ffm at Mit-Mc
cc: msggroup at Mit-Ml
From-the-tty-of: Gary R. Martins
 .:.
Subject: All Kinds of Literacy...
 .:.