10-MAY-78 22:11:23-PDT,4255;000000000001   
Mail from BBN-TENEXA rcvd at 6-NOV-75 1318-PST
Date: 6 NOV 1975 1613-EST
Sender: MOOERS at BBN-TENEXA
Subject: MSGGROUP# 201 6. HOW SHOULD WE DEFINE "RECENT" AND "SEEN" MESSAGES?
From: MOOERS at BBN-TENEXA
To: [ISI]<MsgGroup>Mailing.List:
Cc: REVIEWGROUP.ADDRESSLIST:
Message-ID: <[BBN-TENEXA]6-NOV-75 16:13:01-EST.MOOERS>

MAILSYS now has a message-field "Status", which is automatically
created for each incoming message in the User's INBOX.

Status is the first item in the BASIC-SURVEY template. In User-
defined templates created with the Template Editor, the Status
field may be included at any position.

The format of Status adheres to the convention established by
MSG:

     <UNSEEN spec><RECENT spec>

where <UNSEEN spec> is a single character which may be either a
minus sign "-" = UNSEEN or a space " " = SEEN

and <RECENT spec> is a single character which may be either a
plus sign "+" = RECENT or a space " " = OLD


We would like to get input from the MsgGroup on the best
definitions of UNSEEN and RECENT.


THE DEFINITION OF SEEN AND UNSEEN

When should MAILSYS mark as message as SEEN?

1. Should MAILSYS pay attention to what commands are used to
process messages? If so, then the SURVEY command should NOT mark
the message as SEEN, and the TRANSCRIBE, PRINT and LIST commands
SHOULD mark the message as SEEN.

What about the FILE command? In the old MAILSYS the WRITE command
does NOT mark the message as SEEN. Do we follow this convention?

2. A better approach may be to have the TEMPLATE, not the command
be the determining factor. We can make a rule that any template
whatever, whether System-defined or User-defined, should mark the
message SEEN if, and only if, the template contains the TEXT
field. Then the FILE command always marks the message as SEEN.
However, the SURVEY command marks a message as SEEN if the User
sets the SURVEY template to some template that contains a TEXT
field.


3. If you try to define some combination of command and template
that determines which messages are marked seen, you quickly get
into a complicated tangle:
	
				 VER-		BASIC-	 User-	
				BATIM	ALL	SURVEY	Defined	
-----------------------------------------------------------------
TRANSCRIBE |CURRENT-TEMPLATE	SEEN	SEEN	  ?	 SEEN	  
or PRINT   |-----------------------------------------------------
or LIST    |SURVEY-TEMPLATE	SEEN	SEEN	UNSEEN?	 UNSEEN?
-----------------------------------------------------------------
SURVEY     |SURVEY-TEMPLATE	 ?	 ?      UNSEEN	 UNSEEN?
-----------------------------------------------------------------
FILE       |Transcribes everything 		 ?
-----------------------------------------------------------------

	
4. Perhaps we should build into the TEMPLATE Editor, the choice
of whether the template marks the message SEEN.
	
     >TEMPLATE JOE (CR)     [User creates the template in the
			    subcommand mode, then...]

     >>Name template: JOE (ESC) (marks message) SEEN [or UNSEEN] 
	
5. At present, if a TRANSCRIBE operation marks a message SEEN, it
is SEEN forever more. Is this reasonable? What about the
secretary who CONNECTS (through the EXEC) to a User's INBOX,
LISTS the RECENT messages, and then leaves the printout on the
User's desk each morning? When the User enters the Inbox, later
on, should those messages be marked SEEN?


THE DEFINITION OF RECENT

We now plan to include a separate MAILSYS User's profile which
contains a record of when that particular User last entered any
INBOX (or MESSAGE FILE).
	
			 <User>		<User>	       <User>
			MESSAGE.	ALPHA.		BETA.
			  TXT		 TXT		 TXT

MAILER delivers a 	RECENT		 ---		 ---
message.  User then	UNSEEN		 ---		 ---
enters Message.TXT

User FILES message	RECENT		RECENT		 ---
in ALPHA.TXT, without	UNSEEN		UNSEEN		 ---
other action, and
leaves the INBOX.

User re-enters	 	OLD		RECENT		 ---
MESSAGE.TXT		UNSEEN		UNSEEN		 ---

User TRANSCRIBES	OLD		RECENT		 ---
the message to TTY:	SEEN		UNSEEN		 ---

User FILES the same	OLD		RECENT		RECENT	
message in BETA.TXT	SEEN		UNSEEN		SEEN 

User enters ALPHA.-	OLD		OLD		RECENT
TXT, leaves without	SEEN		UNSEEN		SEEN
processing the mes-
sage, then re-enters.
	
-------
10-MAY-78 22:11:24-PDT,2561;000000000001  
Mail from BBN-TENEXA rcvd at 6-NOV-75 1319-PST
Date: 6 NOV 1975 1605-EST
Sender: MOOERS at BBN-TENEXA
Subject: MSGGROUP# 202 5. HOW MAILSYS "TEMPLATES" TRANSCRIBE MESSAGES
From: MOOERS at BBN-TENEXA
To: [ISI]<MsgGroup>Mailing.List:
Cc: REVIEWGROUP.ADDRESSLIST:
Message-ID: <[BBN-TENEXA]6-NOV-75 16:05:16-EST.MOOERS>

HOW MAILSYS "TEMPLATES" TRANSCRIBE MESSAGES

In MAILSYS, the general command for moving messages is TRANSCRIBE
(which has the special cases: PRINT, LIST and SURVEY).

The general form of TRANSCRIBE is:

TRANSCRIBE <sequence> <template> <destination> (CR)

The first of these argments, SEQUENCE, specifies what messages
are to be TRANSCRIBED; the third specifies the DESTINATION to
which the specified messages are to be sent. The middle argument,
TEMPLATE, specifies the form in which the TRANSCRIBED messages
are to appear. This dicussion attempts to give some idea of what
TEMPLATES can do, in the hope of clearing up prior confusion.

In creating the TEMPLATE feature, we were motivated by the desire
to provide in MAILSYS some kind of report-generating capability.
The User is able to specify what parts of a message are to appear
in the output, in what order, and how they should be formatted.

A TEMPLATE can be thought of as a map that specifies how your
messages are to be output from the computer.


TEMPLATES allow very precise control over the output. For
example, you can put each field on a separate line, or several
fields on one line, in the order you choose.

You can specify whether or not each field is to carry an
identifying label.

You can insert arbitrary text into a TEMPLATE -- to add more
information, or for aesthetic reasons. The added material can be
whole lines of text, spaces, or blank lines. You can place bits
and pieces of text within a line, along with the message fields.

The TEMPLATE Editor is called into action by the command MODIFY
TEMPLATE. The Editor consists of a group of subcommands which
allow you to create new TEMPLATES or modify copies of existing
TEMPLATES. As you edit a TEMPLATE, inserting or deleting lines,
or changing the selection and order of the items within line, you
can, at any point, see a display of the TEMPLATE as it currently
stands.

See MsgGroup # 177 "A Conceptual Introduction to MAILSYS Message-
Processing Commands" for details. (Remember that we have
recently, and tentatively, changed a few of the names of objects
in MAILSYS: SEQUENCE = MESSAGE-LIST, MESSAGE-FILE = INBOX, and
DESTINATION = STREAM.)
-------
10-MAY-78 22:11:24-PDT,1909;000000000001    
Mail from BBN-TENEXA rcvd at 6-NOV-75 1319-PST
Date: 6 NOV 1975 1556-EST
Sender: MOOERS at BBN-TENEXA
Subject: MSGGROUP# 203 4. A DESIGN CHOICE: SEPARATE COMMANDS vs. COMMANDS WITH
Subject: DEFAULT "SWITCH" SETTINGS
From: MOOERS at BBN-TENEXA
To: [ISI]<MsgGroup>Mailing.List:
Cc: REVIEWGROUP.ADDRESSLIST:
Message-ID: <[BBN-TENEXA]6-NOV-75 15:56:29-EST.MOOERS>

Stefferud has complained about the difficulty of remembering how
the SWITCHES in the MAILSYS profile are set at any given time.
Some of us at BBN have had the same trouble.  It is hard to
remember when you are not totally familiar with the system. 

We have no strong objection to separate commands like the QUIT-
EXIT pair.  However, they also present a problem.  I find it
impossible to remember whether QUIT or EXIT does the clean-up in
MSG.

There seem to be three approaches we could use:
	
     A. Pairs of separate commands for doing essentially the same
        job, like MSG's QUIT-EXIT and PUT-MOVE.

     B. Single commands with symmetrical SWITCH settings and
        subcommands, like the current MAILSYS QUIT

	>QUIT,(CR)		and		>MODIFY SWITCHES
	>>?					>>QUIT ?
	Cleanup					Cleanup
	Nocleanup				Nocleanup
	Askcleanup				Askcleanup
	>>					>>

     C. A permanent feature, like  Askcleanup, which asks the User
        whether to cleanup the deleted messages if any.  (This
        need not be a SWITCH setting.)
		
I realize that the abbreviated documentation in the "Conceptual
Introduction to MAILSYS" did not emphasize the Askcleanup feature.

MAILSYS now has Askcleanup as the standard SWITCH setting for
QUIT:
	
     >QUIT(CR)
     May I clean up and renumber the Inbox?

The same concept could be extended to FILE

     >FILE <SEQUENCE> <DESTINATION> (CR)
     May I delete the source messages?

The printout could be shortened:  Cleanup?  Delete source?
	
		
-------
10-MAY-78 22:11:25-PDT,4246;000000000001  
Mail from BBN-TENEXA rcvd at 6-NOV-75 1321-PST
Date: 6 NOV 1975 1541-EST
Sender: MOOERS at BBN-TENEXA
Subject: MSGGROUP# 204 3. MAILSYS COMMANDS AND THEIR ARGUMENTS
From: MOOERS at BBN-TENEXA
To: [ISI]<MsgGroup>Mailing.List:
Cc: REVIEWGROUP.ADDRESSLIST:
Message-ID: <[BBN-TENEXA]6-NOV-75 15:41:14-EST.MOOERS>

In MAILSYS, the general command for moving messages is TRANSCRIBE
(which has the special cases, PRINT, LIST and SURVEY).

The general form of TRANSCRIBE is:

TRANSCRIBE <sequence> <template> <destination> (CR)

The first of these arguments, SEQUENCE, specifies what messages
are to be TRANSCRIBED. The second argument specifies the form in
which the TRANSCRIBED messages are to appear. The third argument,
DESTINATION, specifies the output device or file to which the
messages are to be sent.

In MAILSYS, these arguments are called "objects", and much of the
power and versatility of the system comes from the methods of
specifying these objects. There are also three other kinds of
object: MESSAGE-FILE, FILTER, and SWITCHES.
	
   A FILTER selects messages according to the information they 
   contain or their status.  The convention for specifying a
   SEQUENCE acted upon by a FILTER is SEQUENCE/FILTER.  (More
   complex specifications are also possible.)

   A MESSAGE-FILE is a TENEX file that contains MAILSYS-readable
   messages.

   SWITCHES is a collection of "switch settings" that specify
   the User's choice of how different commands in MAILSYS are
   to function.
	

CURRENT OBJECTS

To make the system easy to use, and to reduce the amount of
typing required, MAILSYS always has a subset of objects which act
as the default values for the arguments of the message-handling
commands.  If the User leaves out an argument, the appropriate
object is selected.  These objects are called the "current
objects."

Thus the command

>TRANSCRIBE (CR)

means TRANSCRIBE the current SEQUENCE in the form specified by
the current TEMPLATE and output the resulting messages on the
current DESTINATION.

Similarly

>TRANSCRIBE / (CR)

means TRANSCRIBE the current SEQUENCE acted upon by the current
FILTER according to the current TEMPLATE and output it on the
current DESTINATION.

NOTE: All the current objects are printed out by MAILSYS if the
User uses the escape key, rather than the space bar, to default
the arguments:

>TR(ESC)ANSCRIBE (sequence)(ESC) CSEQUENCE/(ESC)CFILTER(ESC)
(using template)(ESC)CTEMPLATE (ESC)(on destination) TTY: (CR)

Here, the DESTINATION is printed out literally because MAILSYS
allows only one DESTINATION to be stored in the system at one
time.

The system can store any number of SEQUENCES, FILTERS, and
TEMPLATES, each having its own name; however, there can be only
one Current SEQUENCE, current FILTER, or current TEMPLATE at a
time, and these have the names CSEQUENCE, CFILTER and CTEMPLATE.


USE, COPY AND MODIFY

The commands USE, COPY and MODIFY have no direct equivalents in
MSG because they act upon MAILSYS objects, not upon incoming or
outgoing messages.

USE means "USE as the current object". The USE command changes
the current object to a copy of a named object already in the
environment, or to a literal value typed in by the User.

>USE (as current) <object class> <name or literal value> (CR)

There are three special cases of USE:
	
INPUT = USE MESSAGE-FILE
CONSIDER = USE SEQUENCE
JUMP-TO = USE MESSAGE-NUMBER
	
The COPY command makes a copy of any SEQUENCE, FILTER or
TEMPLATE, and saves it under a new name selected by the User.

>COPY <name of old object> (to) <name of new object> (CR)

The MODIFY command can be used with the objects SEQUENCES,
FILTERS, TEMPLATES, or SWITCHES, or with the User's PROFILE.
MODIFY calls a group of powerful Editors -- a different one for
each class of objects -- which operate in the subcommand mode.

>MODIFY <name of object> (CR)

See MsgGroup # 177 "A Conceptual Introduction to MAILSYS Message-
Processing Commands" for details. (Remember that we have
recently, and tentatively, changed a few of the names of objects
in MAILSYS: SEQUENCE = MESSAGE-LIST, MESSAGE-FILE = INBOX, and
DESTINATION = STREAM.)
-------
10-MAY-78 22:11:25-PDT,417;000000000001  
Mail from USC-ISI rcvd at 7-NOV-75 2117-PST
Date: 7 NOV 1975 1933-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 205 Change Mealy to ISID
From: STEFFERUD at USC-ISI
To: [ISI]<MsgGroup>Mailing.List:
Message-ID: <[USC-ISI]7-NOV-75 19:33:20-PST.STEFFERUD>

George Mealy asks that we all send his mail to Mealy@ISID.  The
change has been made to [ISI]<MsgGroup>Mailing.list.  

Thank you, Stef 
-------
10-MAY-78 22:11:25-PDT,687;000000000001  
Mail from USC-ISI rcvd at 7-NOV-75 2117-PST
Date: 7 NOV 1975 1922-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 206 Add Stan Taylor to MsgGroup
From: STEFFERUD at USC-ISI
To: Taylor at OFFICE-1
Cc: [ISI]<MsgGroup>Mailing.List:
Message-ID: <[USC-ISI]7-NOV-75 19:22:35-PST.STEFFERUD>

Hi Stan,  Welcome to Message Group.  Your name is now in the
master Mailing list in [ISI]<MsgGroup>Mailing.list.

You will receive some introductory stuff in the next few messages
to get you into it.

Message Group Members should add Taylor@OFFICE-1 to their lists or
get a new list from [ISI]<MsgGroup>, or ask me to SNDMSG a new
official copy.

Best Regards,    Stef
-------
10-MAY-78 22:11:25-PDT,1248;000000000001
Mail from BBN-TENEXA rcvd at 10-NOV-75 1406-PST
Date: 10 NOV 1975 1700-EST
Sender: MOOERS at BBN-TENEXA
Subject: MSGGROUP# 207 More on separate commands vs. default "switch" settings.
From: MOOERS at BBN-TENEXA
To: [ISI]<MsgGroup>Mailing.ListI
Cc: REVIEWGROUP.ADDRESSLISTI   
Message-ID: <[BBN-TENEXA]10-NOV-75 17:00:01-EST.MOOERS>   

Stef--

The great controversy on QUIT-EXIT vs.  QUIT with switch settings
may be a step further toward resolution.

What do you say to the following?

Define QUIT so that it has a three-way switch, like MAILSYS at
present:

QUIT:  Optional settings: 1) Askcleanup, 2) Cleanup, 3) Nocleanup

Then define EXIT exactly the same way:

EXIT:  Optional settings: 1) Askcleanup, 2) Cleanup, 3) Nocleanup

You can have QUIT = quit without cleanup and EXIT = quit with
cleanup.  I can have QUIT = quit with Askcleanup, and I can
ignore EXIT.  Somebody else can have whatever seems right to him.

Okay?  And we can do the same for FILE and PUT.  Each can have a
choice of Delete, Nodelete, Askdelete.

All such switches might originally be set to the "Ask" version of
the setting.  That way, the User would be reminded to think of the
vaaious options available.

---Charlotte
-------
10-MAY-78 22:11:25-PDT,1340;000000000001   
Mail from USC-ISI rcvd at 10-NOV-75 1501-PST
Date: 10 NOV 1975 1447-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 208 (More on separate commands vs. default "switch" settings.)
From: STEFFERUD at USC-ISI
To: MOOERS at BBN-TENEXA
Cc: [ISI]<MsgGroup>Mailing.List:
Message-ID: <[USC-ISI]10-NOV-75 14:47:17-PST.STEFFERUD>
In-Reply-To: <[BBN-TENEXA]10-NOV-75 17:00:01-EST.MOOERS>   

HI CHARLOTTE,  "I THINK YOU'VE GOT IT!"

WHAT WE WANT IS THE CAPABILITY TO TAILOR IT TO SUIT OUR TASTE AND STYLE.

NOW, CAN YOU EXTEND THE CONCEPT TO COVER ALL THE POINTS WE HAVE BEEN 
ARGUING ABOUT.  I AM HESITANT TO AGREE IN ADVANCE WITH WHAT YOU MIGHT DO, 
BUT IT LOOKS LIKE YOU HAVE FOUND THE MAGIC ATTITUDE OF PERMISSSIVENESS.

BY THE WAY, I WANT TO COMMEND DAVE DCROCKER'S PERSPECTIVE SETTING PLOY.
I THINK THAT HIS EXERCISE OF TRYING THE COMMAND OUT IN ENGLISH WITH A 
REAL SUBJECT SHULD LEAD TO AN EXECELLENT FIRST APPROXIMATION TO THE ENTIRE
SET OF NEEDED COMMANDS.

I AM STILL IN THE PROCESS OF DIGESTING THE WHOLE OF YOUR RECENT MSGS
(1-6) AND AM HOPING TO GET TO THEM NEXT WEEK.

IF THERE ARE SOME ESPECIALLY PRESSING AREAS THAT YOU WISH ME TO GIVE
EARLIER ATTENTION, PLEASE LET ME KNOW.   AM BOOKED FOR THE WHOLE WEEK
BUT CAN FIND SOME TIME FOR A SHORT REACTION SUCH AS THIS ONE.

BEST REGARDS,   STEF
-------
10-MAY-78 22:11:25-PDT,683;000000000001 
Mail from BBN-TENEXA rcvd at 12-NOV-75 1139-PST
Date: 12 NOV 1975 1429-EST
Sender: MOOERS at BBN-TENEXA
Subject: MSGGROUP# 209 Thank you for your response
From: MOOERS at BBN-TENEXA
To: [ISI]<MsgGroup>Mailing.ListI
Cc: REVIEWGROUP.ADDRESSLISTI  
Message-ID: <[BBN-TENEXA]12-NOV-75 14:29:30-EST.MOOERS>   

Stef --

We are delighted with your enthusiastic reponse.

We want to be permissive and allow Users as much freedom as
possible to tailor their systems so they feel comfortable.

Let's have more input from you (and all other message-group
members) about the places in the system where we can insert those
comfort-giving choices.

---Charlotte
-------    
10-MAY-78 22:11:25-PDT,1652;000000000001 
Mail from USC-ISI rcvd at 12-NOV-75 1513-PST
Date: 12 NOV 1975 1505-PST
From: DCROCKER at USC-ISI
Subject: MSGGROUP# 210 You can have anything you want.  Just ask....
To:   [ISI]<MsgGroup>Mailing.List:

Charlotte -- I, too am greatly in favor of highly adaptive systems; in
case that fact had not already been communicated.  There is, however, a
VERY serious danger with putting too much reliance upon that
adaptability.  A user's impression of a system, and I think their future
ability to learn the system (can't prove the latter assertion) is
tremendously affected by their initial interactions.  Those interactions
take place BEFORE the user can do any tailoring.  Consequently,
tailoring had better only be fine-tuning and NOT represent a major shift
in the system's appearance.  

This suggests that the number of commands changed should be small and,
therefore, that most of the commands had better be "right" from the
perspective of most users.  I refer to syntax and vocabulary, both.  

Tho not directly related to adaptability, here is an example of what can
happen when the user is given too much of a good thing:  XED has a
backup command that behaves somewhat idiosyncratically (to say the
least).  Some people suggested various modifications to it.  What they
suggested was the same as using the WRITE command and hitting <esc>, to
let the next highest version number be used.  However, it had never
occurred to these people that the WRITE command should be used.  They
had been given the Backup command and so the idea of its use was fixed
in their minds.  

First impressions last.  

Dave.  
-------
10-MAY-78 22:11:25-PDT,451;000000000001   
Mail from USC-ISI rcvd at 13-NOV-75 1058-PST
Date: 13 NOV 1975 1037-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 211 You are welcome
To:   Mooers at BBNA
cc:   [ISI]<MsgGroup>Mailing.List:

You are most welcome for the response regarding permissiveness
and comfort.  And I agree about more reaction and comment
from others of the MsgGroup.  Surely I do not speak for the group!


Best regards, and more comment later,  Stef
-------
10-MAY-78 22:11:26-PDT,1605;000000000001   
Mail from USC-ISI rcvd at 18-NOV-75 1928-PST
Date: 18 NOV 75 1925-PST
From: STEFFERUD
Sender: STEFFERUD
Subject: MSGGROUP# 212 RE: You can have anything you want.  Just ask....
To: DCROCKER at USC-ISI
CC: MsgGroup
Message-Id: <[USC-ISI]18-NOV-75 19:25:00-PST.STEFFERUD>
Keywords: levels, simple, tailoring
In-Reply-To: <[FAKE]-11-((75 11 14) (22 3 9) "PST").STEFFERUD>


Hi Dave, 

To respond to your message of 12 Nov, regarding adaptive message
systems, I agree entirely with the points you make, and would like
to suggest that tailorable systems should have a graded set of
sophistication levels available as default options to facilitate
new users who will exhibit growing sophistication and hence need a
growing set of capabilities.  

Clearly, it is important to some of our intended users that we
give them the ultimate in simplicity for their beginning efforts,
and that new capability levels be readily available for them to
use as they get into it.  Without simplified entry levels and
quickly accessible expanded capabilities, we cannot properly
penetrate the market.  

As for the XED Backup Command I want to confess to being one of
the people caught in the trap.  You have precisely diagnosed the
way I trapped myself into fighting a feature that I should have
ignored altogether!  To avoid the trap required taking enough time
to carefully think through the system concept and to do so was not
intuitive at the time.  I wonder how many others have fallen into
the same trap.  

I agree, first impressions do last!  

Best Regards, Stef 


--------
10-MAY-78 22:11:26-PDT,888;000000000001 
Mail from USC-ISI rcvd at 23-NOV-75 1523-PST
Date: 23 NOV 1975 1519-PST
From: DCROCKER at USC-ISI
Subject: MSGGROUP# 213 Envelopes
To:   [ISI]<MsgGroup>MSGDMS.TEST-GROUP:
cc:   [ISI]<MsgGroup>Mailing.List:

Envelopes have been mentioned several times now (initially by Stef) and
I want to make sure we know what part of mail is actually the envelope,
so that when we throw it away, we still have ALL of the actual letter.  

I contend that the name of the file that contains the mail, before it is
sent, is the envelope.  All of the header information (except the kind
of unofficial line that Tenex puts at the beginning of a message showing
source and time of receipt, which is like a postmark) is part of the
actual letter and therefore should always accompany the text of the
letter (when the letter is being moved as an entire unit).  

Thoughts?  Dave.  
-------
10-MAY-78 22:11:26-PDT,884;000000000001
Mail from OFFICE-1 rcvd at 24-NOV-75 0616-PST
Date: 24 NOV 1975 0611-PST
From: UHLIG at OFFICE-1
Subject: MSGGROUP# 214 Re Farber's message on "Envelopes"
To:   [ISI]<MsgGroup>Mailing.List:

I guess I had always thought about the envelope as including the
address (TO:) and the return address (hopefully FROM:), rather
than the more limited set that Dave Farber suggests.  While
the stuff that normally goes on the envelope of regular US (or
other) mail is normally thrown away in an office, I agree that it
needs to be on file.  Perhaps it should properly be discarded,
after a process which would strip that info off the envelope and
file it in a list of correspondents.  That could be separate
for every individual having a mailbox, or some kind of central
system could be set up.  Many variations are possible, but I think
I like the idea.
   Ron Uhlig
-------
10-MAY-78 22:11:26-PDT,54246;000000000001 
Mail from OFFICE-1 rcvd at 26-NOV-75 0657-PST
From: PANKO at OFFICE-1
Date: 26 NOV 1975 0658-PST
Subject: MSGGROUP# 215 The NLS Journal Mail Conference
Distribution: msggroup@USC-ISI



INTRODUCTION

   RA3Y 11-SEP-75 15:17  33459
   A Teleconference on a New Journal System
   Location: (JOURNAL, JRNL29, J33459:gw)
   *****Note: Author Copy*****
   

      Message:

              Doug has asked me to coordinate the promotion of a new and
         more beautiful Journal system.  I would appreciate you comments
         on what featues the next-generation journal system should have.
         Please send them to my ident, RA3Y.
              I will put all suggestions in a file in my directory: 
         Panko,Transcript.  Please feel free to read them and respond to
         any items by sending comments to me via Sendmail (no 
         Sendmessages, please).
              About titles.  When you send something, make the title as 
         specific as possible.  For example, don't remark that it is for
         the Journal teleconference.  If we keep titles specific, we may
         be able to search for them.
              Panko,transcript, also contains a number of "exhibits," 
         i.e. old citations dealing with the journal system.
                             Thanks, Ra3y

EXHIBITS

   BEV 18-SEP-75 13:51  26426
   Sendmail Sample Session I (part of Sec. Functions Guide)
   Location: (HJOURNAL, 26426, 1:w)
   

      Comments: A piece of the Secretary Functions Guide that didn't get
      journalized with the rest of it on Sept. 9.

   BEV 9-SEP-75 20:23  26427
   Sendmail Sample Sesssion II (Secretarial Functions Guide)
   Location: (HJOURNAL, 26427, 1:w)
   

   DCE 29-JUL-75 12:43  33076
   NLS TELECONFERENCING FEATURES: THE JOURNAL, AND SHARED-SCREEN 
   TELEPHONING
   Location: (HJOURNAL, 33076, 1:w)
   

      Comments: This paper was submitted for presentation at COMPCON 75,
      to be held in Washington D.C., 9-11 Sep 75.  They require a 
      'digest' for their proceedings, limited to a fixed maximum page 
      space.

   JAKE 19-AUG-75 03:02  26293
   Network Identification System - Comments and Suggestions
   Location: (HJOURNAL, 26293, 1:w)
   

   JBP 29-APR-75 01:52  25806
   'MSG' mail reading and processing program documentation
   Location: (GJOURNAL, 25806, 1:w)
   *****Note:  [ INFO-ONLY ] *****
   

      Comments: The MSG mail program is installed as a TENEX subsystem 
      at BBNB.

   JEW   23144
   Description of a Multi-Host Journal System
   Location: (MJOURNAL, 23144:gw)
   *****Note: Simulated Citation*****
   

   KIRK 12-SEP-75 23:56  26464
   Readmail design document
   Location: (HJOURNAL, 26464, 1:w)
   

      Comments: Should be considered as an 'exhibit' for RA3Y's new 
      Journal design.  After this design was written, it was decided 
      Tabs, Help, and Air Force Manual formatting had priority, so it 
      has not been implemented.  The design is written as a Userguide 
      and a Help file.  It contains suggestions received since the last 
      time it was journalized.

   RA3Y 11-SEP-75 20:49  33466
   Recorded Dialog: Section from the Final Report
   Location: (HJOURNAL, 33466, 1:w)
   *****Note: Author Copy*****
   

      Comments: This is Branch 13 of the Final Report on Project 1868; 
      this report is scheduled to be COM'd soon.  The enclosed branch is
      Jim White's chapter on Recorded Dialog.

   RA3Y 15-NOV-75 11:10  33911
   Message Service Group Transactions - June 1975
   Location: (IJOURNAL, 33911, 1:w)
   *****Note: Author Copy*****
   

   RA3Y 15-NOV-75 11:14  33912
   Message Service Group Transactions in July 1975
   Location: (JOURNAL, JRNL31, J33912:gw)
   *****Note: Author Copy*****
   

   RA3Y 15-NOV-75 11:19  33913
   Message Service Group Transactions in August 1975
   Location: (IJOURNAL, 33913, 1:w)
   *****Note: Author Copy*****
   

   RA3Y 15-NOV-75 11:27  33914
   Message Service Group Transactions in September 1975
   Location: (IJOURNAL, 33914, 1:w)
   *****Note: Author Copy*****
   

   RA3Y 15-NOV-75 11:36  33915
   Message Service Group Transactions in October 1975
   Location: (IJOURNAL, 33915, 1:w)
   *****Note: Author Copy*****
   

   RLL 24-FEB-75 15:04  25451 citation template
   'Final' citation template with complete discussion.
   Location: (HJOURNAL, 25451, 1:w)

      Comments: the template will be also journalized as a separate 
      item.
      This has been approved by all and thus is the desired and official
      format.  At the moment no move is being made to change current 
      citation to this new form.
      This is also example of cooperative design; many people were 
      involved and many cycles were made in the process of developing 
      this format.

   RLL 26-DEC-74 13:54  24828 Journal citation dialogue second go
   Journal citation dialogue: second go around; two alternatives; call 
   for a meeting.
   Location: (GJOURNAL, 24828, 1:w)

      Comments: I think it is time that a decision is made as to the 
      form of the citation.  Perhaps a meeting some time the week of 
      january 6th.  Send your responses to me (RLL) on either date and 
      time or comments on alternatives.  Thanks Rob

   RLL 29-SEP-75 14:40  26590
   Journal envelop discussion references 1974-75
   Location: (HJOURNAL, 26590, 1:w)
   *****Note:  [ ACTION ] *****
   

      Comments: I believe 25451 and 24828 have references to all the 
      other citations as well as including their thoghts within the 
      discussion.

CONFERENCE RECORD

   JHB 8-SEP-75 16:22  33433
   Disregard (HJOURNAL, 33420,): NLS error got entire file instead of 
   specified structure
   Location: (JOURNAL,JRNL29,J33433:w)
   *****Note: 
   (Secondary Distribution Copy from JHB)*****
   

      Message:

         I discovered some bugs in the Sendmail subsystem as a result of
         trying to use Process (sendmail form):
         1)  Apparently, if you use a sendmail form and bug the 
         beginning of the form, the file in which the form resides will 
         be sent regardless of what structure you specified in the form.
         This could be due to leaving the parts of the inserted form 
         that refer to branch, Plex, etc., empty.  In my case, I had 
         specified a message, but not the other structures (which 
         logically would be cancelled out by Message).
         2) It was also pointed out recently that when the subsystem 
         decides that what you have submitted is a Message, the 
         notifications for Action/Info go away, and so do the 
         parenthetical comments associated with the Idents.
         I am taking action to correct (33420,), so please read the part
         I really wanted to send in a few days.    Thanks, Jim

   DVN 7-NOV-74 16:46  24437 Journal Delivery-header
   One More thought about Journal Deliveryy

   RLL 5-NOV-75 15:09  26867
   SUG: several ideas on the Sendmail/Journal system
   Location: (JOURNAL, JRNL31, J26867:gw)
   

      Message:

         May I suggest what I thought was obvious (at least to DNLS 
         users): Please do NOT put links or any parentheses in the 
         Journal title.

         Also make use of keywords to relate all items pertaining to a 
         particular subject or issue.  Subcollections also work very 
         well but only for those group idents identified with a 
         particular interest or subject.

         SUG: could we change sendmail so that it verifies the existance
         of a title when sending mail?  If none given then offer the 
         option to the author to give one; if he still does not wish to 
         give a title, ok send the mail.

         Use the COMMENTS for references and all links.

         Keep the number of characters short for a message and length of
         statements down also.

   RLL 31-OCT-75 14:33  26822
   SUG: and answer to a problem on using Output journal command for 
   printing files  by specifying links
   Location: (JOURNAL, JRNL30, J26822:gw)
   *****Note:  [ ACTION ] *****
   

      Message:

         If one has a dummy branch called 'journal' with substatements 
         containing <EOL>Location: (link)  The output journal file 
         commad can be used to print diffeent files or different parts 
         of a file, in  any order and with specified viewspecs.  See JCN
         ETS discription for a useful example.. BE CAREFUL to specify 
         the link with parentheses not angled brackets.  This was the 
         problem as spcified by Beck.  My suggestion: can Jeff or somone
         write a hack (in TECO?) to delete the <<<<<>>>> and other 
         garbage this process generates?  It should be an easy task.  We
         could even create a process command branch to do it. Have 
         viewpsec y on in each of the links;NLSize the txt file using 2 
         <CR> option;delete the garbage; and then output quickprint (or 
         printer).  I'll try this route ad let you allknow.  ROb

   RLL 31-OCT-75 14:33  26822
   SUG: and answer to a problem on using Output journal command for 
   printing files  by specifying links
   Location: (JOURNAL, JRNL30, J26822:gw)
   *****Note:  [ ACTION ] *****
   

      Message:

         If one has a dummy branch called 'journal' with substatements 
         containing <EOL>Location: (link)  The output journal file 
         commad can be used to print diffeent files or different parts 
         of a file, in  any order and with specified viewspecs.  See JCN
         ETS discription for a useful example.. BE CAREFUL to specify 
         the link with parentheses not angled brackets.  This was the 
         problem as spcified by Beck.  My suggestion: can Jeff or somone
         write a hack (in TECO?) to delete the <<<<<>>>> and other 
         garbage this process generates?  It should be an easy task.  We
         could even create a process command branch to do it. Have 
         viewpsec y on in each of the links;NLSize the txt file using 2 
         <CR> option;delete the garbage; and then output quickprint (or 
         printer).  I'll try this route ad let you allknow.  ROb

   KIRK 30-DEC-74 16:29  24859 journal headers/citations
   Some reasons for having <:wg> and using angle brackets in general in 
   the proposed new sendmail 'envelope' format
   Location: (GJOURNAL, 24859, 1:w)
   *****Note:  [ INFO-ONLY ] *****
   

   JEW 3-NOV-75 19:18  26843
   Third Draft of DPS Paper
   Location: (IJOURNAL, 26843, 1:w)
   

      Comments: See (26771,) and (26513,) for previous drafts.  Appendix
      D from draft two has been removed, and may become a separate, 
      follow-up paper.

   29-OCT-75 1040-PST  STEFFERUD at USC-ISI:  NLS Sendmail Description 
   from Panko@0FFICE-1
      Distribution:  [ISI]<MSGGROUP>MAILING.LIST:
      Received at:   29-OCT-75 14:58:55-PST

      Message-ID: <[USC-ISI]29-OCT-75 10:40:59-PST.STEFFERUD>

      The enclosed two headers of long messages from Panko@OFFICE-1
      are forwarded for your information.  You may obtain copies by
      the normal means of Reading or FTPing [ISI]<MsgGroup>MSGGROUP#.187
      or MSGGROUP#.188.

      If you wish to have a copy forwarded via SNDMSG, please request
      it by sending a request message to MsgGroup@ISI.

      You are urged to read these two messages to learn about the 
      Sendmail
      capabilities of the NLS system at OFFICE-1.

      Enjoy,   Stef

      8131 Chars 
      Mail from OFFICE-1 rcvd at 20-OCT-75 0745-PDT
      From: PANKO at OFFICE-1
      Date: 20 OCT 1975 0748-PDT
      Subject: MSGGROUP# 187 NLS Sendmail Sample Session I
      Distribution: msggroup@USC-ISI

      8639 Chars
      Mail from OFFICE-1 rcvd at 20-OCT-75 0748-PDT
      From: PANKO at OFFICE-1
      Date: 20 OCT 1975 0750-PDT
      Subject: MSGGROUP# 188 NLS Sendmail Sample Session II
      Distribution: msggroup@USC-ISI

   KEV 28-OCT-74 17:33  24337 hot/journal headers
   journal citations again

      Message: The issue that Dean raises (in-- 24336,) (and I think 
      Jake raised it also) about having sort programs, etc. work is I 
      beleive looking at the citation issue in the wrong way.  The 
      problem, as I see it, is having citations presented to an 
      INDIVIDUAL user in the format preferred by that INDIVIDUAL user.  
      Then if an individual wishes to sort her citations, it is her 
      responsibility (perhaps with our help) to provide the sort keys, 
      programs, etc. that will sort the citations in the desired manner.
      Obviously, these programs must be aware of the format of the 
      citations they are to sort.

      If an individual wishes to make use of pre-existing sorting 
      programs, then she must see to it that her citations conform to 
      the input format required by the program to be used (and of course
      both available programs and required citation formats should be 
      published).  All the catalog production programs that I am aware 
      of, do not go through individual initial files to get their data, 
      but work on other data bases.  Thus, if an individual is only 
      interested in seeing who wrote an article, when it was written, 
      and where it lives, (admittedly a perverse example), there is NO 
      need to have the title in the citation that gets delivered to this
      person. 
      *****Note:  [ ACTION ] *****
      

         Comments: I do have one or two other things to do, but 
         occasionally I need a relief from them!

   NDM 28-OCT-74 15:34  24336 hot/journal headers
   Opinion on Journal Citation Delivery Format
   Location: (MJOURNAL, 24336, 1:w)
   *****Note:  [ INFO-ONLY ] *****
   

      Comments: Modifies slightly format listed as NDM's choice in 
      (24284,).

   27-OCT-74 2047-PDT  BAIR:  Journal headers
      Distribution:  LIEBERMAN, bair
      Received at:   27-OCT-74 20:47:29

      Rob,  All my input is in...a clear statement of what it shoould in
      view of your suggestions.  That comprimise should satisfy all .  
      I do not think it should be sent to KWAC.  It would be very 
      inconsistent with previous design poloicypolicy. (witness the 
      unilateral imposition of the info and attention branches.)

   27-OCT-74 1830-PDT  LIEBERMAN:  journal headers: do u have more 
   input?
      Distribution:  BAIR, lieberman
      Received at:   27-OCT-74 18:30:04

      JIM: I have a hold on establishing the new journal header.  Sent a
      jornal item out last week.  Now have som feedback from SRI-ARC.  
      FOr a list of references see (lieberman,mail,header:wg). 
      I am reay for another go around, but not sure it worth including 
      anyone else but a few (JHB, DCE).  What s your opion?  should the 
      KWAC be asked to comment?

   JBP 25-SEP-75 15:12  26571
   Ident System Note
   Location: (HJOURNAL, 26571, 1:w)
   

      Comments: This is a DRAFT of the report on  the needs for an ident
      system in NSW to be sent to COMPASS. Please  make comments and 
      suggestions to me by 1 Oct.

   CHI 25-OCT-74 10:26  24324 hot/headers for journal
   Journal Citation Recomendations

      Message:

         Robbert, I have the following recommendations re Journal 
         citations delivered to users:
         1) The recipient should be able to choose among several 
         citation formats for mail delivered to him, or perhaps make up 
         his own ala KEV's suggestion (This desired Citation format 
         could be stored in master ident file)
         2) The distribution lists should be made available to the 
         recipient
         3) the [ACTION] and [INFO-ONLY] fields should not be removed 
         from the citation even though they are deposited into action 
         and info branches (because if the user moves them he looses 
         this info) and 
         4) I would like a citation format that had the author and title
         (as much as would fit) in the first line for t-viewspec.
         *****Note:  [ ACTION ] *****
         

   25-FEB-75 1021-PST  LIEBERMAN:  journal citations
      Distribution:  KELLEY, lieberman
      Received at:   25-FEB-75 10:21:37

      Kirk:  thanks for your interest in esponding to the final (?) [not
      t  be i mplemented ??] citation format.  YES YES YES.  i agree 
      entirely with you re statement names.  I lost that battle. Also 
      lost on full last nam and organizaation .  Ro

   25-FEB-75 1008-PST  LIEBERMAN:  journal citation vs. Network standard
      Distribution:  POSTEL, lieberman
      Received at:   25-FEB-75 10:08:06

      Jon: yes the reference is in the jornal itme but buried.  My fault
      for not making it more prominent.  Rob

   DVN 24-SEP-75 12:45  26551
   Comments To Inidividual Journal Recipients Should be Longer.
   Location: (JOURNAL, JRNL29, J26551:gw)
   

      Message:

         I mean when you write in a special note to one person after an 
         ident.  I use this feature a lot but if I have more than about 
         4 lines it says "String too long".  Often I have just typed 
         some long, subtle implication, and I am really pissed off when 
         that happens.  It sould be atleast 2000 characters.  While I am
         on the subject, you should be able to make such comments to the
         recipients of forwards, and forwarding should add the item to 
         appropriate subcollections.

   JAKE 24-OCT-74 22:58  24319 hot/journal headers
   Op. Cit.
   Location: (MJOURNAL, 24319, 1:w)
   *****Note:  [ INFO-ONLY ] *****
   

   DVN 24-OCT-74 22:17  24318
   More On Journal Citations hot/journal headers
   Location: (MJOURNAL, 24318, 1:w)
   *****Note:  [ ACTION ] *****
   

   KEV 24-OCT-74 14:38  24315 hot/journal headers
   journal citations revisited
   Location: (MJOURNAL, 24315, 1:w)
   *****Note:  [ ACTION ] *****
   

   JBP 24-OCT-74 09:58  24294 warm/journal headers
   journal headers
   Location: (MJOURNAL, 24294, 1:w)
   *****Note:  [ ACTION ] *****
   

   JHB 24-OCT-74 08:56  24291
   re J24269:  Journal notification & info/action branches
   *****Note:  [ INFO-ONLY ] *****

      Message:

         I agree with Dirk's notion aout these 2 new features, 
         particularly info and action.  These are arbitrary categories 
         at best, and serve to force additional compensatory decisions 
         on the real users.  IT's difficult not to be snide, but I don't
         recall any debate or even discussion about this.
         I hope that the items that have been sent by myself and others 
         on the Journal citation format are ok.  If not let's have some 
         discussion on them !
         

   JBP 24-FEB-75 22:35  25453 Journal Citations vs. ARPANet Standard
   Journal Citations vs. ARPA Network Standards

      Message:

         it might be useful to cite the ARPA network standard for 
         message headers for reference during the discussion of new 
         journal headers. The reference is RFC 561 <,18516,>. --jon.
         *****Note:  [ INFO-ONLY ] *****
         

   KIRK 24-FEB-75 21:44  25452 Comments on the 'final' journal citation
   Comments on the 'final' journal citation
   Message: In general looks very good.  Major bad thing is a time that 
   cannot be used for statement name (how about PDT1332 22-OCT-75) ?  
   This would give you a logical ordering of time elements (from small 
   to large) and allow access by statementname.  Jump to name next would
   always find the most recent one if the time happened to be 
   duplicated.
   
   One other thing, you should recommend that the Insert Sendmail (form)
   and Process Sendmail (form) commands use the same format in the same 
   order.   Good Show.
   *****Note:  [ ACTION ] *****
   

   RLL 23-OCT-74 22:38  24284 New Journal header: alternatives
   New Jornal header: alternatives;  call for comments and additional 
   input.
   Location: (MJOURNAL, 24284, 1:w)

      Comments: Comments received by FRiday 25Oct74 will be included for
      next pass which will include the KWAC.  Thank you for 
      contributing.

   DCE 22-SEP-75 09:27  33518
   Note on the term Dialog Support
   Location: (HJOURNAL, 33518, 1:w)
   

   RA3Y 22-OCT-75 21:41  33729
   Public Messages Send by Bell-Canada, First Six Months 1975
   Location: (IJOURNAL, 33729, 1:w)
   *****Note: Author Copy*****
   

   RA3Y 20-OCT-75 09:25  33702
   Should We Fit the Network Standard?
   Location: (IJOURNAL, 33702, 1:w)
   *****Note: Author Copy*****
   

   SGR 19-SEP-75 19:43  26515
   Negative Feelings about the Journal
   Location: (JOURNAL, JRNL29, J26515:gw)
   *****Note:  [ ACTION ] *****
   

      Comments: References (33496,)

      Message:

         Do you think it would be worthwhile forsomeone to contact Ron 
         Uhlig andtry to get his feelings on what makes the journal "a 
         pain in the neck to use"?  Or have you askedhim?  --Susan

   SGR 19-SEP-75 19:38  26514
   Dialog Support
   Location: (JOURNAL, JRNL29, J26514:gw)
   *****Note:  [ ACTION ] *****
   

      Message:

         Just a note on (33510,) - A definition of Dialog Support.  In 
         the third TNLS course we spend some describing the concepts 
         Journal and Dialog Support.  A suggestion made by Jim Bair as 
         to the content of this little discourse which I like goes as 
         follows:  Most professions have journals which are used to 
         support dialogue between geographically distributed 
         professionals.  Every group of people with a common interest 
         needs some method for "supporting" communications (dialogue), 
         therefore we have a "journal" to aid our communications 
         (support our dialogue).  It just dawned on me that this is an 
         analogy not a definition so it may not be of any real use to 
         you but since I've taken time to type it I'll go ahead and send
         it...

   RA3Y 19-SEP-75 12:23  33510
   A definition of Dialog Support
   Location: (JOURNAL, JRNL29, J33510:gw)
   *****Note: Author Copy*****
   

      Message:

              Has ARC developed a definition of Dialog Support?  If not,
         do you have suggestions for what that definition would contain.
         For work I am doing on the Journal conference 
         (Panko,transcript,1) I will be needing one.  The definition 
         should distinguish Dialog Support from computer mail systems 
         such as Sendmessage and DMS and also from dedicated computer 
         teleconferencing systems like FORUM, GCS, RIMS and CONFER.  
         Thanks, Gang.  RA3Y.

   JHB 19-OCT-75 10:37  33696
   Comment on 33680, Partial Summary of Sendmail Usage
   Location: (JOURNAL, JRNL30, J33696:gw)
   

      Comments: See -- 25451,)  for the Sendmail citation design , RLL

      Message:

         Its good to have some numbers to back up what we have known for
         over a year.   There has been enough input from users 
         concerning the use of Sendmail to serve as the basis of its 
         refinement.  More reinforcement for this refinement was 
         received at this past KWAC meeting.  I think some action is 
         inorder if can find the resources.  
         Just 2 refinements would improve Sendmail an order of 
         magnitude:
         1)  The redesign of the delivery citation as per RLL's 
         studyearlier this year ;
         2)  The implementation of  the Expedite command to allow users 
         the option of immediate delivery;
         I will look into improved training /documentation for Sendmail.
         Someone should look into the private use , which may be much 
         larger than expected.
         

   RA3Y 19-MAY-75 16:57  32549
   Teleconferencing and Computer Communication
   Location: (GJOURNAL, 32549, 1:w)
   *****Note: Author Copy*****
   

      Comment: Draft paper surveying computer teleconferencing and 
      genral computer-based human communications.

   RA3Y 18-SEP-75 08:15  33496
   How Ron Uhlig feels about Journal mail
   Location: (JOURNAL, JRNL29, J33496:gw)
   *****Note: Author Copy*****
   

      Message:

         18-SEP-75 0729-PDT  UHLIG at OFFICE-1:  RE YOUR 24 AUGUST 
         MESSAGE ON AMC USE STATISTICS
            Distribution:  PANKO, uhlig, vongehren, Message-ID: 
         <[OFFICE-1]18-SEP-75 07:29:31-PDT.UHLIG>
            Received at:   18-SEP-75 07:38:36-PDT

            SORRY I DIDN'T GET AROUND TO ANSWERING YOU BEFORE THIS.  I 
            WAS IN JAPAN WHEN YOUR MESSAGE CAME IN.  I HAVE BEEN BACK 
            FOR ABOUT TWO WEEKS, BUT WE AT AMC RARELY EVER LOOK IN THE 
            JOURNAL.  WE FIND IT A PAIN IN THE NECK TO USE, AND PREFER 
            SNDMSG, SO I JUST FOUND YOUR MSG TODAY AS I TOOK MY MONTHLY 
            LOOK IN THE JOURNAL MAIL.

            RON

   17-OCT-74 0755-PDT  BAIR at OFFICE-1:  Journal citation format
      Distribution:  KELLEY AT SRI-ARC, engelbart at sri-arc, norton at 
   sri-arc, watson at sri-arc,, lieberman at sri-arc, bair at sri-arc
      Received at:   17-OCT-74 07:56:01

      Dear Kirk,  I understand (second hand) that you are in charge of 
      the design of a new Journal citation format.  In that case, I 
      would like to cast my vote for the following (coordinated with 
      RLL):
      DATE SENT (ONLY) AUTHOR(S) JNUMBER TITLE <CR>
         Received:  Time and date;   Sent:  Time<CR>
         TO:  Idents of recipients for action<CR>
         CC:  Idents of recipients for info<CR>
         Link or message
            <new satements>comments.

      This would permit a sort on meaningful fields, date and author 
      ident, and would fit enough of the title on the first line for 
      informative 1 line 1 level perusal.  I think this is consistent 
      with what most Utility clients want.
         Thank you, Jim

   KIRK 17-NOV-74 01:52  24530journal citations
   Good and Bad NLS practice reflected in your proposed sendail citation
   Location: (GJOURNAL, 24530, 1:w)
   *****Note:  [ ACTION ] *****
   

   FEED 16-SEP-75 11:56  33492
   Change in Send Message Command, Message Subsystem
   Location: (JOURNAL, JRNL29, J33492:gw)
   

      Message:

         Dean Meyer has changed the MESSAGE Subsystem so that it is 
         compatible with MSG.  It no longer puts the authors ident after
         the directory name.  It lists the distribution list as sndmsg 
         would, no longer listing the ident first, then the network 
         address in parens.  The change has been made at Office-1, BBNB,
         and ISIC.

   16-OCT-74 1353-PDT  LIEBERMAN:  New journal header: decision by Thurs
   due.
      Distribution:  BAIR, BAIR AT OFFICE-1, lieberman
      Received at:   16-OCT-74 13:53:15

      Jim, Kirk needs a decision on what form to use on the new journal 
      header.  Norton is "too busy to worry about it".  Kirk's words are
      hat whatever you decide goes.  If no wod is received from you then
      Kirk may decide to go with jform3 (currently used by the message 
      subsystem.).
      I wwld like to enter my suggstions.  If you like I will make sure 
      Kirk knows what aapplications' sentiments are andthat he follows 
      them.  Let me know your decison.
      The items to be included ssould be
       author, journal number, title, distribution list, time and date 
      sent, time and date received.
      the  distribtion list prhaps ssould be split between TO and CC 
      categories.
      The  format I suggest is:
       author Jnumber Title <CR>
      <sp><sp><sp> Sent: time date  Received: time date<cr>
      <sp><sp><sp> TO : names of people sent as fr action<CR>
      <sp><sp><sp> CC: names of thos sent for information<CR>
      <sp><sp><sp> Fuull citation with journal dretory).
      The major difference is probably te positioning of time nd date on
      second line.  Lets discuss it if you like. Rob

   DVN 15-SEP-75 18:33  26472
   Command Words for Readmail
   Location: (JOURNAL, JRNL29, J26472:gw)
   *****Note:  [ ACTION ] *****
   

      Comments: Comment on 26464.

      Message:

         In general I like the Readmail design.  It would be nice to 
         keep the verbal quality in initial NLS command words.  Howabout
         "Scan" for "Brief" and  "File" for "Catagory".

   JAKE 15-OCT-75 17:15  26681
   The trouble with SENDMAIL
   Location: (IJOURNAL,26681,1:w)
   *****Note: 
   (Secondary Distribution Copy from RA3Y)*****
   

   RA3Y 15-MAY-75 16:15  32519
   Contact Report: Bert Liffman
   Location: (GJOURNAL, 32519, 1:w)
   *****Note: Author Copy*****
   

      Comments: This contact report was made for the SRI 
      teleconferencing project.  It details use of General Conferencing 
      Systems Ltd.'s computer teleconferencing system by the Nonmedical 
      Drugs Directorate of the Canadian Federal Government.  Cost 
      figures are included.

   RA3Y 14-OCT-75 12:57  33682
   Traffic statistics for public Journal mail, Jan-Jun 1975
   Location: (IJOURNAL, 33682, 1:w)
   *****Note: Author Copy*****
   

   RA3Y 14-OCT-75 12:55  33680
   Summary of a Study of Public Journal Mail Traffic in a Six-Month 
   Period
   Location: (IJOURNAL, 33680, 1:w)
   *****Note: Author Copy*****
   

      Comments: Transmission rates for NLS users in ARC and outside ARC 
      are noted.  Compared to the one other user community employing a 
      computer-based message system that monitors traffice, Journal mail
      usage seems quite low.  It is suggested that this matter be 
      considered further.

   RA3Y 14-NOV-75 09:18  33902
   The MSGIRS Computer-based Communication System at MIT
   Location: (JOURNAL, JRNL31, J33902:gw)
   *****Note: Author Copy*****
   

      Message:

         Al Vezza (AV) of MIT's Project MAC, has produced a computer 
         message service called MSGIRS as a part of Project MAC's 
         Dynamic Modeling System.
         
         The MSG denotes the message part of the system.  The IRS 
         denotes that the system has retrieval features, so that a user 
         can retrieve his or her messages by author, date, recipients, 
         title word and other special fields of a message.
         
         In MSGIRS, not only can people communicate with one another, 
         but software processes can also send messages to people and to 
         one another, and users can send messages to processes through 
         MSGIRS.
         
         MSGIRS is now used at USC-ISI, as well as in the DMS.

   13-JAN-75 1737-PDT  FEEDBACK:  Journal citation reformatting
      Distribution:  BEDFORD, lieberman, feedback
      Received at:   13-JAN-75 17:37:11

      Mike, Great idea...in fact, we have been designing a new format 
      with just exactly that as well as many other changes in mind.  Any
      other ideas on how you would like it to look?   Should be being 
      implemented within a month....    The  issue paper is authored by 
      Lieberman...see journal index from jul - dec 74 under that author 
      name.   Jim/feed

   DVN 13-APR-73 08:58  15931
   The Journal is One Kind of Dialog Support
   Location: (JOURNAL,JRNL9,J15931:w)
   *****Note: 
   (Secondary Distribution Copy from DVN)*****
   

      Message:

         The Journal is a subsetof the Dialog Support System. Shared 
         images, for example are, another dialog support system within 
         nls. But because the journal has been far and away the most 
         prominent system, people have often confused the part with the 
         whole; that is sloppy use of language.

   RA3Y 12-SEP-75 08:06  33473
   Using Keywords
   Location: (JOURNAL, JRNL29, J33473:gw)
   *****Note: Author Copy*****
   

      Comments: For the Journal conference

      Message:

              In your comments to the Journal conference (JOURNAL, 
         JRNL29, J33459:gw), please include one or more of the following
         keywords.  This will help readers browse through the conference
         record.

            Userware: Pertaining to what the user sees, especially 
            commands and subsystems like Sendmail, Readmail, 
            Teleconference, and Identification

            Systemware: Pertaining to things the user does not see, 
            especially the inner workings of the Journal system
            
            Philosophy: Philosophical comments about Dialog Support 
            Systems

            Procedural: Procedural comment about the conference

            Exhibit: to denote a substantive document

   RA3Y 12-SEP-75 07:00  33472
   Citation Format Suggestion: Show Number of Pages
   Location: (JOURNAL, JRNL29, J33472:gw)
   *****Note: Author Copy*****
   

      Message:

         I would like to suggest that, in future journal citation 
         formats, the number of pages in the submission be listed.  This
         help users in deciding whether or not to print a citation.

   RA3Y 12-SEP-75 07:00  33472
   Citation Format Suggestion: Show Number of Pages
   Location: (JOURNAL, JRNL29, J33472:gw)
   *****Note: Author Copy*****
   

      Message:

         I would like to suggest that, in future journal citation 
         formats, the number of pages in the submission be listed.  This
         help users in deciding whether or not to print a citation.

   RA3Y 12-NOV-75 17:25  33890
   Request for Information on Journal/Sendmail/Dialog Support 
   Information
   Location: (JOURNAL, JRNL31, J33890:gw)
   *****Note: Author Copy*****
   

      Message:

         Sandy,  Is it possible for me to get a list of messages 
         suggesting changes, improvements or fixes that have been 
         submitted to Feedback concerning our communication facilities? 
         If you have a branch of a file that will turn the trick, that 
         would be fine.  But don't work too hard at this.

    7-OCT-75 1027-PDT  STEFFERUD at USC-ISI:  MsgGroup Procedure 
   Evaluation
      Distribution:  [ISI]<MSGGROUP>MAILING.LIST:, stefferud
      Received at:   7-OCT-75 10:50:29-PDT

      I have been trying to assess the effectiveness of our MsgGroup
      Procedures, especially those concerned with the distribution of
      long messages.

      I fear that the present provcedure results in non-reading of long 
      messages because they are not handy and it is easy to put off 
      accessing them for printout.  I am particularly concerned about 
      those members who are not colocated with <MsgGroup> at ISIA.

      To help me with my assessment, please let me know by brief return 
      message what you think of the procedures.

      MsgGroup seems to be cutting new ground in that it uses ordinary 
      message systems to conduct a teleconference.  It is not clear 
      whether it is best to send out long messages which can be safely 
      discarded because there exists a "journal" which holds a master 
      backup copy, or whether it is best to sned out citations and let 
      each member take deliberate action to "get" a copy for reading.

      Comments anyone?   Stef

    7-JAN-75 2247-PST  LIEBERMAN:  New Journal citation
      Distribution:  ENGELBART, norton, lieberman
      Received at:   7-JAN-75 22:47:33

      Doug: I would like to talk to you about the new joonal citation 
      that will be delivered via the sendmail/journal system.
      I have a file called <lieberman,headers,> that contains the 
      comments, discussions, etc. on this subject.  Sometime next week I
      hope applications will meet to decide the format.  (JCN how does 
      that go with you??)  A meeting with you (DCE) before this I think 
      would be appropriate.  Robert

    5-JAN-75 0951-PST  BAIR:  Journal citation meeting
      Distribution:  LIEBERMAN, bair
      Received at:   5-JAN-75 09:51:30

      Rob, How about Weds morning if there are no conflicts?
      How does it feel to be back?   See ya, Jim

REFERENCES

   * indicates that references were brought online for the conference 
   (Well, we have asked Tymshare to bring them online, anyway).

   *(MULTI-HOST)Description of a Multi-Host Journal System              
   26135   MULTI-HOST        
      (23144,1:wznC)

   *(TEAM INTERACTION)Online Team Environment / Network Information 
   Center and Computer Augmented Team Interaction                       
   26135   TEAM INTERACTION        
      (13041,1:wznC)

      WARNING: Over 200 pages

   *(JOURNAL)NLS TELECONFERENCING FEATURES: THE JOURNAL, AND 
   SHARED-SCREEN TELEPHONING                       33076   JOURNAL      
      (33076,1:wznC)

   (DIALOG)First Half July Message Group Dialog                         
   26135   Dialog        
      (26135,1:wznC)

   (JOURNAL)Journal mail - Fourth Quarter 1974                          
   10 Jan 75   31617   Journal       
      (31617,1:wznC)

   (JOURNAL)Journal Mail - Third Quarter 1974                           
   10 Jan 75   31616   Journal       
      (31616,1:wznC)

   (JOURNAL)Status of Suggestions Regarding Network Journal Delivery    
   9 Jan 75   31606   Journal       
      (31606,1:wznC)

   (JOURNAL)Journal Citations vs. ARPA Network Standards                
   24 Feb 75   25453   Journal       
      (25453,1:wznC)

   (JOURNAL)A Simple Commands Branch to Reject Journal Mail on Specific 
   Subjects                 9 Jan 75   25042   Journal       
      (25042,1:wznC)

   (JOURNAL)Hardcopy Journal                                            
   30 Jan 75   25254   Journal       
      (25254,1:wznC)

   (JOURNAL)Comments on the 'final' journal citation                    
   24 Feb 75   25452   journal       
      (25452,1:wznC)

   (DIALOG)Some Recent Dialog among  the Message Service Committee      
   32806   Dialog        
      (32806,1:wznC)

   (DIALOG)Recent Message Committee Dialog for Week through June 27     
   27 Jun 75   32840   Dialog        
      (32840,1:wznC)

   (JOURNAL)Journal Mail - Second quarter 1974                          
   23 Jul 74   30938   Journal       
      (30938,1:wznC)

   *(JOURNAL)Network Journal Distribution                               
   2 Dec 74   24647   Journal       
      (24647,1:wznC)

   *(JOURNAL)NETWORK JOURNAL DELVERY                                    
   2 Dec 74   24646   JOURNAL       
      (24646,1:wznC)

   (JOURNAL)Network Journal Delivery                                    
   24645   Journal       
      (24645,1:wznC)

   (JOURNAL)Journal citation dialogue: second go around; two 
   alternatives; call for a                  37   24828   Journal       
      (24828,1:wznC)

   *(JOURNAL)how to getwnls to print only the changed journal mail 
   insteed of everything          12 Aug 74   23759   journal       
      (23759,1:wznC)

   (JOURNAL)Bug in journal citations                                    
   26 Sep 74   24069   journal       
      (24069,1:wznC)

   *(JOURNAL)NEW NLS Journal Delivery                                   
   26 Sep 74   24067   Journal       
      (24067,1:wznC)

   (JOURNAL)Output Journal bug                                          
   19 Sep 74   24006   Journal       
      (24006,1:wznC)

   (JOURNAL)Journal Indices                                             
   19 Sep 74   23994   Journal       
      (23994,1:wznC)

   (JOURNAL)Journal Confounds Bugs with Dreams                          
   24172   Journal       
      (24172,1:wznC)

   (JOURNAL)BUG:journal system. pushing its way in.                     
   3 Oct 74   24157   journal       
      (24157,1:wznC)

   (JOURNAL)SUBMISSION OF JOURNAL FROM THE NETWORK                      
   13 Oct 74   24210   JOURNAL       
      (24210,1:wznC)

   (JOURNAL)For A user otion to Turn off Journal notification           
   23 Oct 74   24269   Journal       
      (24269,1:wznC)

   (JOURNAL)Comment on Functional Documents & Journal Numbers           
   28 Oct 74   24341   Journal       
      (24341,1:wznC)

   *(JOURNAL)journal citations again                                    
   28 Oct 74   24337   journal       
      (24337,1:wznC)

   (JOURNAL)Opinion on Journal Citation Delivery Format                 
   24336   Journal       
      (24336,1:wznC)

   (JOURNAL)Functional Documents and Journal Numbers                    
   24325   Journal       
      (24325,1:wznC)

   (JOURNAL)Journal Citation Recomendations                             
   25 Oct 74   24324   Journal       
      (24324,1:wznC)

   (JOURNAL)More On Journal Citations                                   
   93   24318   Journal       
      (24318,1:wznC)

   (JOURNAL)journal citations revisited                                 
   24315   journal       
      (24315,1:wznC)

   *(JOURNAL)journal headers                                            
   24 Oct 74   24294   journal       
      (24294,1:wznC)

   *(JOURNAL)re J24269:  Journal notification & info/action branches    
   24 Oct 74   24291   Journal       
      (24291,1:wznC)

   (JOURNAL)Additional Thought on Input of Messages to the Journal      
   5 Nov 74   24411   Journal       
      (24411,1:wznC)

   *(JOURNAL)SUMMARY OF ARC JOURNAL                                     
   24621   JOURNAL       
      (24621,1:wznC)

   (JOURNAL)One More thought about Journal Deliveryy                    
   7 Nov 74   24437   Journal       
      (24437,1:wznC)

   *(JOURNAL)ARC Journal: ROUGH DRAFT of Report Chapter                 
   8 Nov 74   24448   Journal       
      (24448,1:wznC)

   *(DIALOG)ARC Dialog Support: ROUGH DRAFT for a Report Chapter        
   8 Nov 74   24450   Dialog        
      (24450,1:wznC)

   (DIALOGUE)Journal citation dialogue: second go around; two 
   alternatives; call for a                  37   24828   dialogue      
      (24828,1:wznC)

   (DIALOGUE)Kudlick's Jul 74 notes re. NIC Experience with Dialogue 
   Support                     13 Dec 74   24755   Dialogue      
      (24755,1:wznC)

   (DIALOGUE)My Thoughts about Recording Written Dialogue               
   24431   Dialogue      
      (24431,1:wznC)

   (DIALOGUE)My thoughts about recording dialogue                       
   24430   dialogue      
      (24430,1:wznC)

   (DIALOGUE)Recording our written dialogue                             
   3 Nov 74   24393   dialogue      
      (24393,1:wznC)

   (DIALOG)Collection of Dialog on a Maling list Superintendent         
   16 Sep 74   23976   Dialog        
      (23976,1:wznC)

   (JOURNAL)Journal mail -Last quarter 1973                             
   6 Feb 74   30059   Journal       
      (30059,1:wznC)

   (JOURNAL)On-line only Delivery of Journal Documents                  
   6 Feb 74   30052   Journal       
      (30052,1:wznC)

   (JOURNAL)Submitting Documents to the Journal                         
   23 Jan 74   30002   Journal       
      (30002,1:wznC)

   *(JOURNAL)Journal SUBCOLLECTIONS command                             
   31 May 74   23174   Journal       
      (23174,1:wznC)

   (JOURNAL)Network Journal Submission                                  
   1 May 74   22879   Journal       
      (22879,1:wznC)

   (JOURNAL)Journal Citations Reformatting Program                      
   29 Apr 74   22853   Journal       
      (22853,1:wznC)

   (JOURNAL)some comments on the dual-journal system                    
   9 Apr 74   22673   journal       
      (22673,1:wznC)

   (JOURNAL)Response to (22598,) - On Journal Statistics                
   4 Apr 74   22625   Journal       
      (22625,1:wznC)

   (JOURNAL)Comments on Journal Statistics                              
   2 Apr 74   22598   Journal       
      (22598,1:wznC)

   (JOURNAL)Yummy, Yummy!  Journal Statistics are Neat!!!               
   1 Apr 74   22594   Journal       
      (22594,1:wznC)

   *(JOURNAL)Preliminary Mapping of Journal Use for One Subject         
   1 Apr 74   22549   Journal       
      (22549,1:wznC)

   *(JOURNAL)Assorted Journal Statistics                                
   1 Apr 74   22547   Journal       
      (22547,1:wznC)

   (JOURNAL)The journal hardcopy command.                               
   28 Mar 74   22521   journal       
      (22521,1:wznC)

   *(JOURNAL)SCENARIO FOR USING THE NETWORK JOURNAL                     
   27 Mar 74   22507   JOURNAL       
      (22507,1:wznC)

   (JOURNAL)on-line journal indexes and other on-line files             
   20 Mar 74   22426   journal       
      (22426,1:wznC)

   *(JOURNAL)Estimated Manpower Required to Implement the Multi-Host 
   Journal System              14 Mar 74   22406   Journal       
      (22406,1:wznC)

   (JOURNAL)Journal delivery, hardcopy vs online                        
   4 Feb 74   21787   Journal       
      (21787,1:wznC)

   (JOURNAL)Scenarios for Sending to, and Retrieving From, Network 
   Journal                      30 Jan 74   21689   Journal       
      (21689,1:wznC)

   (JOURNAL)Sample of Network Journal Through FTP                       
   30 Jan 74   21682   Journal       
      (21682,1:wznC)

   (JOURNAL)Sample of Mail Sent Through TELNET to the Network Journal   
   30 Jan 74   21681   Journal       
      (21681,1:wznC)

   (JOURNAL)Immediately Relevant Suggestions for the Journal System     
   23 Jan 74   21595   Journal       
      (21595,1:wznC)

   (JOURNAL)Journal and the Utility, some feedback.                     
   23 Jan 74   21594   Journal       
      (21594,1:wznC)

   (JOURNAL)journal mail fourth quarter 1973                            
   21 Jan 74   21539   journal       
      (21539,1:wznC)

   (JOURNAL)journal mail fourth quarter 1973                            
   21 Jan 74   21538   journal       
      (21538,1:wznC)

   (JOURNAL)Comments on proposed NIC identfile and journal changes      
   16 Jan 74   21443   journal       
      (21443,1:wznC)

   (JOURNAL)Request for Means to Send Journal Items to Online Addressees
   Only                    4 Jan 74   21294   Journal       
      (21294,1:wznC)

   (DIALOG)Dialog Support Ideas Solicited                               
   8 Jan 74   21332   Dialog        
      (21332,1:wznC)

   (DIALOG)Additional Comment on Your Proposal for Private Journal 
   Dialog                      29 Nov 73   20624   Dialog        
      (20624,1:wznC)

   (DIALOG)Reply to Jim White's Private Journal Dialog Proposal         
   28 Nov 73   20601   Dialog        
      (20601,1:wznC)

   *(JOURNAL)DSS: New Journal Features under Consideration              
   27 Dec 73   21224   Journal       
      (21224,1:wznC)

   (JOURNAL)Thoughts on Possible Exec-Level Journal Commands            
   31 Jan 73   20933   Journal       
      (20933,1:wznC)

   (JOURNAL)re JEW's 20543 Journal Privacy Proposal                     
   6 Dec 73   20750   Journal       
      (20750,1:wznC)

   (JOURNAL)Additional Comment on Your Proposal for Private Journal 
   Dialog                      29 Nov 73   20624   Journal       
      (20624,1:wznC)

   (JOURNAL)Reply to Jim White's Private Journal Dialog Proposal        
   28 Nov 73   20601   Journal       
      (20601,1:wznC)

   *(JOURNAL)A Just-About-Final Journal Privacy Proposal                
   26 Nov 73   20543   Journal       
      (20543,1:wznC)

   (JOURNAL)Suggestion for Change in Journal Hardcopy Format            
   25 Nov 73   20492   Journal       
      (20492,1:wznC)

   (JOURNAL)Agreement that SNDMSG and Journal Should be more Closely 
   Coupled                    20 Nov 73   20392   Journal       
      (20392,1:wznC)

   (JOURNAL)Journal Distribution: Two Additions to be Implemented       
   19 Nov 73   20380   Journal       
      (20380,1:wznC)

   (JOURNAL)Some answers to queries about the journal (20362,)          
   19 Nov 73   20371   journal       
      (20371,1:wznC)

   (JOURNAL)Regarding your Ident system and Journal Subcollection 
   questions                     12 Nov 73   20178   Journal       
      (20178,1:wznC)

   (JOURNAL)Suggestion for Initial File Journal Item Indexing           
   4 Nov 73   20037   Journal       
      (20037,1:wznC)

   *(JOURNAL)What to do When Interogate Tells you a Journal File is Not 
   On Line (reply to         2 Nov 73   20013   Journal       
      (20013,1:wznC)

   *(JOURNAL)Output Journal Mail Command                                
   1 Oct 73   19401   Journal       
      (19401,1:wznC)

   (JOURNAL)Test of Sndmsg vs. the Journal                              
   26 Sep 73   19309   Journal       
      (19309,1:wznC)

   (JOURNAL)A Comment on Journal Privacy                                
   13 Sep 73   19053   Journal       
      (19053,1:wznC)

   (JOURNAL)Questions About Private-Journal Catalogs and Speed of 
   Proposed Implementation       11 Sep 73   18982   Journal       
      (18982,1:wznC)

   (JOURNAL)Response to 18069: Attaching Comments to a Journal Item     
   31 Jul 73   18145   Journal       
      (18145,1:wznC)

   (JOURNAL)On Journal-item Citation Naming; cf. (18011,), (18036,) and 
   (18063,)                31 Jul 73   18132   Journal       
      (18132,1:wznC)

   (JOURNAL)Answers to Questions About Net Journal Submission & Delivery
   20 Jul 73   17964   Journal       
      (17964,1:wznC)

   (JOURNAL)a sample journal message                                    
   18 Jul 73   17857   journal       
      (17857,1:wznC)

   (JOURNAL)a sample journal session                                    
   18 Jul 73   17856   journal       
      (17856,1:wznC)

   (JOURNAL)NWG/RFC 543: Network Journal Submission and Delivery        
   16 Jul 73   17777   Journal       
      (17777,1:wznC)

   *(JOURNAL)L10 Program to Tabulate Modes of Journal Delivery          
   11 Jul 73   17746   Journal       
      (17746,1:wznC)

   (JOURNAL)Network Journal Mail                                        
   3 Jul 73   17628   Journal       
      (17628,1:wznC)

   (JOURNAL)What to do If Your Journal Branch Is Destroyed              
   2 Jul 73   17613   Journal       
      (17613,1:wznC)

   (JUL)Journal Items received from Oct 72-Jul 73                       
   8 Nov 73   20118   Jul           
      (20118,1:wznC)

   *(DIALOG)Summary of Dialog on Journal Headers                        
   7 May 73   16322   Dialog        
      (16322,1:wznC)

   (DIALOG)Privacy in Journal Dialog -- Initial Thoughts                
   23 Apr 73   16052   Dialog        
      (16052,1:wznC)

   *(DIALOG)The Journal is One Kind of Dialog Support                   
   13 Apr 73   15931   Dialog        
      (15931,1:wznC)

   *(DIALOG)Question about Journal vs Dialog Support                    
   12 Apr 73   15756   Dialog        
      (15756,1:wznC)

   (DIALOG)Dialog-Supported Debugging System                            
   15 Mar 73   15101   Dialog        
      (15101,1:wznC)

   (ARC)* ARC JOURNAL INDEX BY TITLEWORD (PDP-10 entries only) to 28 JAN
   72              2 Feb 72   8715    ARC                 
                    To: 
      ( 8715,1:wznC)

   (ARC)* ARC JOURNAL INDEX BY AUTHOR (PDP-10 entries only) to 28 JAN 72
   31 Jan 72   8714    ARC                 
                    To: 
      ( 8714,1:wznC)

   (ARC)* ARC JOURNAL INDEX BY NUMBER (PDP-10 entries only) to 28 JAN 72
   31 Jan 72   8713    ARC                 
                    To: 
      ( 8713,1:wznC)

   (ARC)* New ARC Journal Entries - Since 10 JAN 72 (issue              
   28 Jan 72   8696    ARC                 
                    To: 
      ( 8696,1:wznC)

   (Availability)* Reply to AAM on Status of Journal Availability       
   23 Mar 72   9607    Availability        
                    To: AAM RWW WSD JDH NICSTA 
      ( 9607,1:wznC)

   (Background)* Program for determining proper startup of Journal 
   Background Process           7 Feb 72   8799    Background          
                    To: WRF JDH RWW JCN DCW KEV 
      ( 8799,1:wznC)

   (Bugs) Some Journal Bugs and Glitches                                
   22 Nov 71   8110    Bugs                
                    To: WSD JDH 
      ( 8110,1:wznC)

   *(Catalog) Proposed New Journal Submission Features - Pre-specified 
   Catalog Data         27 Jan 72   8672    Catalog             
                    To: WSD DCE CHI 
      ( 8672,1:wznC)

   (Catalog)* A Recommended Set of Conversion Conventions from the 
   Journal Catalog to the   27 Aug 71   7614    Catalog             
                    To: WSD WLB JBN JCN (Jim this set of conventions is 
   more complete than a previous set you wsd and jbn had discussed) 
      ( 7614,1:wznC)

   (changes)* Proposed journal changes and the new file system          
   11 Jan 72   8425    changes             
                    To: JDH WSD WHP 
      ( 8425,1:wznC)

   (Changes)* Proposed Journal Changes                                  
   7 Jan 72   8405    Changes             
                    To: NPG JCN RWW 
      ( 8405,1:wznC)



10-MAY-78 22:11:28-PDT,1515;000000000001   
Mail from OFFICE-1 rcvd at 1-DEC-75 2027-PST
Date:  1 DEC 1975 2028-PST
From: PANKO at OFFICE-1
Subject: MSGGROUP# 216 Standards and Lack of Standards in Message Headers
To:   [ISI]<MsgGroup>Mailing.List:

Steff asked why some systems have standard ways to handle message formats while others do not, and why innocent bystanders get caught in the crunch.  In reply, let me just note that There is No Justice.

While I feel sorry for Stef, I feel that there are some cogent reasons why NLS should not adhere to the standard RFC on message formats.  The first reason is that NLS came along a lot earlier and developed a standard that ARCers liked.  That alone would not be sufficient.  But the second reason is sufficient: NLS is not an ARPA Net service.  It was designed for a larger community of users, and it is beginning to exploit that community.  So NLS must design its headers for beauty (to the eyes of certain beholders).  Let me cast a vote for message handling systems that accept nonstandard items.

Frankly, I think that the NLS header is pretty lousy, but the standard sendmessag header is pretty clogged up, too.  May I suggest an ultimate design criteria by which new headers can be judged?  I nominate Beauty.  Functionality, I feel, can be achieved in numerous ways.  Only some of those ways are beautiful.

By the way, I have recently left the Augmentation Research Center, to return to SRI's Telecommunication Sciences Center, where I was before joining ARC early this year.
-------
10-MAY-78 22:11:29-PDT,1640;000000000001   
Mail from USC-ISI rcvd at 2-DEC-75 0922-PST
Date:  2 DEC 1975 0853-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 217 Example of NLS Sendmail Message
To:   [ISI]<MsgGroup>Mailing.List:
cc:   AV at MIT-DMS, Farber at USC-ISI, Broos at USC-ISI,
cc:   DCROCKER at USC-ISI, SLESINGER at BBN-TENEX,
cc:   UHLIG at OFFICE-1, AMC at USC-ISI, Stefferud at USC-ISI,
cc:   WALKER at USC-ISI, LIPNER at USC-ISI

   1   Mail from OFFICE-1 rcvd at 2-DEC-75 0825-PST
   2   Mail from USC-ISI rcvd at 2-DEC-75 0833-PST


1 -- ************************
Mail from OFFICE-1 rcvd at 2-DEC-75 0825-PST
FTPMAILWORK.RA3Y;1



2 -- ************************
Mail from USC-ISI rcvd at 2-DEC-75 0833-PST
Forwarded-By: STEFFERUD
Forwarded-To: stefFERUD
Message-Id: <[FAKE]-1-((75 12 2) (8 26 49) "PST").STEFFERUD>

--------
Hi MsgGroupers,

Here is an example of the beauty of NLS Sendmail Journal Citations sent via
SNDMSG, for your enjoyment and appreciation.

Message no. 1 is the MSG typeout of what I received.

Message No. 2 is the same message after receipt by MSGDMS and forwaring
to myself from DMS to MSG.  As you will note, DMS has trown the envelope 
away.

Please correct me if I am wrong.  RFC 680 calls for a <CR><LF><CR><LF>
between the header and the text of any message.  If NLS would only put
the <CR><LF><CR><LF> in front of the citation, then DMS wold not think it 
was a non-standard envelope, and would properly keep the text, and
throw away the empty envelope.

It further seems to me that NLS can be modified to do this in 15
minutes or less of programmer time.

Comments,    Stef
-------
10-MAY-78 22:11:29-PDT,779;000000000001
Mail from USC-ISI rcvd at 2-DEC-75 1800-PST
Date:  2 DEC 1975 1746-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 218 MsgGroup Situation Report: PREFACE
To:   [ISI]<MsgGroup>Mailing.List:

I have finally gotten a handle on how to prepare a Situation
Report for the MsgGroup to document the situation in terms of the
issues.  

In order to deliver it to you in small enough pieces to make it
readable as you go, I am going to send it in approximate one page
segments over several days.  The first page discusses the
BACKGROUND of the situation.  Subsequent sections will deal with
THE CURRENT SITUATION, THE ISSUE MATRIX, and THE ISSUES.  

Hopefully I will have most of it to you by next week.  

See you in the discussion.  

Best regrds, Stef 
-------
10-MAY-78 22:11:29-PDT,3059;000000000001    
Mail from USC-ISI rcvd at 2-DEC-75 2352-PST
Date:  2 DEC 1975 2342-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 219 MsgGroup Situation Report #1: I. BACKGROUND
To:   [ISI]<MsgGroup>Mailing.List:


MSGGROUP SITUATION REPORT NUMBER ONE .  .  .  .  .  .  .  Page 1 

NOVEMBER 18, 1975 

PREPARED BY EINAR STEFFERUD, NETWORK MANAGEMENT ASSOCIATES, Inc.

FOR MSGGROUP 


I.  BACKGROUND 

The purpose of MsgGroup is to hold an informal teleconference on
the subject of message systems, as they might be, as they should
be, and how we might build them out of what we have in hand.  

Message systems have grown up in the ARPANET community in response
to both the need and capability to exchange text messages among
various directories in HOST computers throughout the ARPANET.  

Until recently message systems were spontaneous developments
without formal sponsorship from any agency.  They were strictly a
natural phenomenon of technological advance.  

Experience with the early message systems led to the conclusion
that computer network message system interaction represents a
valuable development with great potential for application in many
domains.  Thus, message systems have come to enjoy formal
sponsorship in the last year or so, with the effort gaining new
momentum with time.  

As part of this formal sponsorship, a Message Service Committee
was formed in 1974 and it has published RFC 680 to specify formats
and protocols for message transmission and processing in the
ARPANET.  The Message Service Committee is currrently developing a
new specification to address the need for a more structured
approach to message systems in ARPANET.  This effort focuses on
the more technical aspects of message transmission as compared to
determination of the proper user interface.  When their report is
ready, it will be distributed to MsgGroup.  

In 1975, it was recognized that the user interface is a vital
aspect of message systems and MsgGroup was formed, more or less
spontaneously and informally, to discuss the issues.  

It is now clear that great potentialities exist for computer
mediated interaction, but it is equally clear that we have not yet
realized these potentials, and it is clear that we are not exactly
certain as to how to proceed to capture them in the most
reasonable way.  

Among the uncertainties are the problems of economics which are
difficult to face in the ARPANET environment.  We are still at
that stage of the development of the concepts where the service
must be provided in a heavily subsidized mode.  This is justified
on the basis that costs will surely decrease with time to the
point where such message systems will become economic in one form
or another.  

This Situation Report attempts to delineate the issues that are
before the MsgGroup in order to facilitate discussion.  In
MsgGroup# 137, an issue matrix was proposed.  Since there has been
no objection to it, this matrix will be used as the basic
framework.  

_ _ _ _ _ _
-------
10-MAY-78 22:11:29-PDT,3339;000000000001    
Mail from USC-ISI rcvd at 4-DEC-75 0000-PST
Date:  3 DEC 1975 2353-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 220 MsgGroup Situatation Report #1: CURRENT SITUATION
To:   [ISI]<MsgGroup>Mailing.List:


MSGGROUP SITUATION REPORT NUMBER ONE .  .  .  .  .  .  .  Page 2 


II.  CURRENT MSGGROUP SITUATION 

At this time, a number of message creation, sending, receiving,
and processing systems are available, which have evolved from
different perspectives to meet different perceived needs of
different communities of interest.  These systems offer a wide
variety of capabilities and styles of use, and it should be no
surprise that these systems present us with some incompatibilities
when we try to interact through unmatched send/receive pairs.  

Some of these incompatibility problems are being dealt with in the
Message Service Committee consideration of a "Structured Message
Transmission" concept.  Unfortunately, a new RFC will not
necessarily cause each implementer to adhere to the standard.
Current experience with RFC 680 shows that we should not expect
simple release of a new RFC to invoke adherence to it.  Some
additional discipline is needed to induce compliance.  

Some users see the current situation as unfortunate chaos, while
others see it as a natural and healthy result of uncoordinated
initial growth which yields a rich array of ideas for
incorporation into future message systems.  Some see the multiple
efforts as simply competitive, while others see them as
differentiated efforts to satisfy different communities of
interest.  Among the things that seem clear from the MsgGroup
dialogue to date, is the notion that there is no such thing as
"The Message System for All Users." 

Recent discussions have lead to the conclusion that the ideal
system is one that can be tailored to become what ever the user
may want, with a graduated set of sophistication levels to match
the user's growing capability to exploit the message system and
the natural propensity to want more power as the user progresses.  

The essence of the tailorable systems concept is to facilitate
user adaptation to meet specific taste and style of use
requirements.  The primary constraint on the concept is that
tailorability is probably expensive, both in terms of the system
design and implementation and in terms of the effort required of
the user to understand and accomplish the tailoring job.  

To summarize, the current MsgGroup situation is characterized by a
number of separate development groups which are avidly
implementing message systems for use in the ARPANET environment,
with minimal cross talk between groups.  Each group is dedicated
to meeting the user interface requirements of some subgroups of
the total potential user community.  

MsgGroup provides a public forum for intergroup discussions with
the level of interaction tending to flow in response to the
release of new versions of the implemented systems.  

Attempts have been made to stimulate discussion through release of
design plans in advance of implemented releases, and the results
have been positive and useful, but not nearly as spectacular as
those stimulated by actual release of new system versions.  There
have not been any recent releases.  




_ _ _ _ _ _
-------
10-MAY-78 22:11:29-PDT,467;000000000001  
Mail from BBN-TENEXA rcvd at 5-DEC-75 1316-PST
Date: 5 DEC 1975 1604-EST
Sender: FITZPATRICK at BBN-TENEXA
Subject: MSGGROUP# 221 NLS Sendmail Description
From: Myer
To: MsgGroup at ISI
Cc: FITZPATRICK   
Message-ID: <[BBN-TENEXA]5-DEC-75 16:04:48-EST.FITZPATRICK>    



Please  send  me  a  copy  of  MSGGROUP#  187 NLS Sendmail Sample
Session I and also a copy of MSGGROUP# 188  NLS  Sendmail  Sample
Session II.

Thank you.

/Ted Myer
------- 
10-MAY-78 22:11:30-PDT,899;000000000001
Mail from USC-ISI rcvd at 5-DEC-75 1603-PST
Date: 5 DEC 1975 1554-PST
Sender: FARBER at USC-ISI
Subject: MSGGROUP# 222 New MSGGROUP Mailing List.. Please check and update
From: FARBER at USC-ISI
To: [ISI]<MsgGroup>Mailing.List:
Message-ID: <[USC-ISI]5-DEC-75 15:54:18-PST.FARBER>


[ISI]<MsgGroup>Mailing.List:
@BBN,Heitmeyer, Gilbert, NGoodwin, 
@BBNA,Henderson, Burchfiel, Mooers, Myer, 
@BBNB, Feinler, Watson, 
@CCA, Tom, 
@I4-TENEX, Pirtle, 
@ISI, MsgGroup, PBaran, DCrocker, Farber, Iseli, Kirstein, 
      Mclindon, Spivey, Stefferud, Tasker, Walker, 
@ISIB,Broos,Oestreicher, Ellis, Pickens, Stotz, Vittal, 
@ISIC,White,
@ISID, Mealy, 
@MIT-DMS, Vezza, 
@mit-multics,Pogran,
@OFFICE-1, Dames, Engelbart, Grobstein, Jernigan, SMartin,
           Panko, Taylor, Uhlig, vonGehren, 
@RAND-RCC, Anderson, BRD, 
@RUTGERS-10, Kohanski, Ryland, 
@SRI-AI, Geoff, 
-------
10-MAY-78 22:11:30-PDT,384;000000000001
Reader-Id: 34
Date: 7 DEC 75 1813-PST
From: DCROCKER at USC-ISI
Subject: MSGGROUP# 223 Announcement of VERY large MsgGroup Msg
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-3-((76 1 7) (22 30 53) "PST").STEFFERUD>

MsgGroup Msg #215:  "The NLS Journal Mail Conference" by Panko at
Office-1, is available in [ISI]<MsgGroup>MsgGroup#.215.  

Dave.  
-------

10-MAY-78 22:11:30-PDT,4538;000000000001
Reader-Id: 35
Date: 9 DEC 75 1548-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 224 MSGGROUP SITUATION REPORT #1: III. ISSUE MATRIX
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-4-((76 1 7) (22 30 55) "PST").STEFFERUD>


MSGGROUP SITUATION REPORT NUMBER ONE .  .  .  .  .  .  .  Page 3 


III.  THE ISSUE MATRIX 

From the MsgGroup discussions, it would seem that one of our
greatest problems is establishment of a common set of perspectives
for viewing design goals of our message systems.  

The purpose of this matrix is to provide a global perspective in
which different aspects of message systems can be evaluated in
terms of User Activities and Message System Tools.  If successful,
this matrix will help to organize our thinking about specific
functions to be implemented in message systems.  

Activities are divided into three basic classes:  Discussion &
Correspondence; Meetings & Conferences; and Fact Gathering.  Tools
are divided into 4 categories:  Preparation & Modification;
Packaging & Delivery; Filing & Retrieval; and Data Banking &
Retrieval.  

Discussion & Correspondence includes the general kind of message
traffic we see in the ARPANET, with large and small messages
exchanged among individuals and groups without declaration of a
meeting or conference.  Both formal and informal traffic is
included.  

Meetings & Conferences consist of recognized group efforts to
collectively deliberate some subject, or to come to a conclusion
and make a decision on some specific issue or issues.  Use of
message systems in this area is poorly understood at best.  Both
formal and informal groups are included.  

Fact Gathering focuses on the collection and analysis of
information in order to produce a report or document.  It includes
accessing data banks to get information other than messages, such
as stock inventories, order backlogs, maintenance records, etc.
It seems clear that this kind of activity must eventually be
facilitated by our message systems so users can collect
information, analyze it and produce reports which can be delivered
via message systems.  

Preparation & Modification includes text entry & editing, assembly
& modification, formatting and printing of text.  This would
include processing of text from received messages as well as from
other sources.  

Packaging & Delivery includes assembly of messages into envelopes,
plus addressing, transmission, receiving, acknowledgement,
rerouting, etc.  It might also include archiving and auantication
facilities analogous to a county recorder's office.  

Filing & Retrieval includes the normal office activity of
processing messages and correspondence (received, sent and
inprocess).  

Data Banking & Retrieval includes the collection and accessing of
general information and data, as can be done with available data
management systems.  This category is included in the table
because message systems must facilitate access to data bank
information for incorporation into message system deliverable
packages.  


___________ 

MSGGROUP SITUATION REPORT NUMBER ONE .  .  .  .  .  .  .  Page 4 


ISSUE MATRIX (Continued) 

	

	User Activities and Message System Tools


*   Activities:	|		|		|
    *		|A. Discussion &|B. Meetings &	|C. Fact
	 *	| Correspondence|   Conferences	|   Gathering
Tools:	      *	|		|		|
-----------------------------------------------------------------
1. Preparation &|		|		|
   Modification	|		|		|
-----------------------------------------------------------------
2. Packaging &	|		|		|
   Delivery	|		|		|
-----------------------------------------------------------------
3. Filing &	|		|		|
   Retrieval	|		|		|
-----------------------------------------------------------------
4. Data Banking	|		|		|
   & Retrieval	|		|		|
-----------------------------------------------------------------
	


The Activity and Tool categories in this taxonomy are very
general, but they can be factored into subcategories and they do
add clarity and efficiency to our discussions.  The major concerns
of MsgGroup appear to focus on Preparation & Modification,
Packaging & Delivery, and Filing & Retrieval Tools for use in
Discussion, Correspondence, Meeting & Conference Activities.
MsgGroup is not much concerned with Data Banking and Retrieval
Tools or with Fact Gathering Activities.  The latter are included
to indicate how message systems relate to the rest of the
universe.  

-------

10-MAY-78 22:11:30-PDT,1343;000000000001
Reader-Id: 36
Date: 14 DEC 75 2356-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 225 New MsgGroup Members
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-5-((76 1 7) (22 30 56) "PST").STEFFERUD>

Welcome to HORNISH, PERLINGGIERO, HEITMEYER, HENDERSON, BROOS,
OESTREICHER, WHITE, POGRAN, and SMARTIN, 

Your names are now included in the official mailing list in
[ISI]<MsgGroup>MAILING.LIST.  

You will receive some introductory stuff in the next few messages
to get you into it.  

Message Group Members have received the new official list.  To get
another copy, please FTP it from [ISI]<MsgGroup> or request that a
new copy be sent via SNDMSG.  

If you wish, you might send a very brief description of yourself
to the MsgGroup so we will know what you first names are and a bit
about what role you play in this drama.  

For example, are you a customer (one who makes budget commitments
to buy message system services), a user (one who uses message
system services purchased by someone else), an implementer (one
who builds message systems), a sponsor (one who funds both users
and implementers in the development effort), or a critic (one with
no vested interest who contributes contructive comment in the
effort to develop message systems)?  

See you in the discussions, Stef 
-------

10-MAY-78 22:11:30-PDT,722;000000000001  
Reader-Id: 37
Date: 15 DEC 75 0940-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 226 Correct Name Spelling & Site Names
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-6-((76 1 7) (22 30 57) "PST").STEFFERUD>

Gentlepeople:

Please excuse my inability to spell Perlingiero correctly,
and please watch to avoid propigating my bad spelling
with the MSG/Mailsys/etc Answer Commands.

Thank you,   Stef


 HORNISH@BBN, PERLINGIERO@BBN, HEITMEYER@BBN, HENDERSON@BBNA,
BROOS@ISI, OESTREICHER@ISIB, WHITE@ISIC, POGRAN@MIT-MULTICS,
SMARTIN@OFFICE-1, 

PS: I am sending this to the entire MsgGroup to be sure
you all have received the correct HOST names for our new
members.    S/
-------

10-MAY-78 22:11:30-PDT,3478;000000000001
Reader-Id: 38
Date: 15 DEC 75 2330-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 227MSGGROUP SITUATION REPORT #1: IV. ISSUE MATRIX SUBCATEGOR
Subject: IES
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-7-((76 1 7) (22 30 59) "PST").STEFFERUD>


MSGGROUP SITUATION REPORT NUMBER ONE .  .  .  .  .  .  .  Page 5 


IV.  ISSUE MATRIX SUBCATEGORIES 

The major issue categories identified in Section III of this
report are much too general for operational level discussions.
This Section attempts to outline the subcategories under
operationally useful headings.  

To help keep track of things, subcategories will be given decimal
identifiers within their major categories, and if we are lucky,
the identifiers will serve as filing & retrieval aids in future
discussions.  Tool categories have numeric indicators while
Activity categories have alphabetic indicators.  

1.  PREPARATION & MODIFICATION 
	
1.1	TEXT ENTRY
1.2	EDITING
1.3	COLLECTING & ASSEMBLY
1.4	MODIFICATION
1.5	COORDINATION
1.6	FORMATTING 
1.7	TYPESETTING & PRINTING
	
2.  PACKAGING & DELIVERY 
	
2.1	ENVELOPES
2.1.1	   EXTERNAL STRUCTURE
2.1.2	   INTERNAL STRUCTURE
2.2	CONTENT
2.2.1	   FULL ENCLOSURE
2.2.2	   CITATION FOR ACCESS
2.3	ADDRESSING
2.3.1	   MAILBOXES
2.3.2	   AGENTS & PROXIES
2.3.3	   STRUCTURE
2.4	TRANSMISSION
2.4.1	   FAILURE
2.4.2	   REROUTING
2.5	RECEIVING
2.5.1	   REDISTRIBUTION
2.5.2	   FORWARDING
2.5.3	   AKNOWLEDGMENT
2.5	AUTHENTIFICATION
2.6	PUBLIC ARCHIVE
2.6.1	   ACCESS CONTROL
2.6.2	   OWNERSHIP
	
3.  FILING & RETRIEVAL 
	
3.1	ANNOTATION
3.2	FILING
3.3	RETRIEVAL
3.4	SEARCHING
3.5	ARCHIVING
3.6	PURGING
3.7	SHARING
	
4.  DATA BANKING 
	


________
	
MSGGROUP SITUATION REPORT NUMBER ONE .  .  .  .  .  .  .  Page 6 


A.  DISCUSSION & CORRESPONDENCE 
	
A.1	MESSAGES
A.2	MEMORANDA	
A.3	LETTERS	
A.4	NOTES	
A.5	DOCUMENTS	
A.6	PUBLICATIONS
A.7	COMMITMENTS	
A.8	DIRECTIVES	
A.9	TRANSACTIONS	
A.10	COORDINATION	
A.11	EVALUATION
	
B.  MEETINGS & CONFERENCES 
	
B.1	INITIATION
B.2	PARTICIPATION	
B.3	DOCUMENTATION
B.4	COORDINATION	
B.5	EXPEDITING	
B.6	VOTING	
	
C.  FACT GATHERING 
	
C.1	COLLECTION
C.2	STORAGE
C.3	ANALYSIS
C.4	SEARCHING
C.5	REPORT GENERATION 
	


In preparing this outline, the following thoughts surfaced and
they seem to provide some useful insight.  

Preparation & Modification are primarily private kinds of tools,
for use by individuals or groups without public concern for how
the tools are used or provided.  

Packaging & Delivery, on the other hand, are of public utility
type concern because all users are affected by the design and
performance of the delivery system.  

Filing & Retrieval are again more private in nature.  

These notions lead to additional criteria for separation of
message system functions, and for definition of requirements for
standards and protocols.  

At this point, it is important to obtain feedback from MsgGroup
regarding the propriety of the proposed subcategories.
Considerable thought has gone into the outline presented here, but
it is not clear that it will serve all our members well.  Please
forward your reactions to MsgGroup@ISI or to Stefferud@ISI.  

In the meantime, work will proceed toward development of a
discussion of each subcategory, and an effort will be made to
relate MsgGroup Proceedings Messages to these subcategories.  


________ 
-------

16-DEC-75 17:03:36-PDT,1618;000000000001 
Mail-from: USC-ISI rcvd at 16-DEC-75 1703-PST
Date: 16 DEC 1975 1655-PST
Sender: ELLIS at USC-ISI
Subject: MSGGROUP# 228  MESSAGE FUNCTIONS
From: TOM ELLIS
To: [ISI]<MsgGroup>Mailing.List:
Message-ID: <[USC-ISI]16-DEC-75 16:55:36-PST.ELLIS>

IN A RECENT MEETING (DEC. 4-5, 1975) OF THE MESSAGE COMMITTEE,
THE COMMITTEE (PER STEVE WALKER'S REQUEST) ARRIVED AT THE 
FOLLOWING FOR YOUR CONSIDERATION:

---------------------------------------------------------------
    A list of primitive functions was derived  and  preferred  commands  to
    evoke  these functions was arrived at by vote.  These functions are not
    in any way intended to describe a minimum system but rather are  to  be
    considered as a common language core pervading "all" systems.  Further,
    it is presented at this time only for comment by the Message Group.


          FUNCTION            EXPECTED ARG.       DEFAULT ARG.

          Quit                   ------              ------
          Summarize           Message Sequence    All unread or
                                                  unsummarized (new)
          Reply               Message Sequence    Current
          Forward             Message Sequence    Current
          Delete              Message Sequence    Current
          Print               Message Sequence    Current
          Next                (Prints next message and increments
                               current.)
          Compose             (Elicits actions to build a new message.)

----------------------------------------------------------------
-------
10-MAY-78 22:11:31-PDT,1296;000000000001  
Reader-Id: 40
Date: 17 DEC 75 0526-PST
From: WALKER at USC-ISI
Subject: MSGGROUP# 229 Message Service Primative Commands
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-8-((76 1 7) (22 31 3) "PST").STEFFERUD>


Let me comment briefly on the list of primative commands that Tom
Ellis sent to you recently. That list is intended to be a basic 
vocabulary of command names to be used by all message services
so that in moving from one service to another, one need not learn 
a new set of command names. It is my intent that that list, as
modified by MsgGroup interactions over the next month, will be 
implemented on all message services supported by ARPA and/or run
on ARPA owned machines. 

This is the first of a set of improvements to the message service
world which I will describe to you in a strategy message in the near 
future. Please consider that list seriously and consider changes in
light of the whole community of message service users, not specialized 
subsets. (DISPLAY is not a reasonable substitute for PRINT, but 
there is nothing in this proposal to preclude a message service from 
also supporting a DISPLAY command).

Your comments/suggestions are welcome. Lets set 17 Jan 76 as 
the deadline for your votes. Thanks.

Steve
-------

10-MAY-78 22:11:31-PDT,1086;000000000001  
Reader-Id: 65
Date: 18 DEC 75 0803-PST
From: Mitchell, Jon
Sender: NGOODWIN at BBN-TENEX
Subject: MSGGROUP# 230 Message Service Primitive Commands
Action-to: [ISI]<MsgGroup>Mailing.List:
CC: NGOODWIN
Message-Id: <[BBN-TENEX]18-DEC-75 11:03:28-EST.NGOODWIN>


I applaud the attempt to use universal terms for a set of basic
message service functions.  I presume that all implementations
will have the same interpretation for each primitive commands; 
that the results of our work will be a set of unambiguous
(we'll be lucky!) definitions of the results of invoking each
primitive.  (For example, "Summarize" will always generate
the same output from the same message.  Anyone who would prefer
to see different information in his summarywill have to use 
a different command.)

Are the primitives to be universally implemented?  Will 
preference be given to the primitive commands in assigning 
short forms for commands?  in assigning function keys(where
these are provided)?  I believe that the answer to all these questions 
should be "yes".

Jon
-------

10-MAY-78 22:11:31-PDT,880;000000000001    
Reader-Id: 41
Date: 18 DEC 75 1017-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 231 (trouble with <msggroup>mailing.list)
Action-to: NGOODWIN at BBN-TENEX
CC: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]18-DEC-75 10:17:49-PST.STEFFERUD>
Keywords: standards, problems, dms, mailsys, addresses, mailing-lists
In-Reply-To: <[BBN-TENEX]18-DEC-75 11:26:32-EST.NGOODWIN>
Filed-Under: MsgGroup

This is a test of [ISI]<MsgGroup>MAILING.LIST.  Nancy Goodwin
indicates that she had some trouble with it and I need to verify
that the master file in <MssgGroup> is not in error.  Thank you
for your patience with this test.  

Stef 


PS:  Nancy, As far as I can see, ISIC is a valid HOST name, in
spite of what your BBN MAILSYS says.  I am copying your message to
ACTION@ISI for their review and possible action.  
-------

10-MAY-78 22:11:31-PDT,1170;000000000001   
Reader-Id: 42
Date: 23 DEC 75 1238-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 232 Welcome to Roland Bryan
Action-to: BRYAN
CC: MSGGROUP, STEFFERUD
Message-Id: <[USC-ISI]23-DEC-75 12:38:37-PST.STEFFERUD>
Keywords: new-member-welcome
Filed-Under: msggroup

Welcome to MsgGroup:

Your name is now included in the official mailing list in
[ISI]<MsgGroup>MAILING.LIST.  

You will receive some introductory stuff in the next few messages
to get you into it.  

If you wish, you might send a very brief description of yourself
to the MsgGroup so we will know what you first names are and a bit
about what role you play in this drama.  

For example, are you a customer (one who makes budget commitments
to buy message system services), a user (one who uses message
system services purchased by someone else), an implementer (one
who builds message systems), a sponsor (one who funds both users
and implementers in the development effort), or a critic (one with
no vested interest who contributes contructive comment in the
effort to develop message systems)?  

See you in the discussions,   Stef
-------

23-DEC-75 13:08:38-PDT,3013;000000000005 
Mail-from: USC-ISI rcvd at 23-DEC-75 1308-PST
Date: 23 DEC 1975 1221-PST
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 233  [ISELI: Goodbye--Heading for the West Coast!]
From: STEFFERUD at USC-ISI
To: [ISI]<MsgGroup>Mailing.List:
Cc: ISELI, Jernigan at OFFICE-1
Message-ID: <[USC-ISI]23-DEC-75 12:21:16-PST.STEFFERUD>
Special-Handling: Please add Bryan@ISI to your MsgGroup
Special-Handling: membership lists. A new list is being sent to
Special-Handling: those who requested automatic update
Special-Handling: deliveries. Others may get copies via FTP or by
Special-Handling: request to MsgGroup@ISI.

	
Begin forwarded message
          --------------------
Mail from USC-ISI rcvd at 23-DEC-75 1207-PST
Date: 21 DEC 75 1929-PST
From: ISELI
Subject: Goodbye--Heading for the West Coast!
Action-to: stefferud
CC: iseli
Forwarded-By: STEFFERUD
Forwarded-To: msggROUP
Message-Id: <[FAKE]-1-((75 12 21) (20 2 13) "PST").STEFFERUD>



[Annotation by STEFFERUD on 23-DEC-75 11:49:58-PST.
To all MsgGroupers, I am forwarding this message from Mil Jernigan
for your information.  Hopefully it will arrive in time for you to
respond before she disappears from ARPANET.  Please note that the
suggested MsgGroup Mailing.list changes have been made in
[ISI]<MsgGroup>MAILING.LIST.  
-
Best wishes, Stef ]

Hi Steff -
Wanted to say goodbye. I am leaving ACC, the East Coast, and the ARPANET.
Expect to leave here about Jan. 10-15 and arrive in Portland about Jan. 20-25.

Got a chance to sppend a year in a rent-free cabin up a beautiful river
with a parttime job and leaving me with no hassles and time to do what
I have always wanted to do...write!  Have been getting back into free
lance writing again lately with some success, so am going to follow
up on it!  Already have my first novel outliined and started and
have been uncoouraged to submit it/with chapters for possible approval
and an advance, so it is too good to pass up the chance!

(I figure 6 years around the ARPANET is a good basis for ANYBODY for
writing science fiction!)

It has been a pleasure knowing you and watching the growth of the message
system. Looks very good, particularly some of the recent work.  Each
time I have said to myself...yeah, but what about.....someone came up
with it before I got around to writing it out.

Best of luck too you.  Take my name of <jernigan>office-1 off the
list, also <Iseli>isi, since I am going to ask that the directories be
closed.  You might add BRYAN@ISI instead, since he will get all my
files of your stuff and that will carry him on from there.  I am leaving
the ARPANET so thoroughly I am sending Roland Bryan (my boss) all my
collection of computer documentation!!!

Best of luck, and the merriest of Christmasses!!

Mil Jernigan     <jernigan>office-l,  <iseli>isi

P.S. This directory will be open a couple more days, but that is all.

-------


--------
          --------------------
End forwarded message
	
-------
10-MAY-78 22:11:32-PDT,334;000000000001
Reader-Id: 44
Date: 23 DEC 75 1336-PST
From: SUTKOWSKI at UTAH-10
Subject: MSGGROUP# 234 MSGGROUP
Action-to: MSGGROUP at USC-ISI
CC: STEFFERUD at USC-ISI
Message-Id: <[FAKE]-9-((76 1 7) (22 31 12) "PST").STEFFERUD>


PLEASE ADD SUTKOWSKI AT UUTAH-10 TO THE MSGGROUP MAILING LIST.
THANKS.

SUTKOWSKI AT UTAH-10
-------

10-MAY-78 22:11:32-PDT,1193;000000000001
Reader-Id: 45
Date: 26 DEC 75 1109-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 235 Welcome SUTKOWSKI@UTAH-10
Action-to: Sutkowski at UTAH-10
CC: STEFFERUD, MSGGROUP
Message-Id: <[USC-ISI]26-DEC-75 11:09:42-PST.STEFFERUD>
Keywords: administration, new-member
Filed-Under: MsgGroup

 are.

We are keeping a complete transcript of all messages received at
MsgGroup@ISI, but are separating the administative messages from
the substantive content messages in order to compact the
Proceedings.

This message explains how to find out more about the msgGroup
files and procedures, and how to join the group if you are so
inclined.

The next message in [ISI]<MsgGroup>MESSAGE.TXT contains a
description of our procedures for exchanging messages among
MsgGroup members.

The third message in [ISI]<MsgGroup>MESSAGE.TXT explains about
the PROCEEDINGS files and tells what is kept in them.

If you are interested in joining the fray, send a message to
MsgGroup@ISI, Stefferud@ISI, Farber@ISI, Pickens@ISIB, or to
DCrocker@ISI and we will add you to the mailing list.

Best Regards, Stef, Dave, John and Dave (respectively)
-------
14
10-MAY-78 22:11:32-PDT,656;000000000001   
Reader-Id: 46
Date: 29 DEC 75 1149-PST
From: SUTKOWSKI at UTAH-10
Subject: MSGGROUP# 236 INFORMATION
Action-to: MSGGROUP at USC-ISI
CC: STEFFERUD at USC-ISI
Message-Id: <[FAKE]-10-((76 1 7) (22 31 16) "PST").STEFFERUD>



THIS IS STEPHEN SUTKOWSKI OF ROME AIR DEVELOPMENT CENTER, GRIFFUS AIR
FORCE BASE, ROME, N. Y.  OUR INTEREST IN THE MSGGROUP IS ORIENTED TO
RESEARCHING MESSAGE SYSTEMS AND IMPLIMENTATIONS IN BOTH THE MILITARY
AND NON-MILITARY ENVIRONMENT, AND ALSO AS A USER OF THESE SYSTEMS.
IF POSSIBLE, I WOULD DESIRE TO LEARN MORE ABOUT RECENT INNOVATIONS
AND TO ALSO CONTRIBUTE AS WELL.  THANKS.

SUTKOWSKI AT UTAH-10
-------

10-MAY-78 22:11:32-PDT,393;000000000001 
Reader-Id: 47
Date: 29 DEC 75 1223-PST
From: SUTKOWSKI at UTAH-10
Subject: MSGGROUP# 237 TELE-CONFERENCES
Action-to: MSGGROUP at USC-ISI
CC: STEFFERUD at USC-ISI
Message-Id: <[FAKE]-11-((76 1 7) (22 31 18) "PST").STEFFERUD>


PLEASE INFORM ME OF ANY PLANNED TELE-CONFERENCES OR MEETINGS AND THEIR
RESPECTIVE TIMES IF POSSIBLE IN THE FUTURE.  THANKS.

STEPHEN SUTKOWSKI
-------

10-MAY-78 22:11:33-PDT,508;000000000001 
Reader-Id: 48
Date: 29 DEC 75 1305-PST
From: STEFFERUD
Subject: MSGGROUP# 238 Re: TELE-CONFERENCES
Action-to: MSGGROUP, SUTKOWSKI at UTAH-10
CC: STEFFERUD
Message-Id: <[FAKE]-12-((76 1 7) (22 31 19) "PST").STEFFERUD>

In response to the message sent 29 DEC 1975 1323-MST from SUTKOWSKI at UTAH-10

Hi Stephen,  You should receive info on planned tele-conferences in the
normal course of events via MsgGroup, assuming that someone informs us
MsgGroupers of such events.

Best,  Stef
-------

10-MAY-78 22:11:33-PDT,2035;000000000001   
Reader-Id: 49
Date: 29 DEC 75 1415-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 239 [SUTKOWSKI at UTAH-10: INFORMATION] [SUTKOWSKI at UTAH-1
Subject: 0: TELE-CONFERENCES] [STEFFERUD: Re: TELE-CONFERENCES] 
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]29-DEC-75 14:15:31-PST.STEFFERUD>
Keywords: new-member, tele-conferences
Filed-Under: msggroup
Special-Handling: forwarded message exchange with Sutkowski foryour info.

	
Begin forwarded messages
          --------------------
Mail from UTAH-10 rcvd at 29-DEC-75 1146-PST
Date: 29 DEC 1975 1249-MST
From: SUTKOWSKI at UTAH-10
Subject: INFORMATION
To:   MSGGROUP at ISI
cc:   STEFFERUD at USC-ISI



THIS IS STEPHEN SUTKOWSKI OF ROME AIR DEVELOPMENT CENTER, GRIFFUS AIR
FORCE BASE, ROME, N. Y.  OUR INTEREST IN THE MSGGROUP IS ORIENTED TO
RESEARCHING MESSAGE SYSTEMS AND IMPLIMENTATIONS IN BOTH THE MILITARY
AND NON-MILITARY ENVIRONMENT, AND ALSO AS A USER OF THESE SYSTEMS.
IF POSSIBLE, I WOULD DESIRE TO LEARN MORE ABOUT RECENT INNOVATIONS
AND TO ALSO CONTRIBUTE AS WELL.  THANKS.

SUTKOWSKI AT UTAH-10
-------
          --------------------
Mail from UTAH-10 rcvd at 29-DEC-75 1220-PST
Date: 29 DEC 1975 1323-MST
From: SUTKOWSKI at UTAH-10
Subject: TELE-CONFERENCES
To:   MSGGROUP at ISI
cc:   STEFFERUD at USC-ISI


PLEASE INFORM ME OF ANY PLANNED TELE-CONFERENCES OR MEETINGS AND THEIR
RESPECTIVE TIMES IF POSSIBLE IN THE FUTURE.  THANKS.

STEPHEN SUTKOWSKI
-------
          --------------------
Date: 29 DEC 1975 1305-PST
From: STEFFERUD
Subject: Re: TELE-CONFERENCES
To:   SUTKOWSKI at UTAH-10, MSGGROUP
cc:   STEFFERUD

In response to the message sent 29 DEC 1975 1323-MST from SUTKOWSKI at UTAH-10

Hi Stephen,  You should receive info on planned tele-conferences in the
normal course of events via MsgGroup, assuming that someone informs us
MsgGroupers of such events.

Best,  Stef
-------
          --------------------
End forwarded messages
	
-------

10-MAY-78 22:11:33-PDT,3784;000000000001    
Reader-Id: 50
Date: 29 DEC 75 2338-PST
From: DCROCKER at USC-ISI
Subject: MSGGROUP# 240 User Specification of Presentation Format (for Mailsys)
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-13-((76 1 7) (22 31 23) "PST").STEFFERUD>

        A few weeks back, upon seeing some of BBN's Mailsys Format
specification mechanism (Template??) I offered some suggestions for
added features.  I'd like to record them, for posterity.  

        For those unfamiliar with the system, the user simply places
field names and literals onto consecutive lines, and that is how the
message is printed.  For example:  
	
		"From:  " From "		Date
		"Re:    " Subject

		Text
	
will cause the first line of the message to contain the field title and
contents of the field indicating who the message is from, with the
origination date somewhat to the right.  The second and succeeding lines
should be obvious.  

        I don't know if the current facility supports user-named fields,
that are unknown to the system.  For example, even if Mailsys had never
heard of the field "Filed-Under" (used by MsgDms) I would like to be
able to indicate where and when to print it.  This is in addition to
being able to say "Other" as a catchall for all the unknown fields.  

        Anyhow, the formatting issues that needed resolving concerned
how the user is to indicate text that is to be Flush left or right,
begin in a particular column, or how to treat overflow text that is too
long for the rest of the field.  For example, the Date would look better
being flush right, than simply "over a few spaces" and where is the
extra text to be placed if the Subject field is longer than one line?  

        The following syntax is offered.  In an attempt to allow the
user to employ any "intuitive" symbol, I have suggested MANY
alternatives.  (And I am not sure how I feel about that fact.) In
general, the symbols are semantically or visually intuitive or they
derive from proofreader's symbols:  
	
	Flush Left:  

		<  or  <-  or  Left  or Flush Left

	Flush Right:

		>  or  ->  or  Right  or  Flush Right

	Field definition (i.e., set of contiguous print positions):

		Start...End  or  [...]  or  (...)  or  {...}

	Centered (within column):

		|...|  or ||...|| or Center
		where "Center" precedes the field reference

	Field width:

		Width ##

	Tab to column

		Column ##
	

        In retrospect, I guess my PL/1 experience has stuck.  All told,
the above would cause the following specification:  
	
Column 30 Width 30 [Center (Field1) > Field2] > Field3
	
to print as:  
	
		Field1    Field2		Field3
	30	35   55        60		     72(i.e., right margin)
	
if Field1 were twenty character long.  

        Note that centering is relative to the current Bracketed field
("Block") and independent of any other fields in the Bracketed field.
Also note that the brackets around Field1 are gratuitous.  Wrap around
is relative to the closest brackets.  If Field1 were more than 30
characters long, it would move onto column 30 of the next line, with
Field2 printing whenever Field1 were finished.  Field3, however, would
always begin printing on the first line.  Note that If it has any
overflow, it will begin printing in column 61.  Blocking is not like
with programs.  A Bracketed field extends up and down the entire page.
The default is to wrap around from the first printing position of the
current (non-bracketed) field.  

        Some of the latter behaviors seem ugly, tho that may be an
artifact of my having chosen such an ugly example.  I would appreciate
some comments, since I basically like BBN's specification style (tho not
their label for the process).  

Dave.  
-------

10-MAY-78 22:11:33-PDT,383;000000000001 
Reader-Id: 51
Date: 30 DEC 75 0811-PST
From: SUTKOWSKI at UTAH-10
Subject: MSGGROUP# 241 NEW ADDITION
Action-to: MSGGROUP at USC-ISI
CC: STEFFERUD at USC-ISI
Message-Id: <[FAKE]-14-((76 1 7) (22 31 24) "PST").STEFFERUD>


PLEASE ADD STONE AT OFFICE-1 TO THE MSGGROUP MAILING LIST (HE IS ALSO
WITH THE ROME AIR DEVELOPMENT CENTER).  THANKS.

STEPHEN SUTKOWSKI
-------

10-MAY-78 22:11:33-PDT,742;000000000001  
Reader-Id: 52
Date: 30 DEC 75 0937-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 242 Adding Young@OFFICE-1 to MsgGroup
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-15-((76 1 7) (22 31 26) "PST").STEFFERUD>

Mail from UTAH-10 rcvd at 30-DEC-75 0809-PST
Date: 30 DEC 1975 0911-MST
From: SUTKOWSKI at UTAH-10
Subject: NEW ADDITION
To:   MSGGROUP at ISI
cc:   STEFFERUD at USC-ISI


PLEASE ADD STONE AT OFFICE-1 TO THE MSGGROUP MAILING LIST (HE IS ALSO
WITH THE ROME AIR DEVELOPMENT CENTER).  THANKS.

STEPHEN SUTKOWSKI
-------


Young@OFFICE-1 has been added to [ISI]<MsgGroup>MAILING.LIST.

Please add to your mailing.list or get a new copy from [ISI]<MsgGroup.

Happy New Year,    Stef
-------

10-MAY-78 22:11:33-PDT,1338;000000000001
Reader-Id: 53
Date: 31 DEC 75 0319-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 243 Mailing.list Changes
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-16-((76 1 7) (22 31 27) "PST").STEFFERUD>

   1   30 Dec  KOHANSKI at RUTGERS-1 NAME CONFUSION
   2   30 DEC  Nancy Goodwin         new account/site


1 -- ************************
Mail from RUTGERS-10 rcvd at 30-DEC-75 1048-PST
Date: 30 Dec 1975 (Tuesday) 1346-Est
From: KOHANSKI at RUTGERS-10
Subject: NAME CONFUSION
To:   STEFFERUD at USC-ISI


IS THE NAME TO BE ADDED "STONE" OR "YOUNG"?

[DAN]


2 -- ************************
Mail from USC-ISI rcvd at 30-DEC-75 1028-PST
Date: 30 DEC 1975 1027-PST
Sender: GOODWIN at USC-ISI
Subject: new account/site
From: Nancy Goodwin
To: STEFFERUD, bergstrom at BBN, blankenheim at BBN, 
To: bair at OFFICE-1
Message-ID: <[USC-ISI]30-DEC-75 10:27:22-PST.GOODWIN>


The Goodwin-Mitchell account has been moved from BBN to ISI.
Jonathan and I can now be reached at GOODWIN@ISI.

(Stef - Please remove NGOODWIN@BBN from the MsgGroup mailing list,
and add GOODWIN@ISI. Thanks)

Nancy Goodwin
-------

My Subject field was wrong, but I got it right in [ISI]<MsgGroup>Mailing.List.

You should add Stone@OFFICE-1 and change Nancy as she requests.

Happy New Year,

Stef
-------

10-MAY-78 22:11:34-PDT,1541;000000000001  
Reader-Id: 54
Date: 2 JAN 76 0845-PST
From: RYLAND
Sender: RYLAND
Subject: MSGGROUP# 244 
Action-to: [ISI]<MsgGroup>Mailing.List:
CC: RYLAND
Message-Id: <[USC-ISID]2-JAN-76 08:45:31-PST.RYLAND>


Hi, all:
     This is Chris Ryland at Harvard.  I'm preparing a paper
concerning  the  technological  impact  of the ARPA Network.
Clearly, one of the most important features of the net is  a
speed-up in communication among researchers, scientists, and
users of the net in general.  Some of the  aspects  of  this
speed-up  are  message  systems  (the MsgGroup's specialty),
net-wide availability of software  tools  at  server  sites,
pre-publication  idea  sharing (eg worker X ships worker Y a
runoff of a first draft), availability  of  other  resources
for  special groups on the net (ILLIAC IV, the Datacomputer,
etc).  What I would like to hear  about  is  any  experience
with  the  above  (or any other related) features and tools,
that demonstrates the novelty of the network in facilitating
communication  among researchers.  Any sort of reply will be
welcome, from "I communicate with 10 people every day" (ie a
quick reference to personal utility) to a documentary of the
usefulness of the net in several research projects.  I think
the message group is in a specially good position to witness
to this sort of thing, and I hope to hear from some of  you.
Please  address all mail to RYLAND@ISID.  Thank you for your
time, and Happy New Year to all!
                        Chris Ryland

-------

10-MAY-78 22:11:34-PDT,427;000000000001  
Reader-Id: 55
Date: 2 JAN 76 1100-PST
From: SUTKOWSKI at UTAH-10
Subject: MSGGROUP# 245 MSGGROUP PAPERS
Action-to: MSGGROUP at USC-ISI
CC: STEFFERUD at USC-ISI
Message-Id: <[FAKE]-17-((76 1 7) (22 31 53) "PST").STEFFERUD>


I WOULD APPRECIATE RECEIVING THE FOLLOWING MSGGROUP PAPERS MISSING FROM
OUR COMPLIATION:

MSGGROUP #91,#127,#157,#186,#189 THROUGH #195,AND #203,.

THANKS.

STEPHEN SUTKOWSKI
-------

10-MAY-78 22:11:34-PDT,621;000000000001   
Reader-Id: 56
Date: 2 JAN 76 1144-PST
From: STEFFERUD
Subject: MSGGROUP# 246 Re: MSGGROUP PAPERS
Action-to: MSGGROUP, SUTKOWSKI at UTAH-10
CC: STEFFERUD
Message-Id: <[FAKE]-18-((76 1 7) (22 31 59) "PST").STEFFERUD>

In response to the message sent  2 JAN 1976 1200-MST from SUTKOWSKI at UTAH-10

Hi, I have located the message copies you requested.

Do you want  hem all inclosed in one message or in separate messages.

No problem at this end, which ever you want, but of course I need
to know before I do it.

I will send them later this afternoon if I haer from you today.

Best,   Stef
-------

10-MAY-78 22:11:34-PDT,2225;000000000001   
Reader-Id: 57
Date: 2 JAN 76 1724-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 347 Obtaining RFC#680 and other RFCs
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]2-JAN-76 17:24:09-PST.STEFFERUD>


Hello MsgGroupers, 

Thanks to John Pickens, those of you with ISIA directories can use
a "DO" file in [ISI]<MsgGroup> named FTP.RFC to obtain copies of
RFCs of interest.  The following Telnet.Typscript will show you
how to use it.  To initiate the action, just type:  

@DO <msggroup>ftp.rfc;1 

Then you will be asked for the RFC#:  and you type the number of
the RFC you want, followed with a carriage return.  The DO file
processor will do the rest for you.  

If you are not blessed with an ISIA directory, you can do your own
FTP using the information given in the Typescript.  

Or, if you only want RFC#680 you can FTP it directly from
[ISI]<MsgGroup>RFC680.TXT;1.  

RFC#680 may be of interest to MsgGroupers who want to know about
the detailed specifications for the packaging of messages for
transmission.  This information is relevant to those who are
concerned about the adherence or lack of adherence to the
standards by various sending and receiving message systems.  

Enjoy, Stef 
	
________Begin Telnet Typscript________
@do 
Input file: <msggROUP>ftp.RFC;1
RFC #: 680
DO interrupt character: ^B

 ISI-TENEX 1.33.12, ISI-SYSTEM-A EXEC 1.53.8
 TENEX WILL GO DOWN THU 1-8-76 2200 TIL FRI 1-9-76 0500
 FOR PREVENTIVE MAINTENANCE
@FTP

USC-ISI FTP User process 1.21.0
*OFFICE-1
 Connection opened
 Assuming 36-bit connections, Paged transfers.

*LOGIN NICGUEST ARPA

< OFFICE-1 FTP Server 1.44.0.0 - at FRI 2-JAN-76 16:04-PST
*GET <NETINFO>RFC680.TXT
 to local-file RRFC680.TXT
 [New version]
< Login completed.
< Retrieve of <NETINFO>RFC680.TXT;1 started.
< Transfer completed.

3584. bytes transferred, run time = 373. MS,
 Elapsed time = 12207. MS, Rate = 10569. Baud.
*BYE
*QUI
@DEL DO.XPSTR;*


 DO.XPSTR;1;T
@EXP
@Did.
@dir rfc680.*;* 

   <STEFFERUD>
 RFC680.TXT;2,1

@conn msggROUP (PASSWORD) 
@ren <stefFERUD>rfc680.TXT;2 (TO BE) RFC680.TXT;1 [New file] 
logo

-------

10-MAY-78 22:11:34-PDT,3900;000000000001   
Reader-Id: 58
Date: 5 JAN 76 1353-PST
From: Geoff at SRI-AI
Subject: MSGGROUP# 248 ARPAnet mail the coming thing?
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-19-((76 1 7) (22 32 8) "PST").STEFFERUD>

Hi all,

   I was reading the news via SU-AI's New York Times and AP news wire system
last night, when I came accross an artical on how the post office is
worried that they might get ripped off if everyone goes the ARPAnet mail
route in the future; so Stef and I thought it might spark some conversation
if I sent the artical around to you all.

	[Geoff]

<<<<<<----->>>>>>

a018  2304  04 Jan 76
Electronic Mail Bjt 490, 2 takes 610
By JEFFREY MILLS
Associated Press Writer
    WASHINGTON (AP) - The Postal Service is beginning to worry about
competition from electronic communication systems which threaten to
make mailmen obsolete.
    ''We are being by-passed technologically and these new developments
have a potential impact on the bread-and-butter part of our business,
first-class mail,'' said J. T. Ellington Jr., senior assistant
postmaster general, in an interview.
    The Postal Service has a legal monopoly on first-class mail, but the
electronic systems were never anticipated by the laws estabishing
this monopoly.
    One of the first major uses of the new technology begins this month
as the federal government bypasses the mails to begin depositing some
Social Security payments directly in pensioners' bank accounts by
electronic transfer. This is done by providing each bank with magnetic
tape that records all Social Security deposits for that bank.
    The government plans to use electronic transfer in the coming years
to pay federal employes' salaries and make other payments, such as to
veterans and retired government workers.
    Within five years, 18 million fewer government checks will be moving
through the mail every month, the Treasury Department estimates.
    Financial institutions are considering similar means to transfer
money instead of mailing pieces of paper, a move that could mean less
mail volume. Financial mail comprises over one-third of the Postal
Service's revenue. In addition, some businesses have invested in
systems of electronic message transmission, a related area.
    Offcials say an expected over-all decline of 4 per cent in mail
usage over the next five years ''is just devastating'' on the
service's financial position because of the related loss of revenue.
    Describing the technological change facing the service, Ellington
said, ''The majority of business mail already is generated by computer
- computerized invoices, computerized addresses or what have you.
Once you have a relationship like that, you have to ask why not just
send the message from one computer to another without the middleman.''
    The message industry envisions a receiver in everyone's home to
receive messages 24 hours a day. A customer upon awakening would find
all of his ''mail'' in a tray waiting for him. The technology for
such systems may already exist in microwaves and satellite channels.
    Ellington described the Postal Service as ''the last of the mass
personal services. The milkman and the deliveryman are gone but we
still have mailmen.''
    The Postal Service, with nearly 700,000 employes, is what economists
call ''labor intensive,'' meaning people do most of the processing.
    Ellington said the inroads of the new technology ''are causing us to
look again at the nature of our mail system. Should we deliver mail
every day? Should we impose a charge for delivering mail to a new
address? If we are to continue the present type of service, there may
hav to be higher subsidies from Congress.''
    Ellington said the Postal Service is ''evaluating going into''
electronic transfer.
    More
    
0204aES 01-05
***************

-------

10-MAY-78 22:11:35-PDT,455;000000000001    
Reader-Id: 59
Date: 5 JAN 76 2109-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 249 MsgGroup Membership Changes
Action-to: [ISI]<MsgGroup>Mailing.List:
CC: Oestreicher at USC-ISIB
Message-Id: <[USC-ISI]5-JAN-76 21:09:30-PST.STEFFERUD>

Don Oestreicher has asked to be removed from the list. He will
keep in touch through Rob Stotz. Chris Ryland has moved from
Rutgers-10 to ISID. Best regards, Stef
-------

10-MAY-78 22:11:35-PDT,705;000000000001    
Reader-Id: 60
Date: 5 JAN 76 0-342-PST
From: HENDERSON at BBN-TENEXA
Sender: HENDERSON at BBN-TENEXA
Subject: MSGGROUP# 250 Self Introduction.
Message-Id: <[BBN-TENEXA]6-JAN-76 00:42:05-EST.HENDERSON> 

Stef has suggested that new members introduce themselves.
Accordingly: I am responsible for the implementation of BBN's
mail system (variously known as MAILSYS, XMAIL, and HERMES).
Also I am a fiarly extensive user of mail systems (I receive on
the order of 10 to 20 messages a day -- before I joined the
Message Group; and a not insignificant amount of the organization
of the programmers implementing our system is done through the
medium of messages).

Austin Henderson.
-------

10-MAY-78 22:11:35-PDT,1484;000000000001    
Reader-Id: 61
Date: 6 JAN 76 0305-PST
From: Geoff at SRI-AI
Subject: MSGGROUP# 251 ARPAnet mail the coming thing?  Part II.
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-20-((76 1 7) (22 32 12) "PST").STEFFERUD>

Hi again,

   At the request of Dave Crocker, I went and got the rest of the story
that came out after I had gotten the first part.  Itz inclosed at the
end of this message.

Enjoy,
	[Geoff]

<<<<<----->>>>>>
a019  2307  04 Jan 76
Electronic Mail Bjt take 2 120
WASHN Electronic Mail Bjt ADD: transfer.
    ''We have a modest research effort to determine what kind of hard
copy transmission is viable for us,'' he said.
    So far, the Postal Service has Mailgram, a combination of its own
delivery network with Western Union's electronic transmission
facilities. Ellington called this ''our toe in the water.''
    The National Association of Letter Carriers, representing 200,000
mailmen, also is concerned about the potential inroads of electronic
communications.
    The union's electronic mail committee predicted that the new
technology would affect the number of jobs for letter carriers.
    It recommended legislation to give the Postal Service ''a subsidy to
enter competition for the electronic mail business.''
    
0207aES 01-05
***************

   If you want the whole thing in one piece, I have nicely put it
in [SRI-AI]<GEOFF>ELECTRONIC.MAIL  which can be FTP'd using 
ANONYMOUS login.	[G]
-------

10-MAY-78 22:11:36-PDT,2159;000000000001    
Reader-Id: 2
Date: 8 JAN 76 1151-PST
From: Myer at BBN-TENEX
Sender: FITZPATRICK at BBN-TENEXA
Subject: MSGGROUP# 252 REF: DCROCKER AND UHLIG ON "ENVELOPES"
Message-Id: <[BBN-TENEXA]8-JAN-76 14:51:28-EST.FITZPATRICK>    


Gentlemen:

I  haven't  seen  Dave  Farber's message on this topic, so please
forgive any repetition in what follows.

How about a model based on business  letters?   The  usual  thing
with   a   business  letter  is  to  include  all  the  essential
information about who sent it, who's getting  it,  etc.,  in  the
letter itself.  If you file the letter, this data stays with it.

Some  of  this  information is repeated on the envelope, together
with (possibly)  some  additional  routing  data,  but  only  for
purposes  of  physically  moving the letter.  Thus, the recipient
will normally throw away the envelope.

When we designed the current (TENEX) delivery system, this is the
model  we  had  in  mind.  Thus, as Dave Crocker correctly points
out, the "holding file" that buffers the message  for  Mailer  is
indeed  the  envelope.   For  routing  purposes,  address data is
copied out of the message itself into  the  name  of  this  file.
However, since it merely copies what's permanently in the letter,
this file name can be, and is, thrown away.

Both Mailsys and MSG also regard all header fields as part of  the
message, rather than the envelope.

Our  own  view is that the business letter model is a pretty good
one.  The recipient of a message should be able to do pretty much
what  he  can  do with a letter.  If he'd like to "snip it apart"
and do different things with the separate pieces, then he  should
be  allowed  to  do  so.   However,  if he does nothing, then the
message should hold together as a single unit -- just as a letter
does.

I  believe  that  Ron's  idea  of a correspondent file, and other
related applications, should be implemented as specialized  tools
that  would  "ride  on  top of" a more basic message sysem.  Such
tools could dissect incoming messages, build  up  special  files,
generate automatic answers, etc.

/Ted Myer
-------

10-MAY-78 22:11:36-PDT,4027;000000000001 
Reader-Id: 3
Date: 9 JAN 76 0828-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 253 Message Function Primative Commands
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 1 10) (11 26 6) "PST").STEFFERUD>

	
With Reference to Messages from file: [USC-ISI]<MSGGROUP>MESSAGE.TXT;1
		 -- WEDNESDAY, JANUARY 7, 1976 18:38:45-PST --

   10  16 DEC  TOM ELLIS             MESSAGE FUNCTIONS (1602 chrs)
   11  17 DEC  WALKER at USC-ISI     Message Service Primative Commands
                                     (1247 chrs)
   12  18 DEC  Jon Mitchell          Message Service Primitive Commands
                                     (1097 chrs)
	
The following paragraphs discuss the "Primative Commands" that
Steve Walker has asked us to discuss so we might come to a
consensus on what is right to do about a core set of primative
commands and functions for ARPANET message systems and services.  

The proposed command names are:  Quit, Summarize, Reply, Forward,
Delete, Print, Next, and Compose.  In the transmittal message, the
behavior of these commands was not detailed.  It seems fair to
assume that they are to do what their equivalent commands do in a
MAILSYS/MSG sort of system.  In any case, this discussion makes
this assumption.  

Since MsgGroup is supposed to be a user oriented discussion group,
it seems reasonable that we adopt a users orientation.  Perhaps we
should even adopt a dumb users perspective, since the need for a
minimum set of core primatives is probably not derivable from the
behavior of sophisticated users.  

Assuming that we want to specify the minimal coherent set of
commands and briefly specify their functional behavior, I will
first review the completeness of the proposed set, disregarding
the propriety of the proposed command names.  

It seems to me that any minimal system should be able to read and
write files other than MESSAGE.TXT, so I suggest that we add a
"File" command to write designated messages into files and a "Get"
command to replace the current file with a specified file.  

Then I suggest a "Cleanup" command to expunge Deleted messages.
This would give me the basic ability to Cleanup and Quit, or Quit
without Cleanup if I wish.  I believe that this kind of option is
absolutely vital for any user who is beyond his first introduction
and who accumulating 3 or more messages per day.  

To me it is not reasonable to make the user accept a cleanup on
every exit from the system.  User sessions are not always under
the full control of the user.  Often they are interrupted by
outside events which cannot be ignored.  The primative set should
at least be a bit civilized!  

With these additions, I feel that the set would be complete and
coherent as a minimal set of commands.  

I considered a goto to accompany the notion of the "current
message number" default, but it really is not needed if all
commands accept message sequence arguments.  

I also considered a Send command to "send" the current content of
the compose buffers as a message, but the other commands do not
appear to offer any opportunity to use such a Send command, unless
the primative command set is expanded to include a command which
opens the buffer for each defined field in Composable messages.  

It is an interesting idea that all message systems might be
required to allow individual field text entry with the field name
used as the evoking command name, but I fear that this may get way
beyond the notion of a minimal command set.  However, there is
another view that says this would be the "true primative set" with
Compose being a command that is beyond the primative set.  

When I started composing this message, I thought I would first
discuss completeness, and then work my way through the proposed
primatives list.  This message is already a bit too long, so I
will stop here and put my "command specific" comments in another
message.  

Comments anyone?  Stef 
-------

10-MAY-78 22:11:36-PDT,1794;000000000001    
Reader-Id: 1
Date: 10 JAN 76 1259-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 254 New MsgGroup Transactions Processing Methods
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]10-JAN-76 12:59:41-PST.STEFFERUD>

I have begun to process [ISI]<MsgGroup> messages with MSGDMS to
insert the MSGGROUP# in the beginning of the subject lines of each
message.  This allows daily processing of messages so that newly
arrived messages can be given their MSGGROUP# right away.  It also
makes it easy to Move and Put messages into TRANSACTIONS.MSG,
PROCEEDINGS.MSG, ADMINISTRATIVE.MSG, and PROCEEDINGS.HEADERS with
normal MSG Commands.  

MSGDMS might do some transformations on your messages that you do
not approve of.  To ease the processing burden on me I request
that you each check your transformed messages for yourselves, and
tell me if you are displeased by the results.  

Please note that what I am doing "rubs" our various message
systems together in what may be an abrasive fashion, in that the
things they do to each other's messages is not always what we
expect or want.  This exercise will give us all some direct
experience with the consequences of our current system
incompatiblities and inconsistencies.  We will need to exercise
our patience and understanding but it should be worth it in the
end.  

To safeguard against loss of any message content, I will copy all
original messages to [ISI]<MsgGroup>MESSAGE.MSGGROUP#n-m which is
marked for archive with deletion.  This will allow us to recover
from any problems that may arise.  

In addition to your assistance, I would appreciate any comments on
these procedures that you can contribute to the MsgGroup Dialogue.  

Thank you, Stef 
-------

10-MAY-78 22:11:36-PDT,4797;000000000001 
Reader-Id: 5
Date: 10 JAN 76 1322-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 255 Header Listing of Processed Messages
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]10-JAN-76 13:22:28-PST.STEFFERUD>

Here is the Headers Listing of the most recently processed
MsgGroup messages for your information and inspection per my prior
message.  

Enjoy!  Stef 


 -- Messages from file: [USC-ISI]<MSGGROUP>TRANSACTIONS.MSG;6
		 -- SATURDAY, JANUARY 10, 1976 13:07:38-PST --

   223  7 DEC  DCROCKER at USC-ISI   MSGGROUP# 223 Announcement of VERY
                                     large MsgGroup Msg (384 chrs)
   224  9 DEC  STEFFERUD at USC-ISI  MSGGROUP# 224 MSGGROUP SITUATION 
                                     REPORT #1: III. ISSUE MATRIX
                                     (4538 chrs)
   225 14 DEC  STEFFERUD at USC-ISI  MSGGROUP# 225 New MsgGroup Members
                                     (1343 chrs)
   226 15 DEC  STEFFERUD at USC-ISI  MSGGROUP# 226 Correct Name 
                                     Spelling & Site Names (722 chrs)
   227 15 DEC  STEFFERUD at USC-ISI  MSGGROUP# 227MSGGROUP SITUATION 
                                     REPORT #1: IV. ISSUE MATRIX 
                                     SUBCATEGOR (3478 chrs)
   228 16 DEC  ELLIS at USC-ISI      MSGGROUP# 228 MESSAGE FUNCTIONS
                                     (1637 chrs)
   229 17 DEC  WALKER at USC-ISI     MSGGROUP# 229 Message Service 
                                     Primative Commands (1296 chrs)
   230 18 DEC  NGOODWIN at BBN-TENEX MSGGROUP# 230 Message Service 
                                     Primitive Commands (1086 chrs)
   231 18 DEC  STEFFERUD at USC-ISI  MSGGROUP# 231 (trouble with 
                                     <msggroup>mailing.list) (880 chrs)
   232 23 DEC  STEFFERUD at USC-ISI  MSGGROUP# 232 Welcome to Roland 
                                     Bryan (1170 chrs)
   233 23 DEC  STEFFERUD at USC-ISI  MSGGROUP# 233 [ISELI: Goodbye--Hea
                                     ding for the West Coast!]
                                     (2981 chrs)
   234 23 DEC  SUTKOWSKI at UTAH-10  MSGGROUP# 234 MSGGROUP (334 chrs)
   235 26 DEC  STEFFERUD at USC-ISI  MSGGROUP# 235 Welcome SUTKOWSKI@UT
                                     AH-10 (1193 chrs)
   236 29 DEC  SUTKOWSKI at UTAH-10  MSGGROUP# 236 INFORMATION
                                     (656 chrs)
   237 29 DEC  SUTKOWSKI at UTAH-10  MSGGROUP# 237 TELE-CONFERENCES
                                     (393 chrs)
   238 29 DEC  STEFFERUD             MSGGROUP# 238 Re: TELE-CONFERENCES
                                     (508 chrs)
   239 29 DEC  STEFFERUD at USC-ISI  MSGGROUP# 239 [SUTKOWSKI at 
                                     UTAH-10: INFORMATION] [SUTKOWSKI 
                                     at UTAH-1 (2035 chrs)
   240 29 DEC  DCROCKER at USC-ISI   MSGGROUP# 240 User Specification 
                                     of Presentation Format (for 
                                     Mailsys) (3784 chrs)
   241 30 DEC  SUTKOWSKI at UTAH-10  MSGGROUP# 241 NEW ADDITION
                                     (383 chrs)
   242 30 DEC  STEFFERUD at USC-ISI  MSGGROUP# 242 Adding Young@OFFICE-
                                     1 to MsgGroup (742 chrs)
   243 31 DEC  STEFFERUD at USC-ISI  MSGGROUP# 243 Mailing.list Changes
                                     (1338 chrs)
   244  2 JAN  RYLAND                MSGGROUP# 244  (1541 chrs)
   245  2 JAN  SUTKOWSKI at UTAH-10  MSGGROUP# 245 MSGGROUP PAPERS
                                     (427 chrs)
   246  2 JAN  STEFFERUD             MSGGROUP# 246 Re: MSGGROUP PAPERS
                                     (621 chrs)
   247  2 JAN  STEFFERUD at USC-ISI  MSGGROUP# 347 Obtaining RFC#680 
                                     and other RFCs (2225 chrs)
   248  5 JAN  Geoff at SRI-AI       MSGGROUP# 248 ARPAnet mail the 
                                     coming thing? (3900 chrs)
   249  5 JAN  STEFFERUD at USC-ISI  MSGGROUP# 249 MsgGroup Membership 
                                     Changes (455 chrs)
   250  5 JAN  HENDERSON at BBN-TENE MSGGROUP# 250 Self Introduction.
                                     (705 chrs)
   251  6 JAN  Geoff at SRI-AI       MSGGROUP# 251 ARPAnet mail the 
                                     coming thing?  Part II.
                                     (1484 chrs)
   252  8 JAN  FITZPATRICK at BBN-TE MSGGROUP# 252 REF: DCROCKER AND 
                                     UHLIG ON "ENVELOPES" (2159 chrs)
   253  9 JAN  STEFFERUD at USC-ISI  MSGGROUP# 253 Message Function 
                                     Primative Commands (4027 chrs)

-------

10-MAY-78 22:11:36-PDT,301;000000000001   
Reader-Id: 6
Date: 10 JAN 76 1512-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 256 CHANGE PICKENS@ISIB TO UCSB@ISI
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 1 10) (22 55 24) "PST").STEFFERUD>

MSGGROUPERS SHOULD CHANGE PICKENS@ISIB TO UCSB@ISI.  /STEF
-------

10-MAY-78 22:11:36-PDT,1490;000000000001   
Reader-Id: 7
Date: 12 JAN 76 1223-PST
From: Mitchell, J, Goodwin, N
Sender: GOODWIN at USC-ISI
Subject: MSGGROUP# 257 Primitive Commands
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]12-JAN-76 12:23:52-PST.GOODWIN>


Presumably, we are discussing commands which are basic (i.e.,
primitive) to any message system rather than those which might
be associated with primates(archbishops or the highest order of mammals)

Summarize and Next seem to us to be modifications on Print.
Stefferud's suggestions of File and Get seem highly desirable.  The
following list results.

Print	with a special subcase, Print.Summary.  Also, if the argument
	contains more than one message, the normal operation should
	require a Next signal to initiate printing of each message
	after the first.

Reply	Which, with a null argument has the effect of Compose.
	This might be reasonable if most messages are thought to be
	in reply to previous ones.. Otherwise, Compose should be the
	basic command and Reply a special variation.

Send/Forward
	Send is the preferred version, but either could be applied to 
	both messages received  and messages generated locally.  If
	applied to received messages, copies should NOT be sent to 
	the addressees in the various Copy fields.

File

Get

Quit

Delete	How often is the Undelete command used?  If it isn't used often,
	why do we distinguish between Delete and Expunge?  If it is 
	used often, why?
-------

10-MAY-78 22:11:36-PDT,1051;000000000001  
Reader-Id: 8
Date: 12 JAN 76 1437-PST
From: FARBER at USC-ISI
Sender: FARBER at USC-ISI
Subject: MSGGROUP# 258 Some comments on Primative Commands
Action-to: STEFFERUD
CC: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]12-JAN-76 14:37:48-PST.FARBER>


At the  meeting  of  the  Message  Services  Committee,  I argued
against the inclusion  of  the  FILE  facilities in the Primative
Command set for  a  number  of  reasons.  Some  of  these are the
difficulty for a novice user  of  a system to understand the file
system that underlies  the  system.  If  we  are  talking about a
spectrum of mail processing programs  on say just TENEX then that
disappears as an argument. If ,  however , we are talking about a
spectrum of systems as  well  then  it  will  require the user to
understand the underlieing  systems  conventions. In addition the
FILE features will  escalate  rapidly  due  to  the  need to move
objects etc. PUT and MOVE of MSG etc.

Thus I would just be cautious about opening the door.

Dave
-------

10-MAY-78 22:11:37-PDT,806;000000000001   
Reader-Id: 9
Date: 12 JAN 76 1512-PST
From: ELLIS at USC-ISI
Sender: ELLIS at USC-ISI
Subject: MSGGROUP# 259 Your question on "Quit" function
Action-to: STEFFERUD
CC: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]12-JAN-76 15:12:07-PST.ELLIS>

STEF:  

The Committee failed to discuss one style of  "Quit"  versus  another.
However,  there  was  some  intent  to  make this core set of commands
reasonably complete logically.  Therefore the  "Quit"  would  have  to
clean up or there is a basic function missing.  

Also, the Committee concluded that the list should  not  include  file
manipulation functions.  That once a user gets to this level of use he
should open the manual.  File functions bring up the need to  explain,
or know, file naming conventions, etc.  
-------

10-MAY-78 22:11:37-PDT,773;000000000001 
Reader-Id: 10
Date: 12 JAN 76 1521-PST
From: DCROCKER at USC-ISI
Subject: MSGGROUP# 260 Including a FILE command in primitive set
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 1 14) (14 53 53) "PST").STEFFERUD>

One reason for including a File command is to make it easier for
multi-system users to remember the basic command word.  Understanding of
the underlying file system is therefore a separate issue.

Another reason for inclduing the command is to attempt to "guarantee"
that a naive user will not have to work very hard to learn the command
invocation term.

A system does not have to be required to provide the command.
Rather, it may be required to use the particular term IFF the function is
provided.

Dave.
-------

10-MAY-78 22:11:37-PDT,1109;000000000001    
Reader-Id: 11
Date: 13 JAN 76 1115-PST
From: UCSB at USC-ISI
Subject: MSGGROUP# 261 Comment on FILEing commands in message systems
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-2-((76 1 14) (14 53 55) "PST").STEFFERUD>

Gee, it sure would be nifty if message systems could contain a complete
set of internal file manipulation commands, with no need to interact
at the executive level.  But, alas, we are at the mercy of the operating
system (and "operators" system too).  For we find ourselves being ARCHIVED,
DEL'd, DELVER'd, and EXPunged out of existence.  Who has not used COPY or TC
to get a quick look at a message file.  Who has not fiddled with PERPETUAL or
NOT PERPETUAL to insure against that dread foe, the file gobbler, "ARCHIVE"!.
Who has not committed the mortal sin of using a standard text editor
to manipulate sections of a received message?  Who has not used
RENAME to juggle around "boxes" of filed messages??


If File manipulation commands are to be a part of message systems, then
all of these problems need to be considered.

John Pickens
-------

10-MAY-78 22:11:37-PDT,2387;000000000001 
Reader-Id: 12
Date: 14 JAN 76 1147-PST
From: WATSON at BBN-TENEXB
Sender: WATSON at BBN-TENEXB
Subject: MSGGROUP# 262 A Data Point on File Commands in Application System
Action-to: Perlingiero at BBN-TENEX, Hornish at BBN-TENEX, 
Action-to: Heitmeyer at BBN-TENEX, Gilbert at BBN-TENEX, WATSON, 
Action-to: FEINLER, Myer at BBN-TENEXA, Mooers at BBN-TENEXA, 
Action-to: Henderson at BBN-TENEXA, Burchfiel at BBN-TENEXA, 
Action-to: Broos at USC-ISI, Bryan at USC-ISI, PBaran at USC-ISI, 
Action-to: MsgGroup at USC-ISI, Pirtle at I4-TENEX, Tom at CCA-TENEX, 
Action-to: Stefferud at USC-ISI, Spivey at USC-ISI, 
Action-to: McLindon at USC-ISI, Kirstein at USC-ISI, 
Action-to: Goodwin at USC-ISI, Farber at USC-ISI, DCrocker at USC-ISI, 
Action-to: White at USC-ISIC, Vittal at USC-ISIB, Stotz at USC-ISIB, 
Action-to: Ellis at USC-ISIB, UCSB at USC-ISI, Walker at USC-ISI, 
Action-to: Tasker at USC-ISI, Ryland, Mealy, Pogran at MIT-MULTICS, 
Action-to: Vezza at MIT-DMS, Stone at OFFICE-1, Panko at OFFICE-1, 
Action-to: SMartin at OFFICE-1, Grobstein at OFFICE-1, 
Action-to: Engelbart at OFFICE-1, Dames at OFFICE-1, BRD at RAND-RCC, 
Action-to: Anderson at RAND-RCC, vonGehren at OFFICE-1, 
Action-to: Uhlig at OFFICE-1, Taylor at OFFICE-1, 
Action-to: Robertson at RUTGERS-10, Kohanski at RUTGERS-10, 
Action-to: Sutkowski at UTAH-10, Geoff at SRI-AI
Message-Id: <[BBN-TENEXB]14-JAN-76 14:47:03-EST.WATSON>

It may be relevant to discussion on whether or not to include file commands in message  core set to indicate the following esperience.
When we converted  from NLS 7 to NLS 8 we had considerable discussion as to whether or not it would be useful to include some of the Tenex Exec type commands at the NLS level.
We decided to try it as an experiment and if it did not seem to be useful to pull them out. Experience has been very favorable to having put them in even though it is very easy to go back and forth from NLS to the Tenex Exec. It has the further advantage in that as the system moves across operating system boundaries the commands will stay the same and the user will not have to learn them in other operating systems if he does not want to.
Others in the msggroup have used both NLS 7 and NLS 8 and so can indicate their feelings on the usefulness of moving Exec type commands up to the Application System. Regards Dick
-------

10-MAY-78 22:11:37-PDT,2957;000000000001 
Reader-Id: 13
Date: 14 JAN 76 1201-PST
From: WATSON at BBN-TENEXB
Sender: WATSON at BBN-TENEXB
Subject: MSGGROUP# 263 Verb Noun Command Form
Action-to: Perlingiero at BBN-TENEX, Hornish at BBN-TENEX, 
Action-to: Heitmeyer at BBN-TENEX, Gilbert at BBN-TENEX, WATSON, 
Action-to: FEINLER, Myer at BBN-TENEXA, Mooers at BBN-TENEXA, 
Action-to: Henderson at BBN-TENEXA, Burchfiel at BBN-TENEXA, 
Action-to: Broos at USC-ISI, Bryan at USC-ISI, PBaran at USC-ISI, 
Action-to: MsgGroup at USC-ISI, Pirtle at I4-TENEX, Tom at CCA-TENEX, 
Action-to: Stefferud at USC-ISI, Spivey at USC-ISI, 
Action-to: McLindon at USC-ISI, Kirstein at USC-ISI, 
Action-to: Goodwin at USC-ISI, Farber at USC-ISI, DCrocker at USC-ISI, 
Action-to: White at USC-ISIC, Vittal at USC-ISIB, Stotz at USC-ISIB, 
Action-to: Ellis at USC-ISIB, UCSB at USC-ISI, Walker at USC-ISI, 
Action-to: Tasker at USC-ISI, Ryland, Mealy, Pogran at MIT-MULTICS, 
Action-to: Vezza at MIT-DMS, Stone at OFFICE-1, Panko at OFFICE-1, 
Action-to: SMartin at OFFICE-1, Grobstein at OFFICE-1, 
Action-to: Engelbart at OFFICE-1, Dames at OFFICE-1, BRD at RAND-RCC, 
Action-to: Anderson at RAND-RCC, vonGehren at OFFICE-1, 
Action-to: Uhlig at OFFICE-1, Taylor at OFFICE-1, 
Action-to: Robertson at RUTGERS-10, Kohanski at RUTGERS-10, 
Action-to: Sutkowski at UTAH-10, Geoff at SRI-AI
Message-Id: <[BBN-TENEXB]14-JAN-76 15:01:20-EST.WATSON>

Watching the number of commands in Mailsys grow and seeing daily suggestions for new ones I would like to bring up the subject again of the utility to the user of grouping commands in "verb noun type form" as an aid to the users comprehension and use of the system.
There are certain actions write, move, delete,replace etc that apply or could apply to several message entities, files, fields, messages, paragraphs, pages or whatever and going to a two or n dimensional command language form minimizes the number of concepts the user has to learn.
It also reduces letter conflicts in command specification etc.
Dave Crocker has brought the subject up a couple of times and I mentioned it in the paper I put in the group dialog on experience with the NLS user interface, but have not seen much discussion  pro or con, but a continuing  single command word orientation. For systems with as many commands as message systems seem to be acquiring, I think something like this is essential if the user is to not be overwhelmed with different command words for commands of the same verb function on different entities.
Also while I'm on the horn, I think use of the Frontend system  we have built for the NSW that now runs on the 10 and allows very easy fast low cost experimentation with user interfaces would be very useful to hook up with msg or mailsys "Backends". Such could be done in a few days at most I think and could allow us to try more and talk less. If anybody is interested let me know and more info can be supplied. Dick
-------

10-MAY-78 22:11:37-PDT,2129;000000000001    
Reader-Id: 14
Date: 14 JAN 76 1452-PST
From: GROBSTEIN at OFFICE-1
Subject: MSGGROUP# 264 more on primitives
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 1 14) (15 38 51) "PST").STEFFERUD>


there  has  been  a  great  deal  of discussion within msggroup on the
appropriate primitive commands.  the purpose  of  my  comments  is  to
record a viewpoint and a "vote" rather than to provide new insight.  

in order for a standard to be meaningful it must be complete enough to
provide  the  "basic" user with the minimum commands needed to use the
message system on a  day  to  day  basis.   if  this  minimum  is  not
available,  augmentation  of  the  "primitive"  set  will be so widely
needed  and  so  diversely  implemented  that  the  standard  will  be
meaningless.   in my opinion, the minimum set should be that needed by
the  non  computer  oriented  user--but  one  who  really   needs   to
communicate using the message system.  

concerning  the  specific  proposed  primitives,  i  think   NEXT   is
unnecessary  and  quit  should  be relegated to the simple function of
terminating the session.  the rest of the commands are needed.  

a  command having the function of OVERWRITE in msg is needed and in my
opinion must be separate from the QUIT command.  one must be  able  to
update his message file independently of terminating the session.  

i do NOT agree that the "casual" user can or should be protected  from
file  commands.   filing  in  the  normal  sense  of placing things in
appropriate groupings is a notion that anyone that has  to  deal  with
messages  is  likely  to  be  comfortable with.  furthermore a message
system that only allows one to  continue  to  accumulate  messages  or
throw them away entirely probably has a very brief useful life for any
new user.  whatever the hazzards that come with it, i think  that  the
commands  MOVE (or PUT), READ, and LIST, with the functions they carry
in msg are essential.  

it occurs to me that this is the first entry i've made to the MsgGroup
dialog.  hello to all.  dave 
-------

10-MAY-78 22:11:37-PDT,1927;000000000001 
Reader-Id: 1
Date: 14 JAN 76 1705-PST
From: WATSON at BBN-TENEXB
Sender: WATSON at BBN-TENEXB
Subject: MSGGROUP# 265 Confession of a Naive Mailsys User
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[BBN-TENEXB]14-JAN-76 20:05:37-EST.WATSON>

I finally learned by folklore why my messages to a distribution
list from a file arrive with all the addresses explicitly listed.
I deleted the text from Stef's nicely supplied list through the
colon, thinking things would not work if I left it on.  Hopefully
this arrived in better form.  

While I am confessing it may be useful to the primitive discussion
to indicate that I also only tend to use the following mailsys
commands.  read, survey, mailer, sndmsg, forward, quit.  

I would like to be able to do a reply to and have distribution
defaulted and there probably is a way, but can't see how from
skimming the material printed when I type help.  

I bring my mail once a day into NLS for further manipulation.  

I am used to NLS breaking my lines so have a hard time remembering
to put in CRs so my messages print funny on peoples printers whose
printer drivers don't break at 72 characters.  

It would be nice if I could get mailsys to put breaks at 72
characters in for me, maybe it already exists and have not gone
deep enough into the help information.  Maybe its the format
command, but to use it I would have to abandon my nice comfortable
simplminded use of the sndmsg command.  

Finally I do not know how to use XED or TECO so when I make typos
and grammatical errors I'm stuck if I've gone beyond the point.  I
either have to learn how nls could be an option in editor of
choice or learn one of the others.  Is there a spec published that
might allow me to see what would be involved to interface nls?  

Do others have similar problems or am I alone in the message
wilderness.  

Regards 

Dick 

------- 

10-MAY-78 22:11:38-PDT,4506;000000000001  
Reader-Id: 2
Date: 14 JAN 76 1854-PST
From: WALKER at USC-ISI
Subject: MSGGROUP# 266 Primative Command Names
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 1 19) (23 9 2) "PST").STEFFERUD>

The dialog of late has been very interesting. I recall that I put a 
17 Jan deadline on comments on the list of primative command names.
We are unlikely to be in a position to wrap this up in two days but it
is important to agree on some things and press on. There has been little 
comment on the basic command list itself, most of the talk has been on
extensions. Perhaps we need a basic list and extensions.

Let me say a few words on an overall strategy which I think we must 
adopt for future message service development. The Message Committee
is laboring to develop mechanism to allow the distribution of
structured messages instead of the present sequential text format. The 
advanced message services now being implemented need the power of structured
message fields. Because of the rich set of commands these services provide,
they also require command completion approaches that are more flexible then
those in use by many current services such as MSG. But .. we have a large
and growing number of satisfied customers of such services as Msg.

We must make the shift to a better message distribution mechanism but as
soon as we do, many current services such as Msg will no longer be usable.

I see a two step process over the next 12 to 18 months to get where we
want to be. We need to get the user population used to the mechanisms
such as command completion that will be needed in the future. But no one
wants to change the way they do things, so we must offer improvements and 
demand change as the price to pay to get the improvements. Once we have 
shifted the user population over to more flexible user interface mechanisms,
then it will be eaier to transfer them to the more advanced message services
and then, the switch to improved message delivery mechanisms can be
made without the user even knowing about it.

Let me explain what all that means: 
The Message Committee concluded ater much discussion that single letter
automatic command completion (while convenient in simple message systems)
just wouldn't work in a richer environment. The notion of typing single 
or multiple letter commands followed by a command completion character
such as space bar, cr, or esc was felt to be inevitable.

I have asked for a new version of Msg to be constructed which employes
this command completion mechanism. The reason for this is to wean the 
current set of Msg users over to the new approach. From there, it will
be relatively easy to transfer users to more advanced services 
which "look alot like Msg". Once this is done, the new message delivery
techniques can be implemented without massive user disruption. 

You will no doubt argue that all we have done is spread the user disruption
over a longer period of time but that is where effective "standards" efforts
come into play. First, we must agree on a basic set of command names and 
enforce that standardization. Next we must agree on the approaches to 
command completion which will be used (there will have to be more then
one since there is no way we can all agree on just one). These tasks are
MsgGroup business and I would like to get on with it.

I will ask Stef to retransmit the definitions for the basic commands which
came out a month ago plus those candidate command names that have been 
suggested since. I will invite all to vote on these lists from two points
of view: user preference and (for system implementers) the ability of
your system to implement the command name. Those names which all systems
can easily implement will be included in the basic set. Those which
some systems cannot accept will be included in an extension 
list. I'll let Stef setup the procedure for voting but suggest that
votes go directly to him for counting and not to the MsgGroup as a whole.
Let's try to do this in the next three weeks if possible.

Once this is done, we should direct attention to command completion
mechanisms. I will ask several groups to submit strawmen on which we can 
vote (to avoid a free for all).

I welcome comments on this approach either to me or to the group. We 
need an organized approach to implementing the advanced message services
we all want. You help is badly needed and greatly appreciated.Steve
-------

10-MAY-78 22:11:38-PDT,1900;000000000001   
Reader-Id: 3
Date: 15 JAN 76 1025-PST
From: GROBSTEIN at OFFICE-1
Subject: MSGGROUP# 267 re:walker on primitives & non-simple systems
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-2-((76 1 19) (23 9 2) "PST").STEFFERUD>


steve (and MsgGroupers),

i got an uncomfortable feeling reading your 14 jan message on the 
transition to more advanced message services.  the logic 
supporting movement away from single letter message system
commands (in order to be able to provide a richer command environment)
is certainly reasonable.  most of us would like more advanced features
and have welcomed past extensions.  i don't doubt that a vote among
the message community would strongly support the proprosed "progress"
toward more advanced but more complex systems.  

what concerns me is the knowledge that there is a group of very
unsophisticated message system users out there, and the strong suspicion
that they better characterize future message system users (and the 
future for message systems) than the present user population does.
i am refering to users who accept sndmsg, reject all editors, and move
reluctantly into msg because of the overwhelming need to creat some
order out of the chaos of an overflowing mailbox.  the transition to
"richer" systems must be made with this growing population in
mind.  attention must be paid not only to weaning the current, 
relatively technically oriented, message users, but also to those 
who will come on-board later as this whole notion grows.

the point is not that progress should be dampened, but that there should
be a determined effort to keep the "entry fee" low.  new systems
designs must allow the casual, or skeptical, or (most importantly)
the non computer oriented user to get started with a small investment
of time and effort and insight.  

                             dave
-------

10-MAY-78 22:11:38-PDT,1918;000000000001
Reader-Id: 5
Date: 15 JAN 76 1914-PST
From: WALKER at USC-ISI
Subject: MSGGROUP# 268 Novice Message System Users
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-3-((76 1 19) (23 9 3) "PST").STEFFERUD>

Mail from USC-ISI rcvd at 15-JAN-76 1908-PST
Date: 15 JAN 1976 1902-PST
From: WALKER
Subject: Re: re:walker on primitives & non-simple systems
To:   GROBSTEIN at OFFICE-1
cc:   WALKER

In response to your message sent 15 JAN 1976 1025-PST

Dave,

Your point is well taken and, risking possible offense of MsgGroup
members, it is the novices (non-computer types) that I am most concerned
about in the steps I am advocating. If only computer types were involved,
I would not worry at all about the transition to structured messages
(we've been through much worse than that). But the impact on novices 
could be very bad. This is why I have been insisting that all message
systems must have a simple user interface for the novice, with the
flexibility to allow more complex interactions as the novice grows
in need/ability. MSG provides an excellent example of the simple
user interface but is restrictive in growth potential. 

If we are careful about the design of the user interface, new users
will accept the new conventions we adopt. Inorder to make the transition 
to improved message delivery systems, and not be stuck with having to 
maintain two delivery mechanisms forever, we must convince the "old"
novices that things will be better in the new world. 

My motivation in all this is to avoid future chaos as more and more
non-computer types come on the net. What I am advocating is an orderly
approach to the transition which must eventually come. The first step
is a basic set of primative command names which all can identify with and
use easily. The next step is command specification mechanisms which 
work the same way.

Steve
-------
-------

10-MAY-78 22:11:38-PDT,2083;000000000001
Reader-Id: 6
Date: 19 JAN 76 0854-PST
From: FARBER at USC-ISI
Sender: FARBER at USC-ISI
Subject: MSGGROUP# 269 What is the intended audience
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]19-JAN-76 08:54:39-PST.FARBER>




Since  I  feel  that we have still not resolved the issue, I would again
like to question the audience that the "primative or novice" command set
is intended for.  I can see at least a four way split.  These are:  

1.  The Novice Non-computer type who will enter  the  message  subsystem
via  possibly  direct  limited  access  after  login,  that is the login
program will invoke the MAILSYSTEM and  thus  the  user  will  not  know
anything about the system he is on beyond how to login.  

2.  The Novice Mailsystem user...  He knows how to use computers but not
how to use mailsystems.  

3.  The Computer oriented experienced user 

4.   The manager (non computer type) who is experienced with mailsystems
but not with operating systems and maybe not with anything not  supplied
via the MAILSYSTEM .  

It is with the above distinctions in mind that I raised the issue of the
applicability  of  FILE  features in the novice set.  Group #1 will need
much more care and instruction if they must deal with the properties  of
a non-friendly file system.  What do you tell him when he gets a message
that the VTOC is interlocked when  all  he  wanted  to  do  was  save  a
message.   We  can  give  him  such features and WILL HAVE TO inorder to
satisfy group 4.  But it will be a major task in our MAILSYSTEM  designs
to  isolate him from the programmer oriented comments of the underlieing
operating systems.  None of our current systems do very well at this.  

I  would  also point out that group 4 will be the most difficult group .
They have lost the novelty of the mailsystems  and  are  trying  to  get
their work done.  This group will need both careful analysis and all the
technological aid we can  create  (such  as  Intelligent  Terminals  and
perhaps a bit of AI ) 

Dave 
-------

10-MAY-78 22:11:38-PDT,1474;000000000001    
Reader-Id: 1
Date: 20 JAN 76 1332-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 270 Advanced Rescue Technology
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 1 20) (14 53 43) "PST").STEFFERUD>

Mail from OFFICE-1 rcvd at 20-JAN-76 1250-PST
Date: 20 JAN 1976 1253-PST
From: GROBSTEIN at OFFICE-1
Subject: rescuing msgs from sndmsg (more)
To:   stefferud at ISI, uhlig
cc:   grobstein

stef and ron,

considering our previous discusion of trying to rescue messages from
the clutches of sndmsg without losing the text, i thought you might
be interested in the following which i found in a <documentation>
file at bbnb called fool-sndmsg.doc;1.  it has an appealing simplicity!
-----------------

YOU CAN FOOL SNDMSG INTO LETTING YOU EDIT YOUR MESSAGE
AS FOLLOWS:

DO NOT ENTER ANY ADDRESSES WHEN ASKED FOR "USERS:" -
I.E. JUST TYPE AN END-OF-LINE. YOU WILL BE ASKED
FOR THE SUBJECT AND MESSAGE AS USUAL.
WHEN YOU TYPE ^Z AT THE END OF THE MESSAGE, SNDMSG WILL SAVE
THE TEXT ON MESSAGE.COPY AS USUAL, BUT WILL
BE UNABLE TO SEND IT BECAUSE YOU GAVE NO ADDRESSES.  IT
WILL THUS GO BACK AND ASK FOR "USERS:".
IF YOU JUST ENTER THE ADDRESSES, THE MESSAGE WILL BE SENT
AS USUAL.
IF YOU WANT TO EDIT YOUR TEXT, HOWEVER, YOU CAN ^C OUT OF SNDMSG,
EDIT THE MESSAGE.COPY, THEN RUN A FRESH SNDMSG AND INSERT
THE EDITED FILE WITH ^B.


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

neat, what?

regards,    dave
-------
Enjoy,    Stef
-------

10-MAY-78 22:11:38-PDT,5048;000000000001
Reader-Id: 2
Date: 20 JAN 76 1406-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 271 Situation as of 20 JAN 1976
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-2-((76 1 20) (14 53 48) "PST").STEFFERUD>

Per Steve Walker's request that I assemble the votes on
"primitive" or "core" or "basic" commands, I have reviewed the
message traffic on the subject and find that we have constructed a
nicely complex problem space to get lost in.  To sort out the
issues, I want to send a set of separate messages to explain where
we seem to be at and to frame the "ballot" so you can vote.  If
possible, I would like to display my perception of the latent
consensus position of the group so you can react to the more
important issues without beating dead horses.  

My first comments focus on the question:  "What are we trying to
do?" 

Answer:  We are trying to proceed in an evolutionary way to a
rich, ppowerful, consistent, comprehensible, forgiving,
implementable set of message systems that will cater to the many
various needs of a wide range of potential future users of ARPANET
Electronic Mail Systems.  

Discussion:  

There can be no argument about the need for implementability,
though there may not be full agreement about which things are
implementable and which are not.  The users are in a dificult
position to evaluate the claims of the various implementers, so
the implementers must settle it among themselves.  Resolution will
no doubt occur in the "marketplace" where customers will
eventually vote with their dollars.  Supposedly the smartest
implementers will succeed the most.  

The need for evolutionary development is not arguable.  Who really
wants a revolution where-in we abandon what we have without a
viable substitute?  And who wants to stop the development where we
are now?  

The need for comprehensibility is also unarguable in principle,
but we are having a very difficult time agreeing on what this
means.  As used here, "comprehensibility" means that the user can
"get his mind around the option space" without the required
thought process interfering with his work.  To the extent that
"any idiot should be able to figure out what is right or wrong
with a little bit of thought" is adopted as a user interface
design philosophy, we will tend to create systems that force users
to think more about the Mail System than their jobs will afford.
Electronic Mail is a Means to some Ends.  

The need for a forgiving system does not appear to be universally
agreed upon, or even understood within MsgGroup.  My opinion is
that no message system command should ever allow one of its users
to irrevokably lose something of value due to a single slip of the
finger or a single wrong assumption.  I regard a wrong assumption
as being in the same class as a physical slip of the finger.  This
is why Delete and Expunge are usefully separate commands and why
it is important for certain distructive commands to require
confirmation.  It seems vital to give each individual user the
option of having "second chances" if he so chooses.  

Conlusions:  

So, Steve Walker has presented us with his evolutionary scheme for
getting to the goal from our present position.  It includes early
installation of certain command completion procedures to comply
with some stringent future requirements of network protocols for
Keyboard Interactive Systems, and progressive agreement on
standard command names and standard command behavior for various
message systems to minimize the effect of negative transfer of
training as we cross from one message system to another.  This
should also aid in the introduction of new users to the Electronic
Mail Environment with systems that let users progress to more
powerful systems without forcing them to unlearn their
introductory systems.  

With a proper evolutionary environment in place, it is intended
that we should work toward increasingly powerful systems that can
be introduced without disruption of the user population, in order
to meet the growing demands for more powerful systems from that
same user population that demands stability.  

Although it is certainly too late to avoid disruption of the
current users, it is clearly not as late as it will be later.  We
should get as much of this change-over done as soon as possible to
minimze the number of people who must suffer conversion.  

In keeping with all this evolutionary stuff, it appears to be
vital to get on with the adoption of standard names for as many
commands as possible in the shortest possible time 

Therefore:  We should immediately agree on as many "basic set"
command names as possible, leaving a second set of "extensions"
for early consideration and adoption, with the balance defered
till later.  We should vote on which "set" each candidate command
should belong to so we can establish the basic set within the
week.  Let's agree on a base and start building!  

Comments?  Stef 
-------

10-MAY-78 22:11:39-PDT,1384;000000000001    
Reader-Id: 5
Date: 21 JAN 76 1224-PST
From: RYLAND
Sender: RYLAND
Subject: MSGGROUP# 272 ASSEMBLY OF RELEVANT MESSAGES FROM PAST; A REQUEST
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISID]21-JAN-76 12:24:01-PST.RYLAND>
Special-Handling: NOTE THE REQUEST FOR COMMENTS TO FUTURE IMPLEMENTORS



Msggroupers:
After following the recent dialogue, I very strongly feel the need
to review past dialogue with respect to the current action.  Since
the Proceedings file in [ISI]<Msggroup> is nearly 300 Tenex pages, this
could be quite an undertaking.  So I'm requesting Stef to assemble
the relevant messages from the past, and make the assembled file of
messages available via FTP.  Can I get any seconds for this motion?

Also, thinking ahead a little, to the point when we, or someone, has
to implement the systems under proposal, and being a Tops-10 "captive",
I would like to make very public the request that all implementation
efforts for PDP-10's be as operating system independent as possible.
I.e., we should certainly be able to write the 'core' system for a
10, independent of Tenex or Tops, and have the respective operating
system interfaces supplied by the interested parties.  I volunteer
as a coordinator, at least initially, for any such 10 implementation
efforts,
joint to all 10s.  Any comments?

Cheers,			Chris

-------

10-MAY-78 22:11:39-PDT,531;000000000001   
Reader-Id: 6
Date: 21 JAN 76 2334-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 273 MsgGroup Membership Changes
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 2 6) (12 32 1) "PST").STEFFERUD>

MsgGroup Members should change SMartin@OFFICE-1 to SMartin@BBNB,
and add Barnes@CMUA, Newcomer@CMUA, Wactlar@CMUA, and Wulf@ISIB.  

A new copy of the official list in [ISI]<MsgGroup>MAILING.LIST is
available via FTP or by request to MsgGroup@ISI or to
Stefferud@ISI.  

Thank you, Stef 
-------

10-MAY-78 22:11:39-PDT,5296;000000000001  
Reader-Id: 7
Date: 22 JAN 76 0020-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 274 List of Primitive Command Related Messages
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-2-((76 2 6) (12 32 3) "PST").STEFFERUD>

Here is my first aproximation to the reference list of MsgGroup
messages related to the discussion on Primitives as requested by
Chris Ryland.  While you all are reviewing these, please notify me
of any relevant messages that you feel should be included.  I will
collect your additions and place them into this special
[ISI]<MSGGROUP>PROCEEDINGS.PRIMITIVES file for your access.  I
will also send you a headers listing of the additions.  

Comments?  Stef 


 -- Messages from file: [USC-ISI]<MSGGROUP>PROCEEDINGS.PRIMITIVES;2
		 -- THURSDAY, JANUARY 22, 1976 00:07:58-PST --

   1   19 JUN  ELLIS at USC-ISI      MSGGROUP# 28 COMMAND MNEMONICS
                                     (801 chrs)
   2   20 JUL  WALKER at USC-ISI     MSGGROUP# 97 MsgGroup vs Message 
                                     Committee (1823 chrs)
   3   23 NOV  DCROCKER at USC-ISI   MSGGROUP# 213 Envelopes
                                     (888 chrs)
   4   24 NOV  UHLIG at OFFICE-1     MSGGROUP# 214 Re Farber's message 
                                     on "Envelopes" (884 chrs)
   5    1 DEC  PANKO at OFFICE-1     MSGGROUP# 216 Standards and Lack 
                                     of Standards in Message Headers
                                     (1515 chrs)
   6    2 DEC  To:  [ISI]<MsgGroup>M MSGGROUP# 218 MsgGroup Situation 
                                     Report: PREFACE (779 chrs)
   7    2 DEC  To:  [ISI]<MsgGroup>M MSGGROUP# 219 MsgGroup Situation 
                                     Report #1: I. BACKGROUND
                                     (3059 chrs)
   8    3 DEC  To:  [ISI]<MsgGroup>M MSGGROUP# 220 MsgGroup Situatation
                                     Report #1: CURRENT SITUATION
                                     (3339 chrs)
   9    9 DEC  STEFFERUD at USC-ISI  MSGGROUP# 224 MSGGROUP SITUATION 
                                     REPORT #1: III. ISSUE MATRIX
                                     (4538 chrs)
   10  15 DEC  STEFFERUD at USC-ISI  MSGGROUP# 227 MSGGROUP SITUATION 
                                     REPORT #1: IV. ISSUE MATRIX 
                                     SUBCATEGO (3479 chrs)
   11  16 DEC  ELLIS at USC-ISI      MSGGROUP# 228 MESSAGE FUNCTIONS
                                     (1637 chrs)
   12  17 DEC  WALKER at USC-ISI     MSGGROUP# 229 Message Service 
                                     Primative Commands (1296 chrs)
   13  18 DEC  NGOODWIN at BBN-TENEX MSGGROUP# 230 Message Service 
                                     Primitive Commands (1086 chrs)
   14   2 JAN  STEFFERUD at USC-ISI  MSGGROUP# 247 Obtaining RFC#680 
                                     and other RFCs (2226 chrs)
   15   8 JAN  FITZPATRICK at BBN-TE MSGGROUP# 252 REF: DCROCKER AND 
                                     UHLIG ON "ENVELOPES" (2159 chrs)
   16   9 JAN  STEFFERUD at USC-ISI  MSGGROUP# 253 Message Function 
                                     Primative Commands (4027 chrs)
   17  12 JAN  GOODWIN at USC-ISI    MSGGROUP# 257 Primitive Commands
                                     (1490 chrs)
   18  12 JAN  FARBER at USC-ISI     MSGGROUP# 258 Some comments on 
                                     Primative Commands (1051 chrs)
   19  12 JAN  ELLIS at USC-ISI      MSGGROUP# 259 Your question on 
                                     "Quit" function (806 chrs)
   20  12 JAN  DCROCKER at USC-ISI   MSGGROUP# 260 Including a FILE 
                                     command in primitive set
                                     (773 chrs)
   21  13 JAN  UCSB at USC-ISI       MSGGROUP# 261 Comment on FILEing 
                                     commands in message systems
                                     (1109 chrs)
   22  14 JAN  WATSON at BBN-TENEXB  MSGGROUP# 262 A Data Point on File
                                     Commands in Application System
                                     (2387 chrs)
   23  14 JAN  WATSON at BBN-TENEXB  MSGGROUP# 263 Verb Noun Command 
                                     Form (2957 chrs)
   24  14 JAN  GROBSTEIN at OFFICE-1 MSGGROUP# 264 more on primitives
                                     (2129 chrs)
   25  14 JAN  WATSON at BBN-TENEXB  MSGGROUP# 265 Confession of a 
                                     Naive Mailsys User (1927 chrs)
   26  14 JAN  WALKER at USC-ISI     MSGGROUP# 266 Primative Command 
                                     Names (4506 chrs)
   27  15 JAN  GROBSTEIN at OFFICE-1 MSGGROUP# 267 re:walker on 
                                     primitives & non-simple systems
                                     (1900 chrs)
   28  15 JAN  WALKER at USC-ISI     MSGGROUP# 268 Novice Message 
                                     System Users (1918 chrs)
   29  19 JAN  FARBER at USC-ISI     MSGGROUP# 269 What is the intended
                                     audience (2083 chrs)
   30  20 JAN  STEFFERUD at USC-ISI  MSGGROUP# 271 Situation as of 20 
                                     JAN 1976 (5048 chrs)


-------

10-MAY-78 22:11:39-PDT,4814;000000000001    
Reader-Id: 8
Date: 22 JAN 76 0115-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 275 Requirements for Agreement on Primitives
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-3-((76 2 6) (12 32 6) "PST").STEFFERUD>

    This is the second message in preparation for voting on the
basic core primitive commands that MsgGroup is trying to agree
upon.  The first message described the general situation.  This
message tries to establish the requirements for agreement on the
"basic set." It seems that we need the following:  

1.  Agreement on a "standard structural schema" for message system
command languages.  

2.  Agreement on the command names in:  

        2.a.  a "basic set," 

        2.b.  an "extension set," and 

        2.c.  some "proposed extensions." 

3.  Agreement on the "behavior specification" of commands in:  

        3.a.  the "basic set," and 

        3.b.  the "extension set." 

4.  Agreement on "standard fields" of "processable" messages.  

5.  Agreement on "processing" of:  

        5.a.  "standard fields," and 

        5.b.  "non-standard fields." 

DISCUSSION 

    Although agreement on a standard structural schema for command
languages for all message systems may seem impossible, it appears
that we are about to impose a standard whether we intend to or
not.  The basic choice appears to be between a "single level"
structure and a "hierarchical strucure." 

    The single level structure would have a separate command for
every combination of things a user may want to do, with no
subcommands.  This is more or less how MSG does it.  

    The hiearachical strucure would allow subcommands and would
look more like Mailsys, NLS, and MSGDMS.  This entails a verb-noun
or action-object construction.  

    As originally formulated by the message Service Committee, the
basic core primitives appear to establish a single level command
structure, without subcommands, which could pose serious problems
for Mailsys, MSGDMS, and NLS.  

    From the messages I have received (some public and some
private) I get the clear impression that there exists a deep
division in MsgGroup on this issue.  The division does not occur
along user/implementor lines.  I suspect that it occurs along
taste and style preference lines.  

    Given the future extensions and coming complexities, it seems
unreasonable to select a set of basic core primitives that lock
future message systems into a non-hierarchical structure.  

   The hierarchical structure argument was carried very well in a
message from Nancy Goodwin (MSGGROUP# 257) which showed that the
number of basic core primitive commands could be minimized if a
hierachical structure is used.  Dick Watson also made some good
points in his message on the "noun-verb command form." (MSGGROUP#
263) Other MsgGroup Members have made strong statements in favor
of the hierarchical form.  Perhaps there is really no strong
support for the single level form.  if so, lets get the fact
registered and also make sure that the proposed primitives core
commands do not lock us in.  

One way to avoid lock-in is to select the "basic set" in such a
way that both options are kept open.  This would imply that we
must accept a smaller set than otherwise, in order to keep the
options open.  

Agreement on "standard fields" in "processable" messages is a
somewhat new area of discussion in the primitives dialogue.  it
arises because there are some real difficulties with standardizing
the commands without standardizing the objects of those commands.  

More important, we need to agree on what our message systesm
should do with a non-standard field when it is encountered.  For
example, should it be ignored, or perhaps thrown away because it
does not conform?  It seems to me that I want my secretary to keep
any envelope that bears a strange return address so i can inspect
it at least, though I don't want it to be used as a valid address
without review or investigation.  

Though it is not clear to me that the following suggestion is
really a good one, it does point out a reasonably straight forward
way to avoid having our message systems emulate dumb people.  My
suggestion is that any field that is not recognized as standard
and valid should be moved into the text body of the message where
it can be seen but not cause trouble for anyone.  

I pose this suggestion here to provide an example of the kind of
forgiving and comprehensible system I think we should be striving
for.  Since this message is getting too long, I shall stop here
and await your comments.  My next message will delinate the
proposed commands in something resembling a ballot.  

See you in the discussions, Stef 
-------

10-MAY-78 22:11:39-PDT,217;000000000001  
Reader-Id: 9
From: SYSTEM at RUTGERS-10
Subject: MSGGROUP# 276 TEST
Action-to: 2], 
Message-Id: <[FAKE]-4-((76 2 6) (12 32 9) "PST").STEFFERUD>


THIS IS A TEST OF THE MSGGROUP MAILIN LIST. PLEASE IGNORE.


10-MAY-78 22:11:40-PDT,10983;000000000001    
Reader-Id: 10
From: RYLAND at RUTGERS-10
Subject: MSGGROUP# 277 Building Comfortable Message Systems, I
Action-to: msggroup at USC-ISI
Message-Id: <[FAKE]-5-((76 2 6) (12 32 11) "PST").STEFFERUD>




Building Comfortable Message Systems, I

     Before we vote on the basic set of standard message system
commands and objects, I would like to make explicit an assumption
that has appeared a number of times in the message group
dialogue:  to build comfortable, usable message systems, we must
keep the user as much in his normal, everyday world as possible.
In otherwords, we need to build systems which interact with a
user in "real world" terms, insofar as thisis possible in the new
context of electronic mail systems.  

     Previous discussion in these channels has often drawn
analogies to real-world objects such as "mailboxes" and
"envelopes", but I propose we radically complete the analogy.
This completed analogy is the not-so-new idea that our message
systems will be, ultimately, components of automated offices, and
thus should model closely the real world activities and objects
comprising the day-to-day operation of an office.  Only in this
way will secretaries, managers, and non-computernik message
system users be easily introduced to the new capabilities of the
proposed message systems, since these people -- as well as users
versed in the use of computers -- are already familiar with the
"office world".  Note carefully that this view is opposed to the
standard approach, viz., "we can build new message systems with a
plethora of new, often arbitrarily-chosen, commands, subcommands,
options, facilities, and capabilities, as long as we provide a
"nice" user interface with each system, that is capable of
supplying helpful information when it is neded" (deliberately
overstated to make the point).

     What am I bringing out that differs so much from the current
themes in the message group dialoge?  Basically, that we first
look hard at how we humans perform message processing tasks,
without the computer, and then build our cognitive models of
computerized message systems.  I feel we should even go so far as
to visualize a message system as a "window" into an artificial,
computer-based world, which corresponds as closely as possible to
the real world of the average user;  the terminal then becomes
the medium -- the "light" -- for viewing this artificial world.
No doubt, future automated office systems will improve greatly on
this, augmenting or replacing the terminal with an array of
audio-visual media, but for now we have to be satisfied with a
practical solution.

     Concretely, what does this mean for the current set of
proposed primitive commands and objects?  I don't know fully --
it seems the more one thinks about this question, the more
difficult it appears --, but a glance at the "real world" of
message processing might give us some ideas.  Let's base our
glance on the life of a secretary, both because the secretary
will bear the brunt of much of our design choices, and because we
all are relatively familiar with this activity.  Be forewarned
that the resulting nomenclature will be rather prosaic, but I
claim this is a big point in its favor -- we computer users are
too jargon-oriented on the whole.

                                                           Page 2


     Call our operative, a secretary, X.  When X comes in, in the
morning, he (traditionally a neutral pronoun) begins mail
processing by seeing what's been placed on the mail stack (or
mail box, or "in box") on his desk.  How does he do this?  By
"surveying unseen messages" (MAAILSYS), or by asking for the
"headers of all not-examined messages" (MSG), or by asking for a
"summary" (proposed primitive)?  Of course not;  he simply goes
through all unopened mail in his mailbox or mail stack --
immediately suggesting the terminology "go through" and "unopened
mail" or "unopened letters".  (An aside:  can we call messages
"letters", when they arrive in "envelopes", and let "messages"
refer to the missives inside, or is the current single-object
terminology too deeply ingrained?) Next, how does X normally go
through unopened letters?  By picking up and examining each one
in turn, looking at the envelope, and deciding to stack it
somewhere else on his desk for later processing (or leave it on
the mail stack), throw it away immediately on the basis of the
envelope (some mail is obviously junk mail), or open it right now
and examine it further.  During this examination, he may decide,
on the basis of the first few lines, what to do with the letter,
whether that be to answer it himself -- as in the case of an
unsatisfiable request --, pass it on to his boss -- with some
comments attached, possibly --, or again place it elsewhere for
later handling.

     Right away, several ideas come to mind.  Some sort of
general "Go Through" command would be nice, where the object gone
through can be the mailbox or mail stack, a stack or pile of
letters on a metaphorical desk, a file of letters (in the sense
of a filing cabinet, not a TENEX file or some such), etc.  The Go
Through command probably needs to be similar to the current Read
command in Mailsys, which sets up a "read list" for the object
under consideration.  Then, a "Pick Up" command would be
appropriate for printing the "envelope" of the current letter,
and some sort of identifying tag (the current message number
scheme seems alright),and then prompting for further action;  a
"Next", "Throw Out", "put in file 'ARPA Contract'", "Put on pile
A", "Open and Read", etc.  commands would then be appropriate.
If the user Opened and Read the current letter, he could then
proceed with "Next", "Comment on", "Pass to boss", "Throw out",
etc., commands.  (Of course, these are primitives, so they could
be made a part of a macro-scheme tailored to each user's pattern
of work.)

     This example brings up the Delete/Undelete/Expunge commands
question.  Wouldn't it be more natural to have commands of the
flavor "Throw out", "Pick out of the Wastebasket" (where the
Wastebasket is yet another file, albeit special), and "Empty the
Wastebasket", where the latter is regularly performed ("at
night"), somewhat like the regular expunges of the TENEX file
system.  Then, when the user said "Throw out" with respect to a
cetain message, or letter, it would disappear from the message
file under consideration, and show up in the Wastebasket.  This
seems more natural than having a "Deleted Message" hang around in
a fileuntil an "expunge" is done on the file.  Or, if X discovers

                                                           Page 3


he's thrown out a useful message, he can Go Through the
Wastebasket file, and from there Put the desired message on or
into its rightful place.  "But, how prosaic!" you exclaim.  I
agree, but we have to wake up the the fact that the terms
"delete" and "expunge" can be terrifying for a neophyte computer
user, thrown into a world where "expunge" could mean a
metamorphosed sponge, for all he knows.

     Another example:  when X sits down to type a letter, will he
consider this action "composition"?  I doubt it.  Even if he is
going to compose a letter on-line, he usually has already done so
on paper or at least in his head.  I suggest instead a command of
the flavor "Type a letter", expressing physically what he wishes
to do.

     An issue that has come up before is the problem of
annotating a message.  I suggest we consider the question in a
slightly larger context, and allow a Note command (like the Text
command of Mailsys) which creates a "scratchpad page" of notes.
Then, for example, when a message is Replied to, a carbon copy
can be "left on the desk" (left in a working space) rather than
mailed to the user himself via a CC list entry (which always
seemed rather funny), and a Note concerning the original message
and its reply -- e.g., "Note:  I'd better clear this mess up
before the first of February" --, and a Staple command issued to
bind the Note, Carbon copy and the Original Message together.
This bundle could then be filed, like a message, and appear in a
survey as (something like) "Bundle:  a comment and 2 letters",
which could then be Gone Through like other objects.

     This brings up the issue of a filing system.  Although a
full automated office filing systems is beyond reach right now,
it is clear that some sort of filing system is both necessary for
all but the most trivial message processing, and is completely
familiar to most people.  The current message-file concept is
just too one-dimensional, and too operating system dependent
(specifically in the file name conventions).  I propose that we
include, as basic to any mail system, at least the rudiments of a
good filing system, structured analogously to the kinds of files
you'd find in an office.  This means, in particular, that we need
to give at least two dimensions of files (with perhaps the top
dimensions, or levels, existing as separate machine files) --
"drawers" and "folders within drawers" (each capable of holding
messages) -- and allow arbitrary text for filing names.  If we
don't do at least the latter, we're going to make movement among
various message systems intolerable for the average user.  Surely
it is not overwhelmingly difficult to implement a message filing
system directory, mapping text string names to (machine) files
and portions of files.  (It can't be as difficult as all the hair
involved with the sophisticated filters of Mailsys.)

     Enough of this rambling.  I hope my nearly peurile,
extremist stance will open our eyes to the fact that we must
leave people in the comfortable world of their everyday lives,
and I think this means, at least, more prosaic command names.

                                                           Page 4


     Although I'm not happy with the list below, I'll provide
them as a strawman for the approach espoused in this discussion.

Glance (at/Through)      summarizes the contents of a file (a
                         "drawer", "folder", "the Desk", the
                         "mail box", etc.)
(Open and) Read          marks a letter as opened, if not
                         already, and pulls out the
                         contents for the user to read
Reply (to message)
Type (a letter)          composition command
Forward (a message)
Put (in/at/on) (drawer/folder/Desk/Wastebasket)
Get (from)        "
                         move the various objects around
                         the metaphorical office space
[Throw (out)]            Necessary with the Put
                         in Wastebasket command?
Quit                     Oh well.

     I sure hope this has shed more light than any shadows it has
cast.

Chris


10-MAY-78 22:11:40-PDT,634;000000000001
Reader-Id: 11
From: RYLAND at RUTGERS-10
Subject: MSGGROUP# 278 Big Message
Action-to: msggroup at USC-ISI
Message-Id: <[FAKE]-6-((76 2 6) (12 32 14) "PST").STEFFERUD>

Stef:
The previous mail from me is a medium-sized file (four pages)
describing the thoughts I have have during this "voting" period.
I spent a great deal of time on this paper, even though it didn't
come out sounding like I would have wanted it to (isn't tht always
true?).  Could you notify the message group of its existence, and
point out that it has a good deal of bearing on the issues facing us
right now?  Thanks much, and cheers,

Chris


10-MAY-78 22:11:40-PDT,11466;000000000001 
Reader-Id: 12
Date: 29 JAN 76 0630-PST
From: RYLAND
Sender: RYLAND
Subject: MSGGROUP# 279 [Long Msg] Building Comfortable Message Systems
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISID]29-JAN-76 06:30:11-PST.RYLAND>
Special-Handling: This msg is 3 1/2 pages long!


Hi, Msggroupers:

I'm taking the liberty of sending yoou a relatively lengthy message,
(3 1/2 pages) since it is boound to be controversial, and has a great
deal to do with the current "voting" process.  I didn't get it assigned
a MsgGroup # for over two days, so rather than let it gather dust during
this more crucial time period, I'm sending it along, below.  Hope it
helps...
Chris

Building Comfortable Message Systems, I

     Before we vote on the basic set of standard message system
commands and objects, I would like to make explicit an assumption
that has appeared a number of times in the message group
dialogue:  to build comfortable, usable message systems, we must
keep the user as much in his normal, everyday world as possible.
In otherwords, we need to build systems which interact with a
user in "real world" terms, insofar as thisis possible in the new
context of electronic mail systems.  

     Previous discussion in these channels has often drawn
analogies to real-world objects such as "mailboxes" and
"envelopes", but I propose we radically complete the analogy.
This completed analogy is the not-so-new idea that our message
systems will be, ultimately, components of automated offices, and
thus should model closely the real world activities and objects
comprising the day-to-day operation of an office.  Only in this
way will secretaries, managers, and non-computernik message
system users be easily introduced to the new capabilities of the
proposed message systems, since these people -- as well as users
versed in the use of computers -- are already familiar with the
"office world".  Note carefully that this view is opposed to the
standard approach, viz., "we can build new message systems with a
plethora of new, often arbitrarily-chosen, commands, subcommands,
options, facilities, and capabilities, as long as we provide a
"nice" user interface with each system, that is capable of
supplying helpful information when it is neded" (deliberately
overstated to make the point).

     What am I bringing out that differs so much from the current
themes in the message group dialoge?  Basically, that we first
look hard at how we humans perform message processing tasks,
without the computer, and then build our cognitive models of
computerized message systems.  I feel we should even go so far as
to visualize a message system as a "window" into an artificial,
computer-based world, which corresponds as closely as possible to
the real world of the average user;  the terminal then becomes
the medium -- the "light" -- for viewing this artificial world.
No doubt, future automated office systems will improve greatly on
this, augmenting or replacing the terminal with an array of
audio-visual media, but for now we have to be satisfied with a
practical solution.

     Concretely, what does this mean for the current set of
proposed primitive commands and objects?  I don't know fully --
it seems the more one thinks about this question, the more
difficult it appears --, but a glance at the "real world" of
message processing might give us some ideas.  Let's base our
glance on the life of a secretary, both because the secretary
will bear the brunt of much of our design choices, and because we
all are relatively familiar with this activity.  Be forewarned
that the resulting nomenclature will be rather prosaic, but I
claim this is a big point in its favor -- we computer users are
too jargon-oriented on the whole.
                                                           Page 2


     Call our operative, a secretary, X.  When X comes in, in the
morning, he (traditionally a neutral pronoun) begins mail
processing by seeing what's been placed on the mail stack (or
mail box, or "in box") on his desk.  How does he do this?  By
"surveying unseen messages" (MAAILSYS), or by asking for the
"headers of all not-examined messages" (MSG), or by asking for a
"summary" (proposed primitive)?  Of course not;  he simply goes
through all unopened mail in his mailbox or mail stack --
immediately suggesting the terminology "go through" and "unopened
mail" or "unopened letters".  (An aside:  can we call messages
"letters", when they arrive in "envelopes", and let "messages"
refer to the missives inside, or is the current single-object
terminology too deeply ingrained?) Next, how does X normally go
through unopened letters?  By picking up and examining each one
in turn, looking at the envelope, and deciding to stack it
somewhere else on his desk for later processing (or leave it on
the mail stack), throw it away immediately on the basis of the
envelope (some mail is obviously junk mail), or open it right now
and examine it further.  During this examination, he may decide,
on the basis of the first few lines, what to do with the letter,
whether that be to answer it himself -- as in the case of an
unsatisfiable request --, pass it on to his boss -- with some
comments attached, possibly --, or again place it elsewhere for
later handling.

     Right away, several ideas come to mind.  Some sort of
general "Go Through" command would be nice, where the object gone
through can be the mailbox or mail stack, a stack or pile of
letters on a metaphorical desk, a file of letters (in the sense
of a filing cabinet, not a TENEX file or some such), etc.  The Go
Through command probably needs to be similar to the current Read
command in Mailsys, which sets up a "read list" for the object
under consideration.  Then, a "Pick Up" command would be
appropriate for printing the "envelope" of the current letter,
and some sort of identifying tag (the current message number
scheme seems alright),and then prompting for further action;  a
"Next", "Throw Out", "put in file 'ARPA Contract'", "Put on pile
A", "Open and Read", etc.  commands would then be appropriate.
If the user Opened and Read the current letter, he could then
proceed with "Next", "Comment on", "Pass to boss", "Throw out",
etc., commands.  (Of course, these are primitives, so they could
be made a part of a macro-scheme tailored to each user's pattern
of work.)

     This example brings up the Delete/Undelete/Expunge commands
question.  Wouldn't it be more natural to have commands of the
flavor "Throw out", "Pick out of the Wastebasket" (where the
Wastebasket is yet another file, albeit special), and "Empty the
Wastebasket", where the latter is regularly performed ("at
night"), somewhat like the regular expunges of the TENEX file
system.  Then, when the user said "Throw out" with respect to a
cetain message, or letter, it would disappear from the message
file under consideration, and show up in the Wastebasket.  This
seems more natural than having a "Deleted Message" hang around in
a fileuntil an "expunge" is done on the file.  Or, if X discovers
                                                           Page 3


he's thrown out a useful message, he can Go Through the
Wastebasket file, and from there Put the desired message on or
into its rightful place.  "But, how prosaic!" you exclaim.  I
agree, but we have to wake up the the fact that the terms
"delete" and "expunge" can be terrifying for a neophyte computer
user, thrown into a world where "expunge" could mean a
metamorphosed sponge, for all he knows.

     Another example:  when X sits down to type a letter, will he
consider this action "composition"?  I doubt it.  Even if he is
going to compose a letter on-line, he usually has already done so
on paper or at least in his head.  I suggest instead a command of
the flavor "Type a letter", expressing physically what he wishes
to do.

     An issue that has come up before is the problem of
annotating a message.  I suggest we consider the question in a
slightly larger context, and allow a Note command (like the Text
command of Mailsys) which creates a "scratchpad page" of notes.
Then, for example, when a message is Replied to, a carbon copy
can be "left on the desk" (left in a working space) rather than
mailed to the user himself via a CC list entry (which always
seemed rather funny), and a Note concerning the original message
and its reply -- e.g., "Note:  I'd better clear this mess up
before the first of February" --, and a Staple command issued to
bind the Note, Carbon copy and the Original Message together.
This bundle could then be filed, like a message, and appear in a
survey as (something like) "Bundle:  a comment and 2 letters",
which could then be Gone Through like other objects.

     This brings up the issue of a filing system.  Although a
full automated office filing systems is beyond reach right now,
it is clear that some sort of filing system is both necessary for
all but the most trivial message processing, and is completely
familiar to most people.  The current message-file concept is
just too one-dimensional, and too operating system dependent
(specifically in the file name conventions).  I propose that we
include, as basic to any mail system, at least the rudiments of a
good filing system, structured analogously to the kinds of files
you'd find in an office.  This means, in particular, that we need
to give at least two dimensions of files (with perhaps the top
dimensions, or levels, existing as separate machine files) --
"drawers" and "folders within drawers" (each capable of holding
messages) -- and allow arbitrary text for filing names.  If we
don't do at least the latter, we're going to make movement among
various message systems intolerable for the average user.  Surely
it is not overwhelmingly difficult to implement a message filing
system directory, mapping text string names to (machine) files
and portions of files.  (It can't be as difficult as all the hair
involved with the sophisticated filters of Mailsys.)

     Enough of this rambling.  I hope my nearly peurile,
extremist stance will open our eyes to the fact that we must
leave people in the comfortable world of their everyday lives,
and I think this means, at least, more prosaic command names.
                                                           Page 4


     Although I'm not happy with the list below, I'll provide
them as a strawman for the approach espoused in this discussion.

Glance (at/Through)      summarizes the contents of a file (a
                         "drawer", "folder", "the Desk", the
                         "mail box", etc.)
(Open and) Read          marks a letter as opened, if not
                         already, and pulls out the
                         contents for the user to read
Reply (to message)
Type (a letter)          composition command
Forward (a message)
Put (in/at/on) (drawer/folder/Desk/Wastebasket)
Get (from)        "
                         move the various objects around
                         the metaphorical office space
[Throw (out)]            Necessary with the Put
                         in Wastebasket command?
Quit                     Oh well.

     I sure hope this has shed more light than any shadows it has
cast.

Chris
-------

10-MAY-78 22:11:41-PDT,2643;000000000001
Reader-Id: 13
Date: 29 JAN 76 1610-PST
From: DCROCKER at USC-ISI
Subject: MSGGROUP# 280 An experiment to determine command vocabulary selection
Action-to: [ISI]<MsgGroup>Mailing.List:
CC: [USC-ECL]<DCrocker>HIC.Folk:
Message-Id: <[FAKE]-7-((76 2 6) (12 32 19) "PST").STEFFERUD>

        I have just conducted an informal experiment to determine what
word should be used for the Headers/Summarize/Survey command.  

        I interviewed three secretaries, asking them what they do, after
initially receiving a stack of mail for their boss, to determine what
the next step for processing the mail is.  This is only one of the
reasons a headers listing is used, but seemed closest to the generic
function and is the only one common to mail processing.  Things like
tables of contents (which is really what is generated) are much less
common and not at all relevant to the processing of mail.  Hence, I
opted for the standard situation in which a secretary needs to "get the
sense of" a group of mail.  

        All three secretaries followed the same description process,
including having the same problems understanding what I wanted from
them.  I believe that only part of the problem was with my language.
The other part seems to be due to the fact that the action is so
automatic, it never is consciously performed.  Note that my results are
most probably biased by my interviewing technique, which likely
channelled the responses.  For the record, I believe that the word that
describes the generic function performed is "surveying" the letter to
determine its disposition.  

        The secretaries initially said that they read the letter to
determine what should be done with it.  In each case I then asked if
they read the whole letter.  They then said (one had to fish for the
word, but did not get further prompting from me):  No, I SCAN it.  


        I therefore believe that the command word should be "Scan".  The
word has nothing to do with the atomic action of printing header
informtion, but has everything to do with WHY the information is printed
out.  It is a surrogate action, to bypass the problem of a constrained
window onto the data base.  If the window were not so constrained, the
Headers command probably would not be necessary.  

        This is the first time I have actually attempted to fully apply
the methodology I suggested some time ago and would appreciate any
comments y'all might have.  In a formal sense, my sample size was too
small for statistical significance, but that is mediated by the absolute
consistency of responses.  

Dave.  
-------

10-MAY-78 22:11:41-PDT,881;000000000001   
Reader-Id: 14
Date: 29 JAN 76 1611-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 281 ADDING DEHALL@MIT-MULTICS
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-8-((76 2 6) (12 32 22) "PST").STEFFERUD>

Mail from SRI-AI rcvd at 28-JAN-76 1609-PST
Date: 28 JAN 1976 1608-PST
From: Dehall at SRI-AI
Subject: MSG Group membership
To:   Stefferud at ISI
cc:   DEHall at MULTICS

Stef
 
I am in the process of designing a mail system for LBL.
Several people have mentioned the MSG Group as a good
source of ideas. Would you mind adding my name to the distribution
list?
My primary mailbox is DEHall@Multics. 
 
Thank you very much,
  
       Dennis
-------
DEHALL AT MIT-MULTICS HAS BEEN ADDED TO THE <MSGGROUP>MAILING.LIST.

PLEASE ADD HIM TO YOUR LIST OR GET A NEW COPY FROM [ISI]<MSGGROUP>.

SEE YOU IN THE DISCUSSIONS,   STEF
-------

10-MAY-78 22:11:41-PDT,2291;000000000001  
Reader-Id: 15
Date: 30 JAN 76 0851-PST
From: RYLAND
Sender: RYLAND
Subject: MSGGROUP# 282 Comfortable Message Systems; further comments
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISID]30-JAN-76 08:51:15-PST.RYLAND>


MsgGroupers:

I received two very helpful replies to my message "Building Comfortable
Message Systems", and I thought I should share them with you.
Ed Von Gehren pointed out that the real issue at stake for mail system
designers is not command names, but primitive functions.  I.e., we
only want to insure that an adequate set of functions is available
in future message systems, regardless of how the user invokes, or
thinks about, this set.  This insight, which I entirely missed,
somewhat weakens my argument, and I want to recognize it as such.
I mentioned, in my direct reply to Ed, that another real concern is
the question of primitive objects, again regardless of how they're named.
If we consider the primitive functions as operating on some entities
 or objects, then we have to define what those objects are.  It may
be that this is not a valid concern, if we consider the primitive
functions as operating only on messages ("letters", "missives", or
what have you).  But the fact that the function of filing mesages may
be considered primitive by some people suggests that another object,
the "file", should come under scrutiny as a possible primitive.

The other message, from Dave Crocker, pointed out a trap that I
fell into, by focussing on actions that have been molded by an
older technology, namely that of the "classical office world".
Dave also suggested that my personal biases in nomenclature and
primitive function choise shouldn't be forced on the rest of the
world.  He's right -- I should add that I wasn't providing the
ultimate answer, either.  His experiment in asking real office
workers, as documented in his message of 29 Jan 76, points the
way to a more realistic method of deciding on what actually goes
in the "office world" and how to model that world.  [Aside: I
think his discovery of the name "Scan" as the appropriate nomen-
clature for a Survey or Summary, is excellent.]

Hope this has cleared up some problems that you might spot in my
message.  Cheers,
Chris
-------

10-MAY-78 22:11:41-PDT,3180;000000000001   
Reader-Id: 18
Date: 6 FEB 76 1224-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 283 MsgGroup Commands Ballot
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 2 6) (13 41 26) "PST").STEFFERUD>

This message contains your Basic Core Primitive Commands Ballot.  

You are asked to return a message to STEFFERUD@ISI listing those
commands in the ballot that you disagree with.  Please use the
ballot item numbers in your lists.  The result should allow us to
set aside those we agree on for inclusion as basic commands in our
message systems while we continue to discuss the issues regarding
those we do not agree on.  

The objective is to quickly establish the list of basic commands
that can be safely implemented as "Basic" without worrying about
those commands that need further resolution.  This will allow the
implementers to proceed without undo delay.  There is to be no
implication that the resulting "agreed-upon-list" is anything more
than a list of command names/functions that we agree should be
included in any ARPANET Message system.  

The Basic primitive Core Commands in the ballot include those
proposed by the Message Service Committee (MSGGROUP# 228,229) plus
additional Commands suggested from the MsgGroup discussions.  

	
  1.  QUIT - [No Arguments] {No Cleanup of message file} 

  2.  SUMMARIZE - [<message sequence>; default <new messages>] 
                  {prints brief information about each message}

  3.  REPLY - [<message sequence>; default <current>] 
              {Elicits actions to compose a reply} 

  4.  FORWARD - [<message sequence>; default <current>]
                {forwards messages in a new envelope} 
                {elicits addressees, subject, and additional text}

  5.  DELETE - [<message sequence>; default <current>] 
               {Marks messages for deletion by CLEANUP} 

  6.  PRINT - [<message sequence>; default <current>] 

  7.  NEXT - [<message number>; default <current+1>] 
             {resets <current> and prints specified message}

  8.  COMPOSE - {elicits actions to compose a message} 

  9.  CLEANUP - [<current file>] {expunge messages marked for deletion}

  10. UNDELETE - [<message sequence>; default <current>]
                  {unmarks messages for deletion by CLEANUP} 

  11. FILE - [<message sequence>; default <current> : <file name>] 
             {places copies of specified messages in named file}

  12. GET - [<file name>; default <message.txt>] 
            {<current file> becomes <named file>}

  13. "FIELDS" - [each defined message field is a command] 
                  {opens buffer for type-in of "FIELD" content}

  14. SEND - [no arguments] {sends message composed of buffers}

  15. RESEND - [<message sequence>; default <current>]
                {sends existing message(s) without new envelopes
                 to newly elicited addressees}

	
If you have any questions please ask.  Comments on issues should
be sent to <MsgGroup>Mailing.List, or to Stefferud@ISI.  

Deadline for return of ballots is Wednesday, Feb 18, 1976.  

See you in the ballot box, Stef 
-------

10-MAY-78 22:11:42-PDT,435;000000000001    
Reader-Id: 19
Date: 6 FEB 76 1456-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 284 Add McDaniel@PARC-MAXC
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 2 13) (17 49 27) "PST").STEFFERUD>

McDaniel@PARC-MAXC has been added to MsgGroup.  Please
add to your list or obtain a new mailing list from [ISI]<MsgGroup>.
A copy of the mailing list may be obtained by SNDMSG request.

Best,  Stef
-------

10-MAY-78 22:11:42-PDT,977;000000000001  
Reader-Id: 20
Date: 6 FEB 76 1616-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 285 "FIELDS" Command Clarification
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-2-((76 2 13) (17 49 29) "PST").STEFFERUD>

I have been asked for clarification of what the "FIELDS" command
means on your ballot.  So here is an atttempted explanation.  

"FIELDS" means that each defined field in a message system will
have a corresponding command of the same name which will (when
executed) open the specified buffer for acceptance of typed input
from the user to fill the field.  "Defined" fields are TO:  FROM:
SUBJECT:  etc.  

I would assume that repeated execution of the same command on a
non empty buffer would result in appending additonal text, and
that the normal ^A, ^W, ^R, ^S type commands are available and
applicable to all text in the buffer, including previous
executions of the command.  

Does this leave any questions?  Stef 
-------

10-MAY-78 22:11:42-PDT,796;000000000001   
Reader-Id: 21
Date: 9 FEB 76 0804-PST
From: UHLIG at OFFICE-1
Sender: UHLIG at OFFICE-1
Subject: MSGGROUP# 286 Effect of an "Open" Ballot
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[OFFICE-1]9-FEB-76 08:04:09-PST.UHLIG>
Keywords: open  , secret, DELPHI, ballot

I wonder whether the current exercise would be affected at all
if the current ballot were "secret" (in the sense of anonymous)
rather than open.  I don't know that much about DELPHI techniques,
etc, but I think we might consider using some mechanism which
would allow the votes to be cast anonymously.  We have had some
interesting, and very good things, occur when we allowed for such
things on certain committees within DARCOM (formerly AMC - our
name has been changed).

   Ron

------- 

10-MAY-78 22:11:42-PDT,611;000000000001   
Reader-Id: 22
Date: 9 FEB 76 0919-PST
From: RYLAND
Sender: RYLAND
Subject: MSGGROUP# 287 (Effect of an "Open" Ballot)
Action-to: UHLIG at OFFICE-1, [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISID]9-FEB-76 09:19:29-PST.RYLAND>
In-Reply-To: <[OFFICE-1]9-FEB-76 08:04:09-PST.UHLIG>


Ron and all:
I just want to point out that the mechanism we could use to effect
secret balloting (more or less), is for each voter to prepare a ballot
as a text file (with no identification in the ballot), and then
use the FTP MailFile function to mail it anonymously to Stef at ISI.
Cheers,
Chris
-------

10-MAY-78 22:11:42-PDT,1052;000000000001 
Reader-Id: 23
Date: 9 FEB 76 1052-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 288 ((Effect of an "Open" Ballot))
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]9-FEB-76 10:52:15-PST.STEFFERUD>
In-Reply-To: <[USC-ISID]9-FEB-76 09:19:29-PST.RYLAND>

The balloting will in effect be more or less secret, in that I do
not plan to vote myself, and I will keep the ballots to myself.  

I expect that greater efforts to assure total secrecy would be
unprofitable.  MsgGroup consists of a mixture of Sponsors,
Vendors, Customers, Users, and Critics.  I think it will be
important to know who voted which way in the analysis.  

It occurs to me that Democracy is not what we are trying to
emulate, though unbiased indications of desires and requirements
is what we want.  If it will help, I will strip away the
identifying parts of the received ballot returns to build the
ballot archive for MsgGroup.  In the meantime, I will keep the
ballots to myself.  

Comments?  Stef
-------

10-MAY-78 22:11:42-PDT,1195;000000000001   
Reader-Id: 24
Date: 9 FEB 76 1418-PST
From: Geoff at SRI-AI
Subject: MSGGROUP# 289 re:  Effect of an "Open" Ballot
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-3-((76 2 13) (17 49 38) "PST").STEFFERUD>

In response to the message sent from Stefferud at ISI in response to the
  message sent from Ryland at ISID in response to the message sent
  from Uhlig at Office-1.

   One can not really vote ANONYMOUSLY in the true sense of the word since
our nifty Tenex FTP Server does the nice job of telling 'which' site the
mail comes from, i.e.  For everyone who is getting this message on a Tenex, 
(and even some other sites may have this feature impelented too), it says
 something to the effect 'Mail received from RANDOM-HOST at DATE-TIME'.

   Now, if I was to cast an anonymous vote from SRI-AI, being the ONLY
MsgGrouper here, that would give my identy away right off the bat, and just
taking a quick look down the Mailing-List I see several other sites where there
are only 1,2 or 3 people on that host.

   So probably the winning thing to do is what Stef suggests and just send
the votes to him and he'll keep our names a secret.
[Geoff]
-------

10-MAY-78 22:11:42-PDT,3687;000000000001 
Reader-Id: 25
Date: 10 FEB 76 0753-PST
From: RYLAND
Sender: RYLAND
Subject: MSGGROUP# 290 Re: MsgGroup Commands Ballot & Effects of Open Ballot
Action-to: STEFFERUD at USC-ISI, [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISID]10-FEB-76 07:53:57-PST.RYLAND>
In-Reply-To: <[USC-ISI]9-FEB-76 10:52:15-PST.STEFFERUD>


Stef-

In reference to  your  messages  of  6  Feb 76 (MsgGroup Commands
Ballot) and 9 Feb 76 (Effects of an Open Ballot response).

First, the latter. I agree  with  you:  the issue is not complete
secrecy, since we are  aiming  at  getting unbiased opinions, not
totally anonymous responses. Your solution sounds fine -- it will
certainly help to know  the  distribution  of responses among the
various groups of Vendors, Users, etc., and if the identification
is stripped off the ballots, that should be satisfactory to all.

Concerning the ballot itself. I'd like to ask some questions that
may help to clear up various points for us all.

Wouldn't  "Summarize"  be  better   named  "Scan",  as  per  Dave
Crocker's experimental results? I realize that nomenclature isn't
crucial right now, but we might  as  well start off with the most
natural names.

Does "Forward" forward the  entire  <message sequnce> as a group,
or does it forward  each  one  singly  (i.e. with new addressees,
subject and text for  each  message  in  the sequence)? If all at
once, then it's  unhappily  non-parallel  to  other commands like
"Read" which act on  messages  individually.  Does this argue for
two sorts of  message  sequences  --  one  a  group of individual
messages, the other a  group  of  message groups? This does dound
rather awful.

Whilst we're on the subject,  shouldn't  we specify the format of
<Msg sequence>, since  this  is  a  notion  common to all message
systems? If we don't, we  run  the  risk of making movement among
various  sytems  intolerable,  due   to   the  little  bother  of
non-standard message sequence specification methods.

What does the  format  CLEANUP  -  [<current  file>] ... mean? Is
there an optional argument that allows for any file to be cleaned
up, defaulting to the current file? If no, why not?

There's another unfortunate lack of parallel between the FILE and
the GET commands. iF you can  FILE a group of individual messages
into a file, why can't you GET  a set of messages (into who knows
where, unfortunately)?


What's the  usefulness  of  RESEND,  and  what  is the conceptual
border between RESEND anf FORWARD? Maybe I missed some references
to a  RESEND  function,  but  its  existence  in  a  basic set of
commands is not clear to me. Any help?

Finally, there's the  whole  question  of  editing characters and
control characters. For example, how  is a "FIELD" command, which
opens the names  buffer,  terminated?  By  a  ctrl-Z? If so, what
about systems like 370s that don't have control characters per se
(since they  support  half-duplex  terminals  only, usually)? The
editing characters --  ctrl-S,  ctrl-R,  etc.  --  are al fine if
you're on a TENEX system,  but  on a TOPS-10 system, they're hard
to use. Are we going  to  tackle the problem of these terminating
and editing control sequences, or  are  we going to just specify
that certain sequences exist, name  them,  and leave it up to the
individual system designer  to  use  appropriate means to achieve
them? Or are we going to just ignore the whole question?

I hope you can clear up some  of these questions for me -- I also
hope that these questions  are  not  unique to me; otherwise, I'm
wasting your time ("you" being everyone but Stef). Cheers!

Chris
-------

10-MAY-78 22:11:43-PDT,3736;000000000001  
Reader-Id: 26
Date: 10 FEB 76 0951-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 291 (Re: MsgGroup Commands Ballot & Effects of Open Ballot)
Action-to: RYLAND
CC: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]10-FEB-76 09:51:10-PST.STEFFERUD>
In-Reply-To: <[USC-ISID]10-FEB-76 07:53:57-PST.RYLAND>

Hi Chris, I think the answer to all your questions and suggestions
is yes.  As follows:  

No one has yet disagreed about the way I propose to handle the
ballots.  

The ballot assumes that FORWARD is as defined in MSG/MAILSYS to
put the group of messages sppecified in <message-sequence> into a
new envelope (ie.  new header) with all FORWARDed message(s)
"enclosed" in one package.." 

RESEND arises because some feel that we should be able to simply
send an existing message without putting it into another envelope,
to avoid masking off the header information from the receiver's
message system.  If you receive a message in a second envelope,
you can't answer its sender with ANSWER.  But, you are correct in
that there has been no direct discussion of this in MsgGroup.  The
discussion has been oblique and obscure.  Mostly it was centered
around a subgroup tryout of MSGDMS which defines FORWARD to be as
the ballot defines RESEND.  There is a real and significant
difference between them.  (I discovered it to my horror one night
when I ANSWERed a RESENT message and too late discovered my answer
going to the originator rather than the forwarder.  Think about it
for awhile.) 

Your opinions about alternatives such as SCAN for SUMMARIZE belong
in your ballot.  I prefer not to comment here.  

Specification of <message sequence> standards is probably due for
another ballot, as you suggest.  There are also some other issues
to be voted on before we are done.  I think we are proceeding in
tandem to get to them in sequence.  Hopefully, completing this
ballot will set the stage for the next.  

The specification that CLEANUP operates on the <current file>
means that it doesn't operate on all files in your directory.  I
trust you don't want it to.  However, there exists at least one
message system that keeps only one copy of all messages in a
single data base with "psuedo files" within it, so cleanup would
litterally mean "all files of messages." The problem in setting
standards here is that the two system concepts are enough
different to cause monstrous mapping problems for command
definitions.  A message system that operates on separate files as
does MSG/MAILSYS has need of file handling commands for users of
moderate sophistication.  Data base systems mask this requirement
from the user.  

FILE and GET are not simple reversals of each other.  Filing a
selected set of messages into a file folder and retreiving a file
folder so you can look in it is what the ballot referes to.  This
is the way MSG/ MAILSYS work now.  If you keep everything in one
single file, then the question is moot.  

As for control character defintions and non-TENEX systems, you
have my deepest sympathies, but I think the arguments should come
from MsgGroup members rather than from me.  I suggest you put
those comments in your ballot.  

Finally, I think we are bordering on disolving our voting process
into a new round of open discussion.  I have tried to keep this
down to "clarification" but it is not easy.  My point is that I
don't want to open a broad ranging discussion.  If the issues are
not clear enough to vote on them, let's point that out in the
ballots.  This waay we can "agree on the agreeable and discuss the
disagreable later!" (Interesting word "disagreeable." No?) 

Cheers, Stef 
-------

10-MAY-78 22:11:43-PDT,3351;000000000001  
Reader-Id: 27
Date: 13 FEB 76 1817-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 292 [PBaran on ballots and things]
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-1-((76 3 5) (19 47 14) "PST").STEFFERUD>

   1   13 FEB  To:  PBARAN           Re: Here is my ballot
   2   13 FEB  PBARAN                Here is my ballot


1 -- ************************
Date: 13 FEB 1976 1814-PST
From: STEFFERUD
Subject: Re: Here is my ballot
To:   PBARAN
cc:   STEFFERUD

In response to your message sent 13 FEB 1976 1754-PST

Paul,  I must agree with you in every regard, but you must admit that 
yours may be the longest recorded statement of abstention in captivity!

Actuall, I was trying to get everyone to let me know if they wanted to vote
or not, not caring myself either way in any case.  The more dangerous way
to go is to assume all those absent ballot mean agreements with every item!

So, since at least one person has shown that I may be misunderstood, I will 
FORWARD your message along with mine and let the MsgGroupers exercise
their DELETE commands.

Best,  Stef
-------


2 -- ************************
Date: 13 FEB 1976 1754-PST
From: PBARAN
Subject: Here is my ballot
To:   STEFFERUD
cc:   PBARAN

Dear Stef:
     I have long believed that many of the serious problems 
that afflict our world can be attributed to 
statements and positions taken by those that really little
to contribute but must say something lest they be thought
stupid or lazy or just not interested.  
     The deliberations of the MsgGroup while voluminous have
succeeded in bringing out many useful points. 
If there is any danger in having an activity of this sort 
bogging down it is the temptation to add comments solely 
to be heard.  I have to this point been able to keep my 
half formed opinions to myself.  If an when I have something 
to contribute I will ssrely use the opportunity of doing so.
     However, I would be most reluctant to toss in a 
vote that would have the same weight as someone who has
spent much time and effort thinking about these matters
and the implications of alternatives.
     Let us not be like the League of Woman Voters bugging 
everyone to get out and vote whether they know what they are
voting about or not.  In my book the fewer people that 
show up to the poles the more knowledgable the overall vote.
     Democracy is a great system.  But, averaging 
everyone's vote to determine fact and giving all votes 
equal weight is a corruption of the basic process.
     Many years ago, in another life I had reason to conduct
several Delphi studies.  I found that the most 
useful results came when you asked each person for his 
familiarity and competence to provide estimates for each 
item.  (I ran some experiments where I had the group 
evaluate the competence of others.  Self evaluation here 
was quite good.)
    Sorry for the ramble, but I did want to explain my 
silence since it was questioned.  I suspect that many others
that did not answer may think in the same general terms 
as myself.  It might be fun to ask them whether they agree
that this is their reason for silence.
(if you want to redistribute this message, permission
granted.)
Paul
-------
?For your enlightenment and entertainment, I trust?  Stef
-------

10-MAY-78 22:11:43-PDT,2926;000000000001  
Reader-Id: 28
Date: 13 FEB 76 2003-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 293 Recent msgGroup Proceedings
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-2-((76 3 5) (19 47 16) "PST").STEFFERUD>

 -- Messages from file: [USC-ISI]<MSGGROUP>PROCEEDINGS.MSG;8
		 -- FRIDAY, FEBRUARY 13, 1976 19:54:50-PST --

   187 20 JAN  STEFFERUD at USC-ISI  MSGGROUP# 270 Advanced Rescue 
                                     Technology (1474 chrs)
   188 20 JAN  STEFFERUD at USC-ISI  MSGGROUP# 271 Situation as of 20 
                                     JAN 1976 (5048 chrs)
   189 21 JAN  RYLAND                MSGGROUP# 272 ASSEMBLY OF RELEVANT
                                     MESSAGES FROM PAST; A REQUEST
                                     (1384 chrs)
   190 22 JAN  STEFFERUD at USC-ISI  MSGGROUP# 274 List of Primitive 
                                     Command Related Messages
                                     (5296 chrs)
   191 22 JAN  STEFFERUD at USC-ISI  MSGGROUP# 275 Requirements for 
                                     Agreement on Primitives
                                     (4814 chrs)
   192 29 JAN  RYLAND                MSGGROUP# 279 [Long Msg] Building 
                                     Comfortable Message Systems
                                     (11466 chrs)
   193 29 JAN  DCROCKER at USC-ISI   MSGGROUP# 280 An experiment to 
                                     determine command vocabulary 
                                     selection (2643 chrs)
   194 30 JAN  RYLAND                MSGGROUP# 282 Comfortable Message 
                                     Systems; further comments
                                     (2291 chrs)
   195  6 FEB  STEFFERUD at USC-ISI  MSGGROUP# 283 MsgGroup Commands 
                                     Ballot (3180 chrs)
   196  6 FEB  STEFFERUD at USC-ISI  MSGGROUP# 285 "FIELDS" Command 
                                     Clarification (977 chrs)
   197  9 FEB  UHLIG at OFFICE-1     MSGGROUP# 286 Effect of an "Open" 
                                     Ballot (796 chrs)
   198  9 FEB  RYLAND                MSGGROUP# 287 (Effect of an "Open"
                                     Ballot) (611 chrs)
   199  9 FEB  STEFFERUD at USC-ISI  MSGGROUP# 288 ((Effect of an 
                                     "Open" Ballot)) (1052 chrs)
   200  9 FEB  Geoff at SRI-AI       MSGGROUP# 289 re:  Effect of an 
                                     "Open" Ballot (1195 chrs)
   201 10 FEB  RYLAND                MSGGROUP# 290 Re: MsgGroup 
                                     Commands Ballot & Effects of Open 
                                     Ballot (3687 chrs)
   202 10 FEB  STEFFERUD at USC-ISI  MSGGROUP# 291 (Re: MsgGroup 
                                     Commands Ballot & Effects of Open 
                                     Ballot) (3736 chrs)
-------

10-MAY-78 22:11:43-PDT,3166;000000000001  
Reader-Id: 30
Date: 4 MAR 76 1308-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 294 Vote Tabulation
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]4-MAR-76 13:08:30-PST.STEFFERUD>
Special-Handling: To MsgGroup:  Here is a tabulaion of the vote.  Enjoy,  Stef    

First, let me try to explain how I constructed a three dimension
tabulation from a ballot that did not show three dimensions for
voting.  

The ballots sometimes needed considerable interpretation because
some NOs meant "yes, the function is good but the name is bad" or
"yes, the name and function are good but not for the BASIC command
set," etc.  (By now you should be glad you are not in the vote
counting business!) 

After processing the "yes, buts .  ." and the "no, buts .  ." I
tallied the vote on NAMEs, inclusion in the BASIC set, and
inclusion in the EXTENSION set.  You will note that there is
little difference between "not BASIC" and "not EXTENSION."
Generally, those who do not like a command function don't like it
at all!  


From my analysis of the vote, it seems reasonable that we should
pay more attention to DISAGREEments than AGREEments because of the
PBaran "bystanders observation." A fair number of voters have no
strong objections, but those who do object often have strong
opinions.  I plan to compile all the coments from the ballots, by
COMMAND NAME for your own analysis, without attribution of
comments to specific voters.  (You get to guess who said what -
good luck!) 

Conclusive results were registered for SUMMARIZE which was most
disliked as a name but unanimously agreed upon as a function.
SCAN was a popular "write-in" to replace the name, but I expect we
should vote on a proposed set of alternatives for the name.  A
list of proposed and suggested alternatives for command names will
be compiled in another message to the MsgGroup.  

RESEND is clearly not desired by a significant number voters,
especially when considered with FORWARD which is closely related.
There were some cogent comments on the FORWARD/RESEND issue.  

"FIELDS" also faired poorly in acceptance, though it seems that
most feel that access to individual field buffers is a good idea
for the EXTENSION set.  

Here is my tabulation.  Please note that the NAME tabulation only
counts those who voted to include the command function in either
the BASIC or the EXTENSION sets.  

Enjoy, Stef 
	
SUMMARY TABULATION OF BASIC COMMAND BALLOTS (27 Ballots Voted)

                                 BASIC           EXTENSION
COMMAND          NAME          FUNCTION          FUNCTION
NAME         AGREE DISAGREE  AGREE DISAGREE   AGREE DISAGREE

1. QUIT		27	0	25	2	25	2

2. SUMMARIZE	12	15	27	0	27	0

3. REPLY	25	1	23	4	26	1

4. FORWARD	19	5	24	3	25	2

5. DELETE	23	2	24	3	24	3

6. PRINT	21	6	27	0	27	0

7. NEXT		22	3	24	3	24	3

8. COMPOSE	23	4	24	3	26	1

9. CLEANUP	22	1	23	4	23	4

10. UNDELETE	21	2	23	3	24	3

11. FILE	20	3	23	4	26	1

12. GET		24	1	23	4	26	1

13. "FIELDS"	17	1	17	6	20	3

14. SEND	22	0	22	4	22	4

15. RESEND	13	3	12	13	19	6
-------   

10-MAY-78 22:11:43-PDT,3150;000000000001   
Reader-Id: 31
Date: 4 MAR 76 2124-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 295 "FIELDS"/SEND: Ballot Comments
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]4-MAR-76 21:24:02-PST.STEFFERUD>    

This message contains comments collected from MsgGroup Ballots on
Basic Command Names, for the "FIELDS" and SEND commands.  These
comments do not make easy reading, but they do convey some
important concepts and issues.

"FIELDS and SEND are grouped because the comments tended to refer
to the set, and because this seems to be a proper functional
grouping within the command structure of our message systems.  

The comments are unchanged from the original, except for
formatting, and extraction from their ballot contexts.  Each group
of comments is preceeded by the Ballot Item Text.  

* * * * * * * * * * * * 

  13.  "FIELDS" - [each defined message field is a command]
       {opens buffer for type-in of "FIELD" content} 

COMMENTS:  

I NOT ONLY APPROVE BUT ENCOURAGE WHAT YOU CALL "FIELDS".  SOME
COMMAND MUST BE ADDED TO THE LIST TO MAKE THIS MORE USABLE; THAT
WOULD BE SOMETHING WHICH WOULD "SHOW" THE CONTENTS OF THESE
BUFFERS.  "PRINT" DOESNT SEEM TO DO IT TO MY WAY OF THINKING
(UNLES WE REDEFINE WHAT WE NOW CALL <MESSAGE SEQUENCE>).  

13.  "FIELDS" - I favor symmetric structure.  

13.  "FIELDS" - STRONGLY OPPOSE!  

13 ("FIELDS") I BELIEVE IT SHOULD BE THE RESPONSIBILITY OF EACH
COMMAND WHICH INITIATES THE MAILER ( OR THE RESPONSIBILITY OF THE
MAILER ITSELF ) TO ELICIT "FIELDS" WHEN REQUIRED.  

Item 13 except for distribution field I feel semantics should be
to replace field instead of appending if field command with same
name issued twice so therefore am not sure what I would recommend
today as semantics should be consistent across all Field commands.  

Are there a minimum number of Fields that Fields command should
exist for?  

13.  "FIELDS" -- Disagree.  If you need to explain it via a
followup note, then MsgGroup hasn't discussed it enough to vote
upon it.  I strongly believe that it is too complex a request
group to be in the "basic set" sought by Steve Walker.  

* * * * * * * * * * * * 

  14.  SEND - [no arguments] {sends message composed of buffers} 

14.  SEND - OPPOSE 

14 (SEND) THE MESSAGE SYSTEM SHOULD NOT BE DESIGNED TO REPLACE OR
REDUNDANTLY PERFORM THE FUNCTION OF THE MAILER.  REPLY, FORWARD
AND COMPOSE SHOULD INITIATE THE MAILER TO DO THEIR SENDING.  

14.  SEND -- Disagree.  My reason is this:  You are assuming the
ENEX model that information as to how the recipients of a message
are specified.  Is it agreed upon that the TENEX philosophy of
typing in recipients as a text-like field of the message is THE
way to go?  If not, then perhaps SEND requires arguments, as in:  

                 SEND <recipient list> 

14 (SEND) MY UNDERSTANDING IS THAT A MESSAGE HANDLER REALLY WANTS
TO WORK WITH OLD MESSAGES; IT SHOULD BE ABLE TO SEND NEW LETTERS
BY INVOKING THE MAILER IN A LOWER FORK (OR PTY ON TOPS-10), BUT IT
SHOULD NOT SUBSTITUTE FOR IT.  
-------  

10-MAY-78 22:11:43-PDT,6001;000000000001  
Reader-Id: 32
Date: 4 MAR 76 2119-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 296 COMPOSE/REPLY/FORWARD/RESEND: Ballot Comments
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]4-MAR-76 21:19:29-PST.STEFFERUD>    

This message contains comments collected from MsgGroup Ballots on
Basic Command Names, for the COMPOSE, REPLY, FORWARD, and RESEND
commands.  These comments do not make easy reading, but they do
convey some important concepts and issues.

COMPOSE, REPLY, FORWARD, and RESEND are grouped because the
comments tended to refer to the set, and because this seems to be
a proper functional grouping within the command structure of our
message systems.  

The comments are unchanged from the original, except for
formatting, and extraction from their ballot contexts.  Each group
of comments is preceeded by the Ballot Item Text.  

* * * * * * * * * * * * 

  8.  COMPOSE - {elicits actions to compose a message} 

COMMENTS:  

8.  should be TYPE or TYPE.MSG; subcommand should be TYPE.REPLY
(vice #3).  TYPE is what users do for input; PRINT is what
computers or machines do for people.  

8.  COMPOSE:  Agree; DRAFT should be used interchangeably.  

8.  COMPOSE - We assume this would be tailorable to particular
applications, and may need arguments to indicate which of several
preformatted sequences is desired.  WRITE or CREATE are acceptable
names also.  

8.  COMPOSE makes me feel like I am becoming a typesetter; I
prefer having this operation merged with the "FIELDS" operations,
if for no other reason than it makes everything symmetric, and
that means there is one less piece of special-casing that a user
has to worry about.  

8.  COMPOSE - AGREE; Should also define actions and prompts
provided.  E.g., should it act like sndmsg, or be different, or
what?  

Item 8 I prefer command word interrogate, mostly from habit but
think its a little more intuitive.  

* * * * * * * * * * * * 

  3.  REPLY - [<message sequence>; default <current>] {Elicits
      actions to compose a reply} 

COMMENTS:  

3.  REPLY:  Agree; ANSWER should be used interchangeably.  

REPLY - - - maybe AGREE -- why this, instead of Answer?  

3.  REPLY - AGREE There should be some definition about what <msg-
seq> means in this case.  Namely, one message, or multiple.  If
multiple, there might be some guarantee that they have something
in common rather than just being completely seperate entities.  

* * * * * * * * * * * * 

  4.  FORWARD - [<message sequence>; default <current>]
      {forwards messages in a new envelope} {elicits addressees,
      subject, and additional text} 

COMMENTS:  

*4.  FORWARD is really one of several sub-basic-functions in the
class that contains RESEND and DISTRIBUTE.  The differences are:  

        FORWARD should merely add a field indicating "forwarded
by:" and allow TO:  specification; addition of notes can be
permitted via the ANNOTATE, INCLUDE or REFERENCE commands that are
presumably a part or the first extension of the basic functions.  

        RESEND should augment the TO:  or CC:  fields only.  

        DISTRIBUTE should not affect the message (allows
distribution by a clerk internal to an organization).  

        I nominate FORWARD as the overall name for the basic
function; in NO CASE do I want to see another envelope!!  

4.  FORWARD Agree Should be interchangeable with READDRESS 

FORWARD - - maybe AGREE, why this instead of Distribute?  

4.  FORWARD - Do not create another envelope.  Provide ENCLOSE for
use with comments to go with a message, or for second envelopes if
necessary.  Add a Forwarded-by field a la DMSMSG.  

4.  FORWARD - AGREE; Should you be allowed to edit the forwarded
stuff in addition to the 'additional text'?  What are the
guarantees provided to the original sender of the message(s) about
the sanctity of his message(s).  

4.  FORWARD -- Agree.  It is not clear to me whether FORWARD
should, by default, "elicit ...  additional text".  May be host
system option.  

* * * * * * * * * * * * 

  15.  RESEND - [<message sequence>; default <current>] {sends
       existing message(s) without new envelopes to newly
       elicited addressees} 

COMMENTS:  

15.  not a basic function (see *4).  

15.  RESEND:  Disagree; Eliminate as a command and include as
argument in FORWARD or READDRESS commands.  

"RESEND" SHOULD BE ELIMINATED.  I SEE THIS AS A POTENTIAL PROBLEM.
I CAN SEE ONLY CONFUSION COMING FROM RECEIPT OF A MESSAGE WHICH
WAS NEVER SENT TO YOU - CONFUSION FOR BOTH THE ORIGINAL SENDER AND
FOR THE ULTIMATE RECEIVER.  IF ONE WANTS TO FORWARD A MESSAGE THE
PREFERABLE MECHANISM IS THERE IN THE FORWARD COMMAND.  

Resend is one of a collection of functions we're designing right
now.  

15.  RESEND - Should be named FORWARD, since SEND is for messages
I create, and RESEND implies I'm trying to send the same thing
over again.  

15.  RESEND - I do not consider this a strong feature, and could
easily live without it.  

15.  RESEND - WHO KNOWS?  I don't understand.  Is this equivalent
to Forward with a guarantee that the original message hasn't been
tampered with?  

The conceptual distinction between RESEND and FORWARD should be
clearly outlined, since I'm not sure that RESEND is needed in a
kernel set of commands.  

15 (RESEND) (REFER TO ARGUMENT AGAINST 'SEND').  FORWARD SHOULD BE
SUFFICENT TO PERFORM A RESEND.  

15.  RESEND -- Disagree.  I do not believe that the "basic" set
should contain both FORWARD and RESEND.  As FORWARD subsumes the
functionality of RESENT, I prefer to retain only FORWARD in the
basic set.  

15 (RESEND) I DO NOT REALLY SEE HOW THIS IS DIFFERENT FROM
'FORWARD', AND WHY BOTH ARE NEEDED AS PRIMITIVES.  

Ballot item 15.  No.  This is almost a special case of "FORWARD",
without comment.  I do not agree that it is basic.  
------- 

10-MAY-78 22:11:44-PDT,4786;000000000001  
Reader-Id: 33
Date: 4 MAR 76 2117-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 297 QUIT/DELETE/UNDELETE/CLEANUP: Ballot Comments
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]4-MAR-76 21:17:08-PST.STEFFERUD>    

This message contains comments collected from MsgGroup Ballots on
Basic Command Names, for the QUIT, DELETE, UNDELETE, and CLEANUP
commands.  These comments do not make easy reading, but they do
convey some important concepts and issues.

QUIT, DELETE, UNDELETE, and CLEANUP are grouped because the
comments tended to refer to the set, and because this seems to be
a proper functional grouping within the command structure of our
message systems.  

The comments are unchanged from the original, except for
formatting, and extraction from their ballot contexts.  Each group
of comments is preceeded by the Ballot Item Text.  

* * * * * * * * * * * * 

  1.  QUIT - [No Arguments] {No Cleanup of message file} 

COMMENTS:  

Would prefer to see Quit do cleanup after asking the user.  We
have a switch on it that allows it to work that way and also the
way suggested in your list.  

1.  QUIT - I would like to see CLEANUP available as a savable
default.  

1.  Quit + updating.  I don't think users should ever leave the
system without having their data base updated.  My inclusion of
file and get mitigates objections regarding accidentally deleting
messages you shouldn't have deleted--in fact it might be
preferable to have a Move command over a File command - 

*1.  QUIT - - Disagree.  The notion that DELETE doesn't delete,
but EXPUNGE does, and sometimes CLEANUPs happen when you QUIT but
sometimes they don't is, I believe, a purely TENEX notion.  If
everyone in MsgGroup is TENEX oriented, then it is easy to see how
everyone would automatically accept the TENEX point of view.  Fact
is, some systems don't have the "expunge" concept, and on these,
DELETE means "delete now" -- "EXPUNGE".  On such a system it might
be possible to have DELETE hold requests in abeyance until a
CLEANUP or QUIT, but such a system might not be able to remember
"delete"- markings between invocations of the mail subsystem.
Thus, on such a system QUIT MUST perform a CLEANUP too.  Hence, I
believe that we cannot legislate that QUIT does not perform a
CLEANUP.  I would rather have QUIT perform an automatic CLEANUP,
and devise another command, EXIT (for example), which would not do
a CLEANUP.  Some systems would not be able to implement EXIT.  

* * * * * * * * * * * * 

  5.  DELETE - [<message sequence>; default <current>] {Marks
      messages for deletion by CLEANUP} 

COMMENTS:  

5.  DELETE:  Agree; Should "Cleanup" automatically.  

Have Print, Delete, Undelete, File, default to the "Current
Sequence", not the "Current Message".  Call the Current Message
".", then it's quite easy to refer to it explicitly in these
commands.  Have the current sequence be "Recent", but also user
settable.  

5.  Delete.  I believe delete should take effect whenever you
leave the message system.  Have you tried to explain to a naive
user the significance of deleted messages (some 'expunged' and
some not) from earlier days of using the system?  Let the faint of
heart File messages in wastebasket.txt before deleting them.  They
can delete things from wastebasket.txt at their leisure!  

5.  DELETE -- Agree.  Question:  If default (current message) is
used, what is value of "current message" pointer after delete is
done?  

* * * * * * * * * * * * 

  10.  UNDELETE - [<message sequence>; default <current>]
       {unmarks messages for deletion by CLEANUP} 

COMMENTS:  

10.  UNDELETE:  DISAGREE; Should not be used.  

10.  'UNDELETE' reflects a bias of TENEX users, which has little
if any analog in most other systems.  The closest are some systems
which archive files, and in which a 'DELETE' operation merely
marks the file available for archiving without actually deleting
it.  The whole concept of 'UN-DELETE'-ing something bothers me.  I
think 'RETRIEVE' or 'RESTORE' are *much* more appropriate.  

* * * * * * * * * * * * 

  9.  CLEANUP - [<current file>] {expunge messages marked for
      deletion} 

COMMENTS:  

I am not sure that my comments are valid for your purposes, so let
me just note that the only command word choice that I really don't
like is CLEANUP, which sounds like what I do after my new puppy.  

9.  CLEANUP:  DISAGREE; Should not be used.  

Cleanup and its implicit confusions seem bad -- to naive users.  

Item 9 I prefer command word expunge again from Tenex habit.  

9.  CLEANUP -- Agree.  See my comment under (*1) above, in quit
command comments.  
-------    

10-MAY-78 22:11:44-PDT,2936;000000000001  
Reader-Id: 34
Date: 5 MAR 76 1055-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 298 GET/FILE: Ballot Comments
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]5-MAR-76 10:55:25-PST.STEFFERUD>    

This message contains comments collected from MsgGroup Ballots on
Basic Command Names, for the GET and FILE commands.  These
comments do not make easy reading, but they do convey some
important concepts and issues.

GET and FILE are grouped because the comments tended to refer to
the set, and because this seems to be a proper functional grouping
within the command structure of our message systems.  

The comments are unchanged from the original, except for
formatting, and extraction from their ballot contexts.  Each group
of comments is preceeded by the Ballot Item Text.  

* * * * * * * * * * * * 

  12.  GET - [<file name>; default <message.txt>] {<current
       file> becomes <named file>} 

COMMENTS:  

12.  should be GET.FILE; just GET is too ambiguous.  

12.  GET:  Agree; USE should be used interchangeably.  

GET - - - DISAGREE, tho I'm not sure what it should be.  

12.  GET - AGREE; But, what does it tell you about the state of
the file since it was last read?  

12.  GET -- Disagree.  Same problem with knowledge of file names.
Also, it presumes that the TENEX mail subsystems' idea of "current
file" etc.  is the correct model for MsgGroup, and, hence, the
world.  I believe that there may be alternatives, and that these
alternatives should be discussed.  

* * * * * * * * * * * * 

11.  FILE - {places copies of specified messages in named file} 

COMMENTS:  

11.  FILE:  Agree; SAVE should be used interchangeably.  

 Have Print, Delete, Undelete, File, default to the "Current
Sequence", not the "Current Message".  Call the Current Message
".", then it's quite easy to refer to it explicitly in these
commands.  Have the current sequence be "Recent", but also user
settable.  

11.  I do not think FILE is appropriate if the original is still
in my mailbox.  When I file something from my desk it is to get it
off the desk.  

11.  FILE - AGREE; but this should probably be a second-level
operation if for no other reason than Dave's comments on file
structure compatibility.  

11.  FILE -- Disagree.  The basic set should not require that the
user understand the syntax of file path names.  Also, I can't tell
if you are specifying the syntax to be 

    FILE <message sequence> <file name> 

    or 

    FILE <file name> <message sequence> 

    I do not believe that it can be legislated without further
discussion.  Hence, two reasons for disagreement.  

Ballot numbers 11-12 - I vote no on these.  I do not believe these
should be included as "basic".  From my understanding of the
intent of Steve Walker, the handling of files is not a "basic"
function.  
-------

10-MAY-78 22:11:44-PDT,5586;000000000001  
Reader-Id: 35
Date: 5 MAR 76 0941-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 299 PRINT/NEXT/SUMMARIZE: Ballot Comments
To: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]5-MAR-76 09:41:39-PST.STEFFERUD>    

This message contains comments collected from MsgGroup Ballots on
Basic Command Names, for the PRINT, NEXT, and SUMMARIZE commands.
These comments do not make easy reading, but they do convey some
important concepts and issues.

PRINT, NEXT, and SUMMARIZE are grouped because the comments tended
to refer to the set, and because this seems to be a proper
functional grouping within the command structure of our message
systems.  

The comments are unchanged from the original, except for
formatting, and extraction from their ballot contexts.  Each group
of comments is preceeded by the Ballot Item Text.  

* * * * * * * * * * * * 

  6.  PRINT - [<message sequence>; default <current>] 

COMMENTS:  

PRINT would not be my choice for a service that is exclusively on
a CRT since it connotes hard copy production.  I would reserve
that word for producing hard copy (which comes off on a different
terminal), and choose DISPLAY for local display.  For non-CRT
based systems, PRINT is probably a reasonable choice.  

6.  PRINT ok but require/allow the NEXT command to be used between
the messages specified; call it PRINT.MSG if necessary to
distinguish from PRINT.SUMMARY.  Note that some provision will
necessary for allowing a user to get a hard (paper) copy; like
PRINT.COPY.  

6.  PRINT:  Agree; DISPLAY should be used interchangeably.  

 Have Print, Delete, Undelete, File, default to the "Current
Sequence", not the "Current Message".  Call the Current Message
".", then it's quite easy to refer to it explicitly in these
commands.  Have the current sequence be "Recent", but also user
settable.  

PRINT - - - DISAGREE -- Should be Show 

6.  PRINT - This is potentially confusing for video display
terminal users, especially those who have a hard copy capability.
(Some would like it to default to NEXT MSG , while I find default
to current message ok.) 

6.  I would like to make a strong vote for 'READ' in favor of
'PRINT'...because if I PRINT my mail I want hardcopy on the line
printer.  "Printing" is a meaningless operation on a video
terminal.  

As I understood the original question, you were asking only about
named commands .  (not about control z and the like).  Therefore,
Yes, I am in agreement on al items in the ballot, except the ____
NAME 'PRINT'.  I prefer the name 'TYPE' since thats what happens.
PS That just leaves me holding out for TYPE rather than PRINT.  -- 

6 (PRINT) PRINT IS A COMMON COMMAND USED ON MANY SYSTEMS TO
PERFORM OUTPUT TO A LINE PRINTER.  IN ORDER TO AVIOD CONFUSION, I
THINK 'EXAMINE' WOULD BE A BETTER CHOICE.  

* * * * * * * * * * * * 

  7.  NEXT - [<message number>; default <current+1>] {resets
      <current> and prints specified message} 

COMMENTS:  

7.  NEXT - this is unneeded, if PRINT defaults to next message.  

Item 7 - I wonder if LF should not also do Next function as it
does in most systems I am familiar with.  

Is there a standard for meaning of message sequence?  

7.  NEXT -- Disagree.  I think your specification is incorrect:
there should be no <message number> for next.  What does it mean
to say "NEXT 5"?  Does it mean "PRINT 5"?  Or "PRINT 6"?  Note:  I
think the CONCEPT of NEXT is a good one; I think it's merely
improperly specified here.  

[7 (NEXT)] IF WE HAVE CURRENT FOR DEFAULT AND NEXT TO MOVE IT
AROUND, WE NEED A 'CURRENT' TO TELL US WHERE WE ARE.  

* * * * * * * * * * * * 


  2.  SUMMARIZE - [<message sequence>; default <new messages>]
      {prints brief information about each message} 

COMMENTS:  

2.  should be PRINT.SUMMARY but SCAN is a good second.  (The
military around here have pointed out that these are not really
"summaries" but rather, in the military lingo, "header fields".
This establishes a need for the terminology used in the
specification of what appears as a result of this command to be
consistent with the name chosen for the command:  e.g.,
SPECIFY.SUMMARY.  In this regard SPECIFY.SCAN is less natural
(although SPECIFY.SCAN.FIELDS is not bad) and FILTER is downright
obnoxious.) 

2.  SUMMARIZE:  Disagree; READ or SCAN would be closer to the
meaning intended and should be used interchangeably.  

"SUMMARIZE" SHOULD BE CHANGED TO "SCAN".  

Have Summarize also default to Current Sequence.  Most users will
leave Current Sequence set to its default -- Recent -- so doing
this will just add flexibility for advanced users who wish to
change the current sequence.  

Also I prefer "Survey" or "Scan" to "Summarize".  They're both
shorter.  

 SUMMARIZE - DISAGREE, and I'm not sure I think Scan is best.  

2.  SUMMARIZE - This name does not reflect what the user is doing.
SCAN is a better term.  Print.Summary is ok if an abbreviation is
available for the experienced user.  (I like LIST but realize this
has special connotations for computer people.) 

2.  SUMMARIZE - AGREE, but with reservations about how the stuff
is presented to users.  In addition, can a user define how stuff
gets displayed to him?  

I propose "Scan" rather than "Summarize", due to Dave Crocker's
experiment, which I believe is accurate.  

2.  SUMMARIZE -- Agree.  Note that some systems may not have the
concept of "New" messages, and may default to "all" messages.  
-------  

10-MAY-78 22:11:45-PDT,1345;000000000001   
Reader-Id: 36
Date: 5 MAR 76 1500-PST
From: STEFFERUD at USC-ISI
Sender: STEFFERUD at USC-ISI
Subject: MSGGROUP# 300 [GROBSTEIN at OFFICE-1: ballot tabulation message error]
To: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[USC-ISI]5-MAR-76 15:00:51-PST.STEFFERUD>    

	
Begin forwarded message
          --------------------
Mail from OFFICE-1 rcvd at 5-MAR-76 1324-PST
Date:  5 MAR 1976 1324-PST
From: GROBSTEIN at OFFICE-1
Subject: ballot tabulation message error
To:   stefferud at ISI
cc:   grobstein


stef,

on the off chance that you didn't notice, and no one told you,
the message with the ballot tabulation has the numbers scrunched
together up against the command names instead of being under
the approppriate columns.  have a good weekend.   dave
-------
          --------------------
End forwarded message
	


To all MsgGroupees, 

I hope Dave is the only one of you who did not get a fair share of
the TABs I included with the Tabulation Message.  (One such person
is more than enough) 

I checked the copy in [ISIA]<MsgGroup>MESSAGE.TXT and it is fine.
You can get a new copy from there if need be.  I have also set up
a copy in a separate file so it can be FTPed easily.  It is in
[ISIA]<MsgGroup>MSGGROUP#.294;1.  

Let me know if you have any further troubles.  Best, Stef 
-------