Date: 06 DEC 1977 0951-EST
From: JZS at CCA
Subject: Sam Strugglegear assails Boston
To:   Header-People at MIT-MC

Bob Dornick of Quasar Industries and side-kick Sam, "programmed for
random conversation", appeared on the WCVB Good Day program this morning
and will be "chatting" with the folks at Jordan Marsh, Boston today.

/Joanne
-------

Date:  9 Dec 1977 1603-EST
From: Philip Karlton at CMU-10A
Subject: Parsing RFC733 address lists.
To:   Header-People at MIT-MC
Message-ID: <09Dec77 160339 PK01@CMU-10A>

How about somebody from the committee generating a list of pathological,
but legal header lines that people can try shoving through their
parsers?
                        PK

Date: 09 DEC 1977 1634-EST
From: JZS at CCA
Subject: Parsing RFC733 address lists
To:   Header-People at MIT-MC

This is an excellent idea.  I'd also appreciate receiving sample
messages for testing purposes directly from group members.

Joanne
-------

Date: 11 Dec 1977 1745-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: too late for the RFC, but you still might want to know
To:   Header-People at MIT-MC

In the RFC, it states that the separation between the header and
the body is to be a null line, i.e. CRLF CRLF.  I assume that this
is so that there will be no ambiguity in telling folded lines from
end-of-header marks.

However, folks around the net seem to be generating headers that 
have that blank in there (CRLF SPACE CRLF), so it might be a good
idea for all of you folks who are frantically writing fancy 
mail-reading programs to make your programs be able to  recognize
that case, even though it is illegal.
                        B.

Date: 12 DEC 1977 1040-PST
Sender: DCROCKER at USC-ISI
Subject: Re: too late for the RFC, but you still might want to know
From: DCROCKER at USC-ISI
To: Brien.Reid at CMUA
Cc: Header-People at MIT-MC
Message-ID: <[USC-ISI]12-DEC-77 10:40:22.DCROCKER>
In-Reply-To: Your message of DECEMBER 11, 1977

(CRLF SPACE CRLF) is a bug.  The old Unix Sndmsg generates it at
some sites (including Rand, I'm afraid).

Dave.
-------

Date: 12 Dec 1977 1521-EST
From: BRIAN REID at CMU-10A
Subject: Bug
To:   DCROCKER at USC-ISI
CC:   Header-People at MIT-MC
In-Reply-To: <[USC-ISI]12-DEC-77 10:40:22.DCROCKER>

Ah, but it's a sufficiently subtle bug that I think it would behoove
mail programs to look for it.  What RDMAIL did with a message that had
(CRLF SPACE CRLF) in it was to make the entire message into a header,
then not print the `extra' header lines because my user profile says 
I don't want to see random extra header lines.

One question, though: if a mail has no body but only a header, does 
the CRLF CRLF still need to be at the end??
                        Brian

Date: 12 DEC 1977 1400-PST
Sender: DCROCKER at USC-ISI
Subject: Re: Bug
From: DCROCKER at USC-ISI
To: BRIAN.REID at CMUA
Cc: Header-People at MIT-MC
Message-ID: <[USC-ISI]12-DEC-77 14:00:56.DCROCKER>
In-Reply-To: Your message of DECEMBER 12, 1977

Unfortunately, it will be quite reasonable for messages to have
(CRLF SPACE CRLF) as valid lines in a header.  E.G.  I expect our
system to support that use.

I believe the 733 syntax does not require CRLF CRLF if there is
not body text.  (Certainly meant to make it that way.)

Dave.
-------

Date:  6 Feb 1978 1223-PST
From: ZELLICH at OFFICE-1
Subject: Net address change for zellich, wmartin, walsh
To:   msggroup at ISI, stefferud at ISI, header-people at MIT-AI

I don't know if all three of us are still listed in both Header-People &
Msggroup, but anyway:
As of Monday, 6 Feb 78, Rich Zellich, Will Martin, and Bill Walsh directories
have been moved from the SRI-KL to OFFICE-1.  Directory names ZELLICH,
WMARTIN, and WALSH are still valid - only the host has changed.
Cheers,
Rich
-------


Date:    8 Feb 1978 2000-EST
Sender:  RICK.GUMPERTZ at CMU-10A
Subject: address lists
From:    RICK GUMPERTZ(N810RG02) at CMU-10A 
To:      Header-People at MIT-MC

- - - -
I asked this before but got no response, so here goes again:

Suppose I want to put in a piece of mail an address field that lists
the individuals in a group like Header-People but also gives a
pseudo-user that can be used instead.  How do I represent that?  I.e.
how do I say further mail should go to either the single address X or
to all of the multiple address A,B,C,...

		Rick

-------

Date:    10 Feb 1978 1404-EST
From:    BRIAN.REID at CMU-10D 
Subject: let's hear it for uniform standards
To:      Header-People at MIT-MC, bajzek at CMUA

- - - -
300 PARC-MAXC FTP Service 2.9.0.2 %57 at FRI 10-FEB-78 10:26-PST
450 No such mailbox at this site.
?Transfer aborted.
					**COMMAND QUEUED**
!SMLFL 10 Feb 1978 1322-EST ; NBS-10;436FPO.QED;Totally stupid
300 NBS-10 5.07B NBS 5/IL FTP Server 4B(32)
507  No such user as TOTALLY STUP
*SMLFL 10 Feb 1978 1331-EST ; UTEXAS;423FPO.QED;Unknown User
300 UTEXAS RET-Unix Server FTP
050 Howdy Pardner!
450 User unknown
					**COMMAND QUEUED**
!SMLFL 10 Feb 1978 1331-EST ; RAND-UNIX;423FPO.QED;Unknown User
300 Rand-Unix Server FTP
450 User Unknown
					**COMMAND QUEUED**
!SMLFL 10 Feb 1978 1331-EST ; AMES-67;423FPO.QED;Unknown User
300 NASA AMES TSS/360 SERVER FTP -- ENTER USERID (OR "MAIL" COMMAND)
503 COMMAND "MLFL UNKNOWN USER" IGNORED: UNKNOWN USER SPECIFIED
?Transfer aborted.
					**COMMAND QUEUED**
!SMLFL 10 Feb 1978 1331-EST ; MIT-MC;423FPO.QED;Unknown User
300- MIT-MC ITS 1100,  FTP server 158 on 10 FEB 1978 1335-EST
300 Bugs/gripes to BUG-FTP @ MIT-AI
252 Thanks for the blurb
FTP 4A(13)
*SMLFL 10 Feb 1978 1347-EST ; MULTIC;472FPO.QED;Unknown User
030 Unattended Service
300-Multics 33.2: MIT, Cambridge, Mass.
300 Load = 20.0 out of 85.0 units: users = 20
450  Cannot locate mailbox for "Unknown"; please check spelling of user name.
?Transfer aborted.
					**COMMAND QUEUED**
!SMLFL 10 Feb 1978 1347-EST ; ARGONN;472FPO.QED;Unknown User
? IMP6 Connection error - refused
?ICP connection failed
					**COMMAND QUEUED**
*SMLFL 10 Feb 1978 1347-EST ; WHARTO;472FPO.QED;Unknown User
300 Wharton School 6.03v10 FTP Server 4B(32)
507  No such user as UNKNOW
					**COMMAND QUEUED**
!SMLFL 10 Feb 1978 1347-EST ; LONDON;472FPO.QED;Unknown User
300 UC LONDON GATEWAY 18 46  ON 10 FEB 78
000 INDRA FTP Version 2.11 (19 Apr 77)
500 Command unrecognized
?Transfer aborted.
					**COMMAND QUEUED**
!SMLFL 10 Feb 1978 1347-EST ; LBL;472FPO.QED;Unknown User
? IMP6 Connection error - host down
?ICP connection failed
					**COMMAND QUEUED**
*SMLFL 10 Feb 1978 1347-EST ; UCLA-CCN;472FPO.QED;Unknown User
300 UCLA/CCN FTP SERVER NEW TELNET, ENTER COMMAND OR HELP
503 USER PARAMETER INVALID, REENTER THIS AND FOLLOWING PARAMETERS
					**COMMAND QUEUED**
*SMLFL 10 Feb 1978 1349-EST ; SDAC-44;730FPO.QED;Unknown User
300 SDAC-44 FTP Server, Version 74.327
431 User name invalid
?Transfer aborted.
					**COMMAND QUEUED**
!SMLFL 10 Feb 1978 1349-EST ; SRI-KL;730FPO.QED;Unknown User
300 SRI-KL FTP Service 101B(4) at Fri 10-Feb-78 10:53-PST
450 No such mailbox at this site.
?Transfer aborted.
					**COMMAND QUEUED**

-------

Date: 10 FEB 1978 1508-PST
To: HEADER-PEOPLE at MIT-MC
From: Hathaway at AMES-67
Subject: BRIAN'S "LET'S HEAR IT ..."

Brian, you're beautiful!
 
And I will be the first to admit that my server's response is probably
wrong (we returned a 503 for "Unknown User"), but it was a bit hard
arriving at that decision, since: 
 
    1. there is no mention of MLFL in the official FTP protocol,
 
    2. in the "Official Mail Protocol" (pages 239-240 in the ARPANET
        Protocol Handbook) it says that MLFL has the same replies as
        APPE, which can't be right because APPE (almost) always
        requires logon and MLFL usually does not, and
 
    3. RFC 640, which was supposed to become official in February of
        1974 (yep!) is not yet in universal use.
 
At any rate, it seems the correct reply would be 530, at least ac-
cording to RFC 640.  That means "permanent failure" (since "Unknown
User" is not likely to succeed if you tried it again) and "failure
in authentication and accounting."  Also I note that 530 is listed
as a reply for MLFL (page 228) although it is not in the list of
example messages (pages 225-226).  It is particularly interesting
that this "correct" code is one of the relatively few three digit
numbers which was used by NOBODY in Brian's sample!
 
And to repeat:  Let's hear it for uniform standards!!!!
 
                                       Wayne
 
PS:  An aside to UTEXAS:  "Howdy Pardner!"??????  That sounds like
      something a Teasip system would say!    W.
------

Date: 21 Feb 1978 1750-EST
From: RICK GUMPERTZ at CMU-10D (N810RG02)
Subject: proposed Federal Information Processing Standard
To:   Header-People at MIT-MC, MsgGroup at USC-ISI, Wactlar at CMU-10A,
      Wulf at CMU-10A, Feinler at SRI-KL, Roach at MIT-Multics,
      Tavares at MIT-Multics, Newcomer at CMU-10A, Saltzer at MIT-Multics
CC:   Gumpertz @ CMU-10a
Reply-To: Gumpertz @ CMU-10a
Message-ID: <21Feb78 175050 RG02@CMU-10D>

People:

I am sending this to everyone I can think of who might be interested
or might know of appropriate people to be forwarded to.  Please feel
free to forward this note to anyone whom you think it concerns.
(aside to Jake: please forward this to the ARPANET liason list)

I have recently discovered that the National Bureau of Standards
published in the Federal Register (available at most major libraries)
for 12 December 1978 (pp. 62408-16) a proposed standard for logging
into and out of interactive computer systems.  It claims to apply to
all systems which will be used by a "Federal Government user"
(whatever that is!).

Not only does it specify to the word what messages will be generated,
it flagrantly violates ASCII by suggesting a new meaning for the DLE
code.  Although I am sure some well meaning person put a lot of work
into writing this document, I don't really think it is suitable as a
FIPS.

The first notice that I found of this standard was in "Minicomputer
News", which may seem a rather unlikely source.  To make things
worse, the deadline for comments is 13 March 1978!  Please try to get
hold of a copy (if you are concerned with such things) and comment
to NBS as soon as possible.

                Richard H. Gumpertz

Date: Tuesday, 21 Feb 1978 2027-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: Re: proposed Federal Information Processing Standard
To:   Header-People at MIT-MC, MsgGroup at USC-ISI, Wactlar at CMU-10A,
      Wulf at CMU-10A, Feinler at SRI-KL, Roach at MIT-Multics,
      Tavares at MIT-Multics, Newcomer at CMU-10A, Saltzer at MIT-Multics,
      Sproull at CMU-10A
CC:   RICK GUMPERTZ at CMU-10D (N810RG02)
In-Reply-To: <21Feb78 175050 RG02@CMU-10D>

Some highlights of this proposed standard:

  - [The System Signal] is generated by a computer, and 
    indicates to the user that the next action is up to 
    the user. . . .  The system signal shall be generated
    so as to print or display the colon character (:) at 
    the left margin of a line following a previously printed
    or displayed line of system message text."

  - "This Standard comes into play the instant there is
    established the capability of recognizable character 
    transmission and receipt by a user's terminal.  Thus,
    no commands, requests or messages may be presented to 
    or accepted from a user between the time that the user
    approaches the terminal and the time that this Standard
    governs what the user sees and does."

  - The default value for the exit request signal is DLE
    [^P].  The exit request signal shall be recognized
    by the system at any time during the operation of a
    computer service or during the access procedures
    when the user is permitted to enter input."

From the Introduction:

    "Just as the number and variety of users has grown, so has
    the number and variety of computer services, both within
    and outside the Federal Government.  But while the services
    are no longer in their formative stages, users who choose
    to deal with more than one are still being asked to overlook
    differences that strike them as being frustrating and
    annoying....Specifically, this standard is intended to stem
    the proliferation of access -- entry and exit -- procedures,
    and to establish a single set of procedures that will have
    widespread applicability."

    "APPLICABILITY.  The procedures specified in this standard
    apply to all user-terminal interactions where a Federal
    Government user is seeking access to or exit from one or
    more computer services."


Date: 23 FEB 1978 2313-EST
From: MARS-RETRIEVER at CCA
Subject: RFC 733 seems to be stabilizing.  Besides, the new ARPANET protocol
To:   Date:, From:, Subject:, To:
cc:   Sender:, Message-ID:, [CMU-10A] 31 Oct 1977 22:, 27:

handbook is due someday soon.  I strongly feel that before 733 gets
any sort of stamp of "official approval" as a standard, it should be
implemented and used by at least a few sites.  Design problems have a
way of becoming more obvious when one tries to really implement the
paper design.

Does anyone out there have the time to get a 733 like mail
sender/receiver running?  Has anyone tried yet?

		Rick
-------
-------

Date: 23 FEB 1978 2331-EST
From: MARS-RETRIEVER at CCA
Subject: Please ignore previous message
To:   Header-People at MIT-MC


-------

Mail from SRI-KL rcvd at 24-Feb-78 1658-PST
Date: 24 Feb 1978 1649-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: Online address for delivery of FIPS standard comments
To:   [SRI-KL]<FEINLER>nlg-sndmsg-1-78:

 -- Messages from file: [SRI-KL]<FEINLER>MAIL.TXT.1
		 -- Friday, February 24, 1978 14:44:20 --

Mail from NBS-10 rcvd at 24-Feb-78 1347-PST
Date: 24 Feb 1978 (Friday) 1647-Est
From: WATKINS at NBS-10
Subject: FIPS Standard replies
To:   Feinler at SRI-KL
cc:   Gumpertz at CMU-10A

If network mail is sent to me (Watkins @nbs-10) concerning the proposed
standard, I will print it out and forward to the proper person.  I will
not be able to do more than simply print it out on a line printer, so
if anyone is concerned with formatting and type quality be forewarned
that the transmission medium will be line printer type and paper.
Shirley

-------

Date: 24 Feb 1978 1652-EST
From: Rick Gumpertz at CMU-10A
Subject: net replies
To:   PBARAN at USC-ISI, MsgGroup at USC-ISI, Header-People at MIT-MC
Message-ID: <24Feb78 165218 RG02@CMU-10A>

I just got this --

                Rick

- - - - Begin forwarded message - - - -
Date: 24 Feb 1978 (Friday) 1647-Est
From: WATKINS at NBS-10
Subject: FIPS Standard replies
To:   Feinler at SRI-KL
cc:   Gumpertz at CMU-10A

If network mail is sent to me (Watkins @nbs-10) concerning the proposed
standard, I will print it out and forward to the proper person.  I will
not be able to do more than simply print it out on a line printer, so
if anyone is concerned with formatting and type quality be forewarned
that the transmission medium will be line printer type and paper.
Shirley
- - - - End forwarded message - - - -

Date:  3 Mar 1978 1156-PST
From: Kahler at SUMEX-AIM
Subject: FIPS Proposed Standard Sample Session
To:   [ISI]<MsgGroup>Mailing.List;149:
cc:   Header-People at MIT-MC

	To my understanding, this is what a typical terminal session
might look like under the proposed standard.  If this message takes
a lot of paper, well, so will logging in and out under this proposal.
Line editing, by the way, is not provided, or even anticipated.  For
all I know, we are expected to be perfect typists.

[Signal your communications network (in this case the local TIP) that
 you want service and identify your terminal, then...]

[TIP may type out a "network information message" identifying the TIP
 and the ARPA network]

Abbreviated form - Yes or No?
:No				[User may also type HELP, ?, or LIST]

Enter destination
:SUMEX-AIM

SUMEX-AIM is available

Enter identification
:Smith

Enter password
:password	     [Either not echoed, underprinted or overprinted]

["Service operation" commences]

	.
	.
	.

[User types ^P at some point to exit]

		^P
Enter one of the following:  Terminate or Leave or Stay or Suspend
:T

Smith has terminated SUMEX-AIM at date/time
[Optional accounting stuff]
END

				Rich
-------

Date:  3 Mar 1978 1433-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: FIPS standard
To:   header-people at MIT-MC
cc:   feinler

I talked to Shirley Watkins and she said that there are
set procedures for having one's comments registered with respect
to a FIPS standard.  The most important procedure is that the
comments must be received in writing and be signed by the sender.
This may mean that the comments forwarded to Shirley (I believe
at least two people responded to her) may not be valid input.
There is still time for those of you who responded online to
do so in a signed letter.

I thought you would want this input so that you can make
your comments count.

Regards,

Jake

If you have questions you might direct them to either Shirley
Watkins (Watkins@NBS-10) or Tom Pyke (Pyke@NBS-10)  I would
appreciate receiving copies of the dialog, if any.  Thanks.
-------

Date: 4 MAR 1978 0014-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: watkins at NBS-10, pyke at NBS-10
CC: Roach at MIT-MULTICS, Tavares at MIT-MULTICS
CC: Saltzer at MIT-MULTICS, Feinler at SRI-KL, Wulf at CMU-10A
CC: Wactlar at CMU-10A, Newcomer at CMU-10A, msggroup at USC-ISI
CC: header-people at MIT-MC

I am not certain that I will be able to find the mental
wherewithal to mail an actual US mail letter within a week.
I hope that whoever is designing the standard is not legally
prohibited from taking into account any knowledge that he
gets via unofficial channels (though I wouldn't be surprised
if the government were so cretinous).  Here is the story:

  The operations which the login/logout standard is trying
  to standardize have no resemblance to the actual operations
  performed by users of most timesharing systems.

IF it is true that the user is going to specify a service,
his name, and a password, then the standard is fine as a way
of doing it.  But that isn't usually the case.

Problems with the standard for Login:

I know of no system except Multics in which the user says
ANYTHING about what he intends to do before he logs in.
If we interpret a "service" to mean the use of one or more programs,
then the user does all the specification of the services he
wishes to use AFTER logging in, on most systems.  It would
be horrible to be forced by a standard to restrict him!
If, as the standard perhaps (it's not clear) suggests, a service
is a large number of programs that can be used together or
sequentially, than most timesharing systems offer only one
service:  the entire set of programs available on the machine.
Thus, there is no point in asking the user to specify the
service in advance.  "Hello, welcome to ITS.  What service would
you like:  ITS or ITS?"

So far, things would be OK if only the "destination"
specification could be omitted by the 99% of all systems which don't want it.
But there is an additional problem:  most systems provide "service"
to the user BEFORE HE LOGS IN.  Commercial systems such a
Bottoms-10 and Twenex allow the user to run some programs
such as SYSTAT or talk to the operator before logging in.
Since the user does this exactly the same way he would do it
if he WERE logged in, clearly the system is not doing anything
special;  it is just providing a restricted subset of the same
(unique) service which it provides to logged-in users.
On my system, ITS, it's even worse.  Essentially complete service
is available to whether you log in or not.  This is deliberate
and provides benefits to the user.  But the login standard says
that the computer MUST make the user log in as the very first
thing he does, not giving him a chance to ask to do anything else.
And when the ITS user decides to log in, he does so by typing
a command, using the same syntax used for other commands.
The command syntax used is ":<commandname> <arguments><CR>".
Clearly it is better for the user to have a consistent syntax
available for all commands including the :LOGIN command.

Problems with the standard for "exit requests":

As for the "exit request", its format limits the flexibility of
the operating system and limits its architecture.  I will
describe each of the three operating systems for the PDP-10
and how it would be affected.  Note that the problems depend
on whether a "service" is a single program invocation or a whole
session;  I will describe separately the problems resulting
from each assumption.

ITS and Tenex/Twenex, if each program is a "service":

On ITS and Tenex/Twenex, the user's "system commands" are actually
read by a top-level command-reading program, a user-mode program
distinguished very little from other programs run by the user.
It creates inferior jobs and runs programs in them as specified by the user.

Now, of course, there is a character to interrupt an inferior job and
give more commands to the top level.  If we regard each invocation of a
program as a distinct service, then it is analogous to what the standard
calls an "exit request".  On ITS it is ^Z (Control-Z);
on Tenex/Twenex it is ^C.  It could conceivably be ^P,
if that weren't already used for other things.  But what it does
is not the same as what the standard says about exit requests.  It simply
stops the inferior and lets you give more commands.  You can give
a command to continue (like "stay"), or a command to log out
(like "terminate").  On Tenex/Twenex, you can run some other program,
analogous to "leave".  On ITS, you can run some other program,
but it is analogous to "suspend" since ITS's top level allows up
to 8 inferiors and all are independent.  If you want to get rid of
your old service, you must explicitly kill it.  ITS also allows
you to do other things, such as tell the program to run, but without
control of the terminal (good for an assembly with its error output diverted).
Of course, on both systems you can give innumerable other commands
to communicate with other users, inquire about the system status,
list your directory or delete or copy files, etc. without interfering
with the job you have exited from.  You aren't forced to say what
to do with it right away;  you can attend to other things and
decide its fate whenever it is convenient for you.  This is especially
true on ITS, where absolutely anything else you do will not interfere
with the status of the suspended program unless you explicitly kill
or restart it.  This power is very convenient, but it is forbidden by the
standard, assuming once again that each program invocation is a service.

ITS and Tenex/Twenex, if a whole session is a "service":

If each program invocation is NOT a distinct service, then the whole
session is one service-invocation, and the exit request can only be
interpreted as a request to log out.  On ITS and Tenex/Twenex, the
way to log out is to give the appropriate command to the top-level
program, which executes a logout system call in response.
First, you must interrupt the inferior you are using, if necessary.
The standard appears to require that a ^P be interpreted, at all
times (not just when you are talking to the top level), as a request
to log out.  This can only be done by making ^P give control to
the top level.  This is an imposition on the character set
available for inferior jobs;  they can't use ^P for anything.
Since the character for exitingthe inferior has to exist anyway,
and logging out can be done with that followed by a command to the
top level, the imposition is totally unnecessary.  It is also somewhat
of a screw.  On ITS, you can run the usual top-level as an inferior,
and command it to run sub-inferiors.  It behaves totally as usual,
except that it can't log in or out.  The inferior-escape ^Z works
with it too, since it really goes up one level rather than to the top.
^P, on the other hand, would have to go all the way to the top.
This is rather untasteful.
Also, logging out is not something done frequently, and, from an
information-theoretic standpoint, it should not have a particularly
short command.  There are a dozen things I do far more often than
log out.  Should each one have a character to request it, which
works all the time?  They each deserve one more than logging out does.
But better is not to give a special character to any of them.
The top level program has commands for them all; I need only
type ^Z or ^C to get back to it, and give the command.

Finally, since ITS offers only one service ("ITS") and Tenex/Twenex
offers only the "Tenex" or "Twenex" service, what is the meaning of "Leave"?

Bottoms-10:

So much for ITS and Tenex/Twenex.  For Bottoms-10, the architecture
is simpler - there is "the user's program" and there is the "system
command level" - so there are no problems there.  But the other
problems - that the existing system is much more flexible than
the standard allows - are the same.  You type ^C or ^C^C to stop
a program.  ^C makes it stop only as soon as it waits for input.
^C^C stops it right away.  This distinction is very useful and
nobody would like having to give it up.  Then, you can restart the
program or run something else, or do various other things before
you have to make up your mind.  When you do decide, you speak your
mind by giving a command, in the same syntax that system commands
always use.  This internal consistency is certainly valuable.
It can't fit in with the logout standard, though, since the standard
is designed for a situation where the possible user commands form
a very limited set.  So much for what happens if each program is
a distinct service.  If the whole session is one service, the problems
are again similar to those of ITS and Tenex/Twenex.  You log out
by giving a system command, if necessary typing ^C or ^C^C first
so you can give system commands.  If ^P were to be effective at
all times, it would be an additional superfluous way of exiting
a user program.  And again, logging out isn't frequent enough
to need such special treatment.

Conclusions:

The conclusion is that the standard assumes that systems differ
only in minor details from a specific model of interactions,
and attempts to standardize the minor details.  This assumption
is false; the model used differs more from most timesharing
systems than the systems differ from each other!

In fact, the only systems I know of which actually fit the model
assumed by the standard are the TIPs, ELFs, and other systems which
exist only for communication with other systems.  A user of the TIP
might indeed specify his "destination" first of all, and then
give his user name.  Of course, TIPs don't ask you for a user name.
So the model seems to fit only the composite interaction in which
the TIP asks you for your destination, and connects you,
and the machine you are connected to asks you for your name.
The TIP also does have an escape character with which you can
at any time close your connection to "leave" or "terminate".

So I think that the proposed standard needs major rethinking.
If what you want is a standard for TELNET programs and their
command syntaxes, you should call it that, and not say that
it applies to loggin in and out of timesharing systems.

Questions:

I would like to know your specific attitudes toward the problems
I have mentioned.  For example, do you think that standardization
is so important that it outweighs all these disadvantages?
Or do you think that the disadvantages don't exist?
Do you consider a "service" to be a single program, or a session?
Which systems did you have in mind when you formulated the standard?
What, exactly, is a "Federal user"?  Is everyone funded by ARPA
a Federal user?
What if ITS decides that the unspecified preamble for establishing
communication consists of "^Z :OWATABUBIAM<CR>"?  Is that within the standard?
I will be glad to try to send you a US mail copy of this if it is
important, though I can't promise success.  Should I?
What will that accomplish?
Please send the answers to these questions to all the recipients
of this message.

Plea:

PLEASE, PLEASE allow more time for comments, even a week more.
Much of the ARPANET community learned about the proposed standard
less than a week ago (Nobody makes a habit of reading the Federal Register
here).  It takes time for a person to articulate his thoughts.  
Everyone who has seen the standard here has been so shocked
that he couldn't think.  I am the first to recover enough to say
anything coherent.  My friends are so stunned they can't find words!


Date: 4 Mar 1978 1718-PST
From: MRC at SU-AI (Mark Crispin)
Subject: FTP in reality and myth  
To:   Feinler at SRI-KL, Postel at USC-ISI
CC:   Header-People at MIT-MC

[Jake and Jon, please forward this to the liaison group and the RFC list]

While looking through the new protocol handbook (a beautiful job btw
as an aside to the editors), I again noticed the funny state which the
FTP protocol is in.  For one thing, the document specifies a protocol
which allegedly became official back in 1974, and which for the interim
was to live on socket 21.  Well, today, we have, according to "assigned
numbers" the "old" FTP protocol living on socket 3, and the "new"
protocol living on socket 25.  A quick look by me on the network failed
to find anybody who had a socket 25 FTP server.

In addition, I noticed several pages devoted to conflicting descriptions
of the reply codes.  I have been told (though I do not know, since this
was before the time when I was doing network programming) that the new
protocol was so much hairier than the old one that nobody wanted to
spend the time or money to implement it.

I would like to bring this up before the community of ARPAnet hackers.
Exactly what is the real state of the FTP protocol?  How close is the
true implementation to what the book says?  I don't think it helps
much to have the book describe a beautiful but legendary protocol.
Additionally, on the reply codes, what is the true state of things on
this?  What document is telling the truth?

Why isn't the "old" FTP protocol documented, if it is closer to reality
than the "new" protocol?  It seems like a major screw to not document
an important protocol such as FTP (I have similar feelings about the
lack of documentation on the old TELNET protocol, despite my strong
preference for the new protocol).  The reason for these questions
is this; how else do you answer protocol questions when a conflict
comes up between two hosts on who is losing by violating protocol?
Worse, if the network software undergoes a redesign, compatability
means the old protocols have to be supported too.  Old source listings
which may or may not themselves by lying aren't too helpful.

I would like to hear the opinions of others on this matter.  Perhaps if
the "new" protocol really contains necessary improvements over the "old"
one, then ARPA should fund the manpower for everbody to convert.  Otherwise,
the "new" protocol should be abandoned and something be done to clean up
the mess on the "old" protocol so somebody going to write an FTP
implementation knows what the hell is going on!

Cheers,
	Mark

-------

Date: 6 Mar 1978 1311-PST
From: MRC at SU-AI (Mark Crispin)
Subject: FTP continued  
To:   MsgGroup at USC-ISI, Header-People at MIT-MC
To:   Feinler at SRI-KL, Postel at USC-ISIB   

The responses I have received so far seem to indicate that the new FTP
protocol is not implemented by anybody, and that there are enough
differences between the new and the old FTP protocols so that a
different type user and server probably could not talk to each
other effectively.

Additionally, the people who replied to me were unanimous in their
feelings that the new protocol should be flushed and replaced with a
well-documented version of the old protocol.  The feeling seemed to be
that if any changes were necessary to the protocol, it should be in
the reply codes to ensure standardization and to make them more
esoteric.

Because of this, I am asking the network hacker community if anybody
is interested in forming a new "FTP group", to be charged with the
responsibility NOT to design a new FTP protocol, but rather to get an
agreed-upon standard documentation for the old protocol and possibly
change the sense of some of the reply codes.  The FTP protocol that
results from this group's efforts is to conform to the reality of
today, instead of generating a protocol that someday might be reality.
The only changes to existing programs should be ones which are to
correct what are violations of protocol today.

What does everybody think?  Jake and Jon, please forward this to
the RFC and network liaison groups; and please also inform us what the
chances of this project meeting with official sanction?  I really
believe that having a documented protocol which nobody implements
while the implemented protocol is undocumented is intolerable; and I
hope it isn't a case of an immovable object and an irresistable force.

regards,
	-- mark

-------

Date: 6 MAR 1978 1948-EST
From: KLH at MIT-MC (Ken Harrenstien)
To: mrc at SU-AI
CC: HEADER-PEOPLE at MIT-MC, MsgGroup at USC-ISI

Read RFC 691.  It should be available from SRI-KL as <NETINFO>RFC691.TXT.
It has been around for quite a while, proposes ways in which the
advantages of new FTP can be obtained with old FTP, and other good stuff.
Probably it has not been pushed as much as it should have been because
the author (Brian Harvey) took off for Paris for a couple years shortly
after writing it.  However, in one of my recent RFC's (XRSQ/XRCP, #743)
I explained my position on reply codes, pointed out the 3 possible sets,
and declared intent to use 691's - and nobody has commented.  So perhaps
the answer is that nobody reads RFC's.  In any case the preface to the
"new FTP" document lists RFC numbers which you can look up (or ask the NIC for)
to get the scoop on old FTP and bickering thereof.

Date:  7 Mar 1978 1020-PST
From: Kahler at SUMEX-AIM
Subject: May I be put on the mailing list?
To:   Header-People at MIT-MC

	Can someone also show me where the previous Header-People
messages are?  I am a member of MSGGROUP and don't want to miss the
Header-People stuff.

				Rich
-------

Date: 09 MAR 1978 1337-EST
From: JZS at CCA
Subject: Re: May I be put on the mailing list?
To:   Kahler at SUMEX-AIM
cc:   Header-People at MIT-MC

In response to your message sent  7 Mar 1978 1020-PST

Header-People messages and the mailing list are maintained by Ken Harrenstien
on MIT-MC.

In addition, all Header-People messages are archived on the Datacomputer
at CCA, and may be retrieved by sending a Retrieval Request to MARS-Retriever
(or MARS-R) at CCA.  I'm including, below, a sample RR which will retrieve
the first month's messages.  The date qualification is used to avoid getting
nearly 800 messages (some of them quite lengthy) all at once.

SAMPLE RR:

  (send message to MARS-R or MARS-Retriever@CCA)
  (SUBJECT: field is not used for retrieval)

  (the message body is the 'request form')
  TO: Header-People
  SINCE: 24 Sept 1976
  UNTIL: 24 Oct 1976
-------

It is also possible to retrieve on the basis of words in the subject-field
of the filed messages (e.g., SUBJECT: FIPS), and separately on the basis of
words in the message body (e.g., TEXT: proposed standard).

RFC744 describes MARS service more fully.  I'd be glad to send you a copy -
and to answer any other questions you might have about it.

Joanne Z. Sattley
JZS@CCA
-------

Date: Fri, 10 Mar 78 14:21-PST
Subject: RFC 733 Mail standard:  Group Names
From: Dcrocker at Rand-Unix
To: Header-People at Mit-Mc
cc: Borden at Rand-Unix
Message-ID: <Dcrocker.78.68.142117 @ Rand-Unix>

I have two points to raise and want to keep the discussions
separate, so the second will come in a different message.

In implementing a parser for 733, we discovered that having group
names be optional makes life much more difficult, even tho it
isn't ambiguous.  The problem is that, when beginning an
<address> parse, encountering a ":" doesn't have a single meaning
and it can be quite a while before you get to the comma or colon
or other separator that decides the issue.  For example:

	:include:foo at bar;;

consists of two groups, one nested inside the other, where the
first has no name, and the second is named "include".  That may
be a strange construction, but it's legal and the ambiguity isn't
fully resolved until the first semi-colon is encountered.

My suggestion is that we make life vastly simpler by requiring
groups to have names.  Therefore, if you hit a colon at the
beginning, you know you have a "data type" label.

Comments?

Dave.

Date: 10 Mar 1978 1735-PST
From: Kahler at SUMEX-AIM
Subject: Great big long message coming
To:   [ISI]<MsgGroup>Mailing.List;149:, Header-People at MIT-MC,
To:   Roach at MIT-MULTICS, Saltzer at MIT-MULTICS,
To:   Tavares at MIT-MULTICS, Sproull at CMUA, Wulf at CMUA

	I wrote six pages of comments for the proposed FIPS which
I will be sending to Shirley Watkins at NBS-10 and copying to you.
I spent a lot of time on it, I hope it is read at NBS.

				Rich
-------

Date: 10 Mar 1978 1817-PST
From: Kahler at SUMEX-AIM
Subject: Comments on proposed FIPS for user-terminal protocols
To:   Watkins at NBS-10, pyke at NBS-10
cc:   [ISI]<MsgGroup>Mailing.List;149:, Header-people at MIT-MC,
cc:   Roach at MIT-MULTICS, Saltzer at MIT-MULTICS,
cc:   Tavares at MIT-MULTICS, Sproull at CMUA, Wulf at CMUA


				March 10, 1978


Associate Director for ADP Standards
Institute for Computer Sciences and Technology
National Bureau of Standards
Washington, DC 20234


	Comments regarding the proposed Federal Information Processing
Standard entitled "User-Terminal Protocols -- Entry and Exit Procedures
between Terminal Users and Computer Services", found in the Federal
Register for Monday, December 12, 1977, pages 62408-62416:

	I wish to suggest several ways to increase the flexibility of
the standard so it may better "benefit the users of computer services"
and "in so doing impose minimal constraints upon the suppliers of
computer services" (from the introduction, page 62408).  These
suggestions fall under the following categories:

1. User waiver of the standard's requirements
2. Who handles what?
3. Flexible ordering of system messages
4. Line editing
5. Exit-choice message
6. Available help
7. Multiple communications networks
8. Linefeeds


	       USER WAIVER OF THE STANDARD'S REQUIREMENTS

	The protocol specified in the proposed standard is intended, and
should be intended, for the use of computer novices and infrequent
computer users who need a simple, understandable, predictable means of
reaching their destination.  As I understand it, there is no reason to
require that more experienced users use the same protocol.

	Computer services do make a great variety of tools available to
users during the entry/exit process with which the novice need not
concern him or herself, but which the more experienced user finds very
valuable.  It is not the purpose of the standard to provide all these
tools in a standard fashion.  Neither do the goals of the standard
make it in any way necessary to deny the experienced user access to
these tools.

	We therefore need to provide in the standard a means for the
user to waive its requirements and interact with the computer service
in its own language and on its own terms, as is now the case, in order
to have the full power of the computer service available to him or her.

	For example, make the word "WAIVE" and/or an "escape signal"
such as the ASCII ESC code an acceptable user response to any of the
system prompts specified in the standard, at which point the user will





be able to interact with the computer service as though this standard
had never been in force.

	This implies, of course, that the exitrequest signal will not
be recognized by the computer service as such.  That in fact is what
would be desired by such a user, otherwise, the waiver would only be
a partial one.

	Let the waiver be an implementor option.  The implementor need
not provide an alternative means of entry and exit outside the standard,
but should be free to do so.  All implementors of course do so now,
since there is no standard in force at this time.


			WHO HANDLES WHAT?

	The definition of "computer service" provided in Appendix B
and the rigid destination-userID-password sequence provided in the
body of the proposed standard are the source of serious confusion.
Is the user to be required every time to interact with a terminal
telecommunications network which prompts him or her for a computer
service name (destination) and then makes the connection, whereupon the
computer service requests user identification and password at its
option?  Or is the network required to obtain destination, userID, and
password from the user and actually log the user in at the destination?
(This would cause an uproar.  It would require that the network control
every computer service on every network it had access to.  Computer
installations would be unable to manage their own affairs.)

	Who is supposed to intercept the exitrequest signal, the
computer service or the network?  If the computer service, how will
the user exit the network if the service malfunctions?  If the network
intercepts the signal (as it should, being closer to the user) how can
the user exit from the computer service first using a means provided
by the standard?  Worse yet, is a destination, as some speculate, an
individual program running under the operating system of a computer
service?  A separate login might then be required to run each separate
program!  (This does not seem to be the case in view of the definition
of "computer service", but the definition itself (A coherent logical
entity...) is too vaguely general for me to be sure.)

	What the drafters of the proposed standard envision may be
entirely different than any of the above, in which case can it be
called a clear, concise, well-thought-out document in view of the
wide range of futile attempts to read its meaning?

	My conclusion, after all this, is that the standard's authors
in the attempt to make the network's operations transparent to the user
(see Appendix A) have themselves confused the operation of the network
with the operation of the computer service.  I would recommend that
we remember that the network is a computer service in its own right,
performing a valuable function for the user, yet physically and logically
separate from the destination computer services it serves.  Perhaps the
inexperienced user doesn't need to know this, but we do.





	The definition of "computer service" needs to reflect this
understanding and be more simply, concisely and understandably defined,
perhaps as:  "A computer running a program that interacts with a user
through a terminal, sending messages to the terminal and accepting
commands and data from the user."  There are many computer services
which do not deal with user terminals, but we are not concerned here
with them.

	It is the network's task to obtain a destination from the user
and make the connection.  It is then up to the destination computer
service whether or not to ask for user name and password before
proceeding.  If there is no network intervening, a destination request
is superfluous.  The exitrequest signal (or some panic signal, see below
under multiple communications networks) must be handled by the computer
service (network or otherwise) closest to the user.  If a panic-exit
signal is provided for the user, the exitrequest signal can be sent
through to be handled by the most remote computer service in use at the
time.


		  FLEXIBLE ORDERING OF SYSTEM MESSAGES

	There are only three combinations of the three parts of the
entry protocol allowed by the proposed standard:  destination only, or
destination-userID or destination-userID-password.  In practice, any
combination will come up.  If the standard is to be designed so as "not
to impede technological advancements in computer services and networks"
(from the introduction, page 62408), much greater flexibility is needed.

	In my networking experience I have personally encountered:

destination-ID,
destination-ID / user-ID / user-password,
destination-ID / destination-password / user-ID / user-password,
destination-ID / destination-password,
destination-password,
destination-password / user-ID,
destination-password / user-ID / user-password,
user-ID,		and, most frequently,
user-ID / user-password.

	These are all legitimate and proper combinations, and more are
possible.  Can this variety be any source of confusion in the user's
mind, provided that prompting for each is uniform?  When the user is
prompted for a destination, password, or anything else in a consistent
fashion, it is clear what is wanted, the user supplies the information
and the interaction proceeds.  The user is happy and the implementor has
the information he or she needs in the order he or she needs it.  I
suggest that no specific order be required.

	I also suggest that the prompt for user identification be
"Enter user identification" rather than "Enter identification", since
in the majority of cases this prompt will be the first given, and it
would otherwise be ambiguous which kind of identification is required.





			  LINE EDITING

	Line editing capabilities are entirely unaddressed by the
standard.  This is a serious omission, especially from the novice's
point of view.  Any standard which attempts to serve the needs of the
terminal user should provide a means for the user to correct typing
errors before giving the user signal.  Uniformity in line editing
practices for the interactions covered by this standard would be
as beneficial to the novice as the standardization of the system
messages required for them.

	I propose a minimum of two editing signals for standardization.
These may be called cancel-last-character and cancel-entire-line.  The
cancel-last-character signal requests that the computer service cancel
the last text character typed in, whereupon the next-to-last text (i.e.
non-editing-signal) character typed in becomes the last.  Repeated
cancel-last-character signals eventually would cancel the entire line.
The cancel-entire-line signal would ask the computer service to ignore
all that has been typed in since the system signal was last given,
optionally print " XXX " on the current line, and repeat the system
signal.

	The system response to the cancel-last-character signal may take
one of several forms.  On display terminals, when terminal character-
istics are known to a sufficient extent, the character may be erased
from the screen.  On other terminals, the cancelled character may be
retyped, preceded or followed by a slash (/), or preferably surrounded
by square brackets ([]).  It is not difficult, when several characters
are cancelled in succession, to delay the printing of the right square
bracket until some other character than cancel-last-character is typed.
A typescript showing :ABCDE[EDC]ACUS would, if retyped by the system, be
:ABACUS.  The user, in this case, had typed "ABCDE###ACUS", where "#"
indicates the cancel-last-character signal.

	My suggestions for default values for these signals:

cancel-last-character	DEL	(DELETE, RUBOUT)	and/or
			BS	(BACKSPACE, control-H)

cancel-entire-line	CAN	(CANCEL, control-X)

	Two other useful editing signals are cancel-word and retype-line,
but ASCII has no control codes set aside for these functions.  Cancel-word
cancels characters up to, but not including, a space or tab.  Retype-line
shows the user what the input line really looks like after editing has
been done.

cancel-word		ETB	(control-W)
retype-line		DC2	(control-R)





			EXIT-CHOICE MESSAGE

	The exit-choice message (whose format may well have been the
result of careful deliberation):

Enter one of the following:  Terminate or Leave or Stay or Suspend
:

is too long to be typed out on a 110 or 300 baud terminal every time the
user wishes to exit, regardless of the fact that abbreviations may be
available.  In practice, users often need or wish to exit quickly.  I
suggest:

Enter exit choice (Type ? for help)
:

(which is bad enough), with the requirement that help be offered in the
same fashion as with the abbreviated form request.  Perhaps implementors
can be given the option of implementing either the longer message with
no help provided or the shorter message with help available.


			  AVAILABLE HELP

	The interests of the user would indeed be served if HELP, ?, and
LIST were acceptable user responses every time the user is prompted with
the system signal, as with the abbreviated form request, so that the
user may have help at any point.  Such a consistent feature would be
welcomed by many a confused user, and would likely be found in use at
one time or another at every point at which it is offered.  If not
required it should at least be permitted.


		  MULTIPLE COMMUNICATIONS NETWORKS

	When, for example, two networks are involved in the connection
process to a destination, the standard should make it clear that the
user needs to give the second network as the destination to the first
network, then the real destination to the second network.  The first
network cannot be required to know the names of all destinations
accessible from all connecting networks.  If such a thing is meant to be
required, let that be clearly stated.  Implied requirements such as
these, which upon examination prove to be unreasonable and unworkable,
are of course unacceptable.  They are evidence that the impact of the
standard, first on implementors and then on users, is not well
understood.  This is another result of the effort to make the network(s)
involved totally transparent to the user.

	When a network is invoked in the terminal communications
process, it will identify itself, request a destination of the user
and make the connection.  Each network invoked in turn identifies
itself and repeats this simple process.  The user will know by this
interaction that he or she is talking for that brief period to a





network.  The network must provide a means for a panic exit for the
user's safety, and the user should be aware that when the exitrequest
signal (sent all the way down the line to the final destination) doesn't
produce any results, there is still a way out.  The panic signal, though
armed by all networks (unless the user has issued a waiver), will be
trapped of course by the first network in the chain, which will perhaps
initiate a normal exit-request sequence.

	This is the minimum awareness a user must have of the network.
In my opinion, every user using a network needs to know this much for
his or her protection.  It need not be at all confusing to the novice
when properly and simply explained and demonstrated.  The novice need
know no more about the presence of the network than this.

	Regarding a default value for the panic-signal, I would suggest
what is probably one of the least used control characters in ASCII
because it is more difficult to type.  It cannot be typed by holding the
CTRL key down and typing a letter.  It is FS (control-backslash), octal
34, decimal 28.  The ESC (escape) code, though it may seem appropriate,
is too heavily used for program commands and setting terminal parameters
to be armed for a special purpose throughout the terminal session.  I do
suggest it for user waiver of the standard protocol (see above), because
it will only be recognized as such during an entry/exit sequence.


			   LINEFEEDS

	A minor detail - the ASCII linefeed character (LF) should also
be in the list of characters required to be displayed by the terminal.
The ASCII carriage return character (CR) returns the carriage to the
left margin on the current line.  An LF must follow the CR to move the
carriage down to the next line.  Even though some terminals will do a
CRLF combination every time they receive a CR, this is not ASCII, and is
not desirable for such applications as underlining or overstriking text
on a line-by-line basis.  The confusion arises because in common
practice when the user types the CR key on a full-duplex terminal it is
echoed by the system as CRLF.


	The drafting committee needs to have experienced assistance from
users and implementors who are familiar with existing terminal
communications networks like the ARPANET and TYMNET.  Otherwise it may
come up with another proposed standard that is impractical to implement
where networks are concerned.

	I hope you will give these comments careful consideration.


				Sincerely,

				Richard Q. Kahler
				SUMEX Computer Project
				TB105, Stanford University Medical Center
				Stanford, CA 94305
-------

Date: Saturday, 11 Mar 1978 0220-EST
From: Philip.Karlton at CMU-10A
Subject: Re: RFC 733 Mail standard: Group Names
To:   Dcrocker at Rand-Unix
CC:   Header-People at Mit-Mc
Message-ID: <11Mar78 022000 PK01@CMU-10A>
In-Reply-To: <Dcrocker.78.68.142117 @ Rand-Unix>

I go along with the suggestion for forcing groups to have a non-null name.

PK

Date: Sunday, 12 Mar 1978 1920-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: Proposed FIPS standard for User-Terminal protocols
To:   Watkins at NBS-10, Pyke at NBS-10
CC:   MsgGroup at ISI, Header-People at MIT-MC, Roach at MIT-MULTICS,
      Saltzer at MIT-MULTICS, Tavares at MIT-MULTICS

Associate Director for ADP Standards
Institute for Computer Sciences and Technology
National Bureau of Standards
Washington, DC 20234

Re:	Proposed FIPS entitled "User-Terminal Protocols -- Entry and
        Exit Procedures between Terminal Users and Computer Services"

Sir or Madam:

There are two difficulties with the proposed standard:

  (1)   Technical problems with the details of the standard.
  (2)   Administrative problems with the scope of applicability of
        the standard.

I shall try to be brief rather than exhaustive.  

(1) The first point is just a couple of nits:

    - The DLE character (Data Link Escape) does not mean "escape from
      the data link", it means "begin an escape sequence" and is to
      be used by protocols within the data link.  It is probably a
      very bad idea to have a single character be used to signal an
      exit request, but if you must use a single character, the
      correct one is probably EOT (End of Transmission).

    - There are no provisions for line and character editing: what is
      typed to erase a character or a line.

(2) The second point is the meat of my comment.  This standard is
    intended to apply to "Computer Services" It would be quite
    reasonable to standardize the login/logout procedure for turnkey
    user programs used by non-programmers, many of whom are hostile
    towards computer systems and want only the results of the user
    programs.  For this set of computer users, namely those who are
    using canned software as a tool in the course of their daily
    work, there should be not only a standardized login/logout
    procedure but an attempt made to shield them from the knowledge
    that they are using a general-purpose interactive computer
    system.

The authors of this standard have correctly noticed that users of
    turnkey software systems are often hostile towards the computers
    and annoyed at the differences that they find, but these turnkey
    system users, although numerous and influential, are not the only
    class of user of computer services procured by the Government.
    Programmers of any kind, whether Cobol trainees at HEW or
    assembly-language experts at some weapons lab, will be driven up
    the wall by this standard.

The authors of this standard should recognize that these various
    classes of users exist, and should restrict the applicability of
    the standard so as to cover turnkey software services rather than
    all computer use.



                                        Brian K. Reid
                                        Graduate Student
                                        Department of Computer Science
                                        Carnegie-Mellon University
                                        Pittsburgh, PA  15213

Date: Sunday, 12 Mar 1978 1920-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: Proposed FIPS standard for User-Terminal protocols
To:   Watkins at NBS-10, Pyke at NBS-10
CC:   MsgGroup at ISI, Header-People at MIT-MC, Roach at MIT-MULTICS,
      Saltzer at MIT-MULTICS, Tavares at MIT-MULTICS

Associate Director for ADP Standards
Institute for Computer Sciences and Technology
National Bureau of Standards
Washington, DC 20234

Re:	Proposed FIPS entitled "User-Terminal Protocols -- Entry and
        Exit Procedures between Terminal Users and Computer Services"

Sir or Madam:

There are two difficulties with the proposed standard:

  (1)   Technical problems with the details of the standard.
  (2)   Administrative problems with the scope of applicability of
        the standard.

I shall try to be brief rather than exhaustive.  

(1) The first point is just a couple of nits:

    - The DLE character (Data Link Escape) does not mean "escape from
      the data link", it means "begin an escape sequence" and is to
      be used by protocols within the data link.  It is probably a
      very bad idea to have a single character be used to signal an
      exit request, but if you must use a single character, the
      correct one is probably EOT (End of Transmission).

    - There are no provisions for line and character editing: what is
      typed to erase a character or a line.

(2) The second point is the meat of my comment.  This standard is
    intended to apply to "Computer Services" It would be quite
    reasonable to standardize the login/logout procedure for turnkey
    user programs used by non-programmers, many of whom are hostile
    towards computer systems and want only the results of the user
    programs.  For this set of computer users, namely those who are
    using canned software as a tool in the course of their daily
    work, there should be not only a standardized login/logout
    procedure but an attempt made to shield them from the knowledge
    that they are using a general-purpose interactive computer
    system.

The authors of this standard have correctly noticed that users of
    turnkey software systems are often hostile towards the computers
    and annoyed at the differences that they find, but these turnkey
    system users, although numerous and influential, are not the only
    class of user of computer services procured by the Government.
    Programmers of any kind, whether Cobol trainees at HEW or
    assembly-language experts at some weapons lab, will be driven up
    the wall by this standard.

The authors of this standard should recognize that these various
    classes of users exist, and should restrict the applicability of
    the standard so as to cover turnkey software services rather than
    all computer use.



                                        Brian K. Reid
                                        Graduate Student
                                        Department of Computer Science
                                        Carnegie-Mellon University
                                        Pittsburgh, PA  15213

Date:     13 March 1978 0018-est
From:     Robert M. Frankston      <Frankston at MIT-Multics>
Subject:  Proposed FIPS for User=Terminal protocols
To:       Watkins at NBS-10, Pyke at NBS-10
cc:       MsgGroup at USC-ISI, Header-People at MIT-MC
cc:       Roach at MIT-Multics, Saltzer at MIT-Multics
cc:       Tavares at MIT-Multics

Associate Director for ADP Standards
Institute for Computer Sciences and Technology
National Bureau of Standards
Washington, DC 20234

While I find the concept of a standard for entering  and  exiting
computer  based services attractive in some ways, I feel that the
current attempts are premature and beset by technical problems.

The standard is both  too  constricting  and  too  vacuous.   The
essense seems to be the specification of a single destination and
establishment of the exit procedure.

The core of the entry procedure seems to be the specification  of
a destination (a strange term for the name of a service).    Only
one  service may be specified at a time.  This is a basic fallacy
since the use of a communications network is  itself  a  service.
In  Tymnet, for example, one must identify oneself to the network
for billing purposes and access control.     This  is  more  than
what  seems  to  be  allowed  for in carrier accommodation action
(4.1.3).  Of course, one  can  stretch  the  meaning  of  4.1  to
include  logging  into  a  computer  system  since  that  can  be
considered simply part of the establishment  of  a  communication
path,  and  in  doing so defeat the standard.  As has been ponted
out by others, specification of the service before authentication
is very arbitrary since one may not know which service is desired
before authentication.  As a matter of fact, in many systems, the
name  of  the  service  is  known  only  whithin  a  given  users
environment  (i.e. is listed in the user's directory) thus cannot
be known prior to authentication.  The  authentication  procedure
itself is limiting.  Some systems, like Multics (Honeywell 68/80)
combine  procedures  4.4  and  4.5  into  a single authentication
procedure so that one cannot determine the  validity  of  a  name
without  also  knowing  its  password -- an attempt at additional
security.  Since the definition of a service is so vague, Multics
can  even  be  considered  to  combine   specification   of   the
destination  into  the  same procedure in that the user's project
name is also specified during the authentication procedure.


As has been pointed out by others, the exit  procedure  also  has
problems.   Aside from the use of the DLE character in an unusual
manner there is the issue of which service interprets the control
code.  Also the attempt to limit one's choices of exit procedures
is premature.  One important class of exits is completely omitted
-- one in which the user can disconnect from a service, but leave
the service running noninteractively.

If the specification of the destination and the  exit  procedures
are  not acceptable,  one is left only with the use of the ":" as
a prompt to the user and the user of the return character to  end
messages to the computer system (oh yes, also the suggestion that
upper  and  lower  case  distinctions  be  ignored  -- a point of
contention among existing systems).  The user of, and  choice  of
signal characters seems to be a minor issue at this point.

It seems premature to enforce a rigid standard at this point that
completely governs the entry and exit procedures.

The attempt to provide a uniform interface for users of  computer
systems  seems,  however,  to  be a reasonable goal.  Perhaps the
failure of the standard is its meekness.  It requires  that  each
computer  system  and  service  be  modified to present a uniform
interface geared to the lowest common  denominator  of  terminals
and  classes  of  service.  A bolder approach is to associate the
smoothing  of  the  interface  with  the  terminal  that  can  be
personalized  to  the  user's needs.  What is requred is a set of
high level protocols for communication between a user's  terminal
and  a  computer  system.   Much  discussion  is needed if such a
protocol is to be developed, but the planning is necessary  since
any  confusion  due  to  differences  in  logging  in  and out of
computer systems is trivial as  compared  with  the  interactions
during  the  use  of  a  service,  especially with the ability to
provide  services  dependent  upon  characteristics  of  specific
terminals.

PS:  I want to  express  my  dissatisfaction  with  the  lack  of
publicity  given  to  the  standard.   Admittedly  this is just a
Federal standard that is not intended to limit commercial  usage.
However,  if  the  standard is to be implemented on a system by a
manufacturer, the effect will be felt by all users.

Date: 13 Mar 1978 2026-EST
Sender: HENDERSON at BBN-TENEXD
Subject: Proposed FIPS standard for User-Terminal protocols
From: HENDERSON at BBN-TENEXD
To: Watkins at NBS-10, Pyke at NBS-10
Cc: MsgGroup at ISI, Header-People at MIT-MC
Message-ID: <[BBN-TENEXD]13-Mar-78 20:26:53.HENDERSON>

Associate Director for ADP Standards
Institute for Computer Sciences and Technology
National Bureau of Standards
Washington, DC 20234

Re: Proposed FIPS entitled "User-Terminal Protocols -- Entry and
    Exit Procedures between Terminal Users and Computer Services"

Sir or Madam:

There are a number of problems with the proposed standard, but I
wish to focus on one only.

Computer systems will only be regarded as useful tools when they
become forgiving of human errors.  Even more strongly: they
should be programmed so that the propensity for error among human
is recognized and the computer can put its powerful resources to
use in helping to correct them.  We should strive for
habitability as much as for power, for to be useful a tool must
have both of these characteristics.

The standard is not habitable as far as I am concerned.

In entering the login information, no interaction with the user
to help in this task is permitted: for example, how can a
mistyped character be corrected?

It is easily possible to mistype such that the terminal which one
uses issues a DLE.  For example, certain keyboards have the CNTL
mode shift key beside the SHIFT mode shift key (the HP2645A, for
example).  Thus by a slight mispositioning of one finger, the
attempt to type an uppercase P could cause immediate and
irrevocable logout from the system.

This seems a bit harsh.

Sincerely,

D. Austin Henderson, Jr.
Computer Scientist
Bolt Beranek and Newman Inc.
Cambridge, Mass., 02138

Date: 13 MAR 1978 1905-PST
From: POSTEL at USC-ISIB
Subject: group names in 733
To:   Header-People at MIT-MC
cc:   postel

Dave:
i agree that groups should have (non null) names.
--jon.
-------

Date: 14 Mar 1978 0034-EST
From: Rick Gumpertz at CMU-10A
Subject: group names
To:   Header-People @ MIT-MC
Message-ID: <14Mar78 003441 RG02@CMU-10A>

1) I have no objection to requiring nnon-null group names.

2) Once again, I solicit comments on how to indicate that an address
   list consists of two alternatives, such as "Header-People@MIT-MC" or
   "Gumpertz@CMU-10a, Postel@USC-ISIB, ..." where either the fiirst or the second
   (but not both) alternative is an acceptable address for further correspondence.
   Perhaps some sort of change to group names to allow an optional "group address"
   would be reasonable?

                Rick

Date: Tuesday, 14 Mar 1978 1801-EST
From: Philip.Karlton at CMU-10A
Subject: Administrative: Mailing list changes
To:   MsgGroup at USC-ISI, Header-People at MIT-MC
CC:   RdMail at CMU-10A
Message-ID: <14Mar78 180114 PK01@CMU-10A>

Please change Philip.Karlton@CMU-10A to Karlton@PARC-MAXC
Please add RdMail@CMU-10A.

From:  Tavares.Multics at MIT-Multics
Date:  03/20/78 1354-est
Subject:  Proposed FIPS
To:  Frankston at MIT-Multics, Roach at MIT-Multics,
To:  Saltzer at MIT-Multics, Tavares at MIT-Multics,
To:  Pyke at NBS-10, Watkins at NBS-10, Kahler at SUMEX-AIM,
To:  Feinler at SRI-KL, Gumpertz at CMU-10a,
To:  Newcomer at CMU-10a, Wactlar at CMU-10a
Message-ID:  [MIT-Multics]1.1.BBBJHLHwHjkkld

     Honeywell has responded to the proposed FIPS for login/logout in three
letters.

     The first, sent in January, suggests that the assumption made by the
standard that Government personnel tend to access more than one computer sys-
tem, is false.  It goes on to state that since the number of people accessing
only one system exceeds the number accessing multiple systems, the total impact
of having to re-learn the new procedures would be negative.  It continues by
expressing misgivings about the dichotomy of government purchasers insisting on
off-the-shelf products, and other government agencies requiring special feat-
ures for the government.  Added to this is a statement that "Government use is
a small percent of the total use", and mentions that users in the private sec-
tor do not seem to be interested in such a standard.

     The second, sent earlier this month by our CBEMA representative, expresses
"disappointment and concern that the Government has chosen to by-pass the pub-
lic voluntary consensus standards-developing process", and quotes the relevant
policy statement.  It also warns against finessing the newly formed
ISO/TC97/SC16 committee which is attempting to deal with just this problem.

     The third, sent just last week, was a nine page report dealing with spe-
cifics, and expressing much of the same horror I have found in network communi-
cations from others on this topic.  Among the b^etes noirs mentioned were the
upper-case only restriction, multi-network piggybacking, the single character
exit request (which may be signalled by a dirty comm line), security implica-
tions of telling a user whether it was the username or password that was wrong,
and numerous requests for clarification.  The letter ends by giving the propos-
ers A for effort, but recommends it be referred to ANSI for more work.

C. D. Tavares

Date: 20 Mar 1978 1418-EST
From: Rick Gumpertz at CMU-10A
Subject: FIPS
To:   MsgGroup @ USC-ISI, Header-People @ MIT-MC
CC:   Tavares.Multics at MIT-Multics
Message-ID: <20Mar78 141814 RG02@CMU-10A>

Chris apparently missed a few relevent people in his TO list for this note.
I have taken the liberty of forwarding it.

                Rick

- - - - Begin forwarded message - - - -
From:  Tavares.Multics at MIT-Multics
Date:  03/20/78 1354-est
Subject:  Proposed FIPS
To:  Frankston at MIT-Multics, Roach at MIT-Multics,
To:  Saltzer at MIT-Multics, Tavares at MIT-Multics,
To:  Pyke at NBS-10, Watkins at NBS-10, Kahler at SUMEX-AIM,
To:  Feinler at SRI-KL, Gumpertz at CMU-10a,
To:  Newcomer at CMU-10a, Wactlar at CMU-10a
Message-ID:  [MIT-Multics]1.1.BBBJHLHwHjkkld

     Honeywell has responded to the proposed FIPS for login/logout in three
letters.

     The first, sent in January, suggests that the assumption made by the
standard that Government personnel tend to access more than one computer sys-
tem, is false.  It goes on to state that since the number of people accessing
only one system exceeds the number accessing multiple systems, the total impact
of having to re-learn the new procedures would be negative.  It continues by
expressing misgivings about the dichotomy of government purchasers insisting on
off-the-shelf products, and other government agencies requiring special feat-
ures for the government.  Added to this is a statement that "Government use is
a small percent of the total use", and mentions that users in the private sec-
tor do not seem to be interested in such a standard.

     The second, sent earlier this month by our CBEMA representative, expresses
"disappointment and concern that the Government has chosen to by-pass the pub-
lic voluntary consensus standards-developing process", and quotes the relevant
policy statement.  It also warns against finessing the newly formed
ISO/TC97/SC16 committee which is attempting to deal with just this problem.

     The third, sent just last week, was a nine page report dealing with spe-
cifics, and expressing much of the same horror I have found in network communi-
cations from others on this topic.  Among the b^etes noirs mentioned were the
upper-case only restriction, multi-network piggybacking, the single character
exit request (which may be signalled by a dirty comm line), security implica-
tions of telling a user whether it was the username or password that was wrong,
and numerous requests for clarification.  The letter ends by giving the propos-
ers A for effort, but recommends it be referred to ANSI for more work.

C. D. Tavares
- - - - End forwarded message - - - -

Date: 21 Mar 1978 0038-PST
From: MRC at SU-AI (Mark Crispin)
Subject: message reliability, and a plea!  
To:   Header-People at MIT-MC, MsgGroup at USC-ISI
To:   Feinler at SRI-KL, Malman at BBN-TENEXE 

In the course of the past few days, I have observed several cases
where mail has not gone through for no good reason.

My first gripe has to do with WHARTON being in this mode where any
ICP to them ICP's back to your own host on the same socket.  I
understand that this mode is used for debugging the IMP interface.
If so, WHY wasn't the NCC and the NIC told about this?  And if
they were, WHY weren't the network liaisons told?  This means that
mail to a person at WHARTON, instead of being delayed, it gets
sent to that user-id at the sender's host!  [God forbid a message
ever get sent to a local user who has his/her mail forwarded to
WHARTON--it will loop endlessly!]

Please, people, if you are going to fool around like that, tell
the rest of the world so we can make sure you will get your mail!

I have also observed cases of messages being lost at other hosts
due to something strange they are doing.  For example:

At CMU, apparently when the system is in "no login" mode (preparing
for PM?) they accept FTP connections, but trying to mail to anybody
there gets told NO REMOTE LOGINS AT THIS TIME.  CMU should plain
refuse the FTP connection so the message will be queued (or whatever
is done when a host is down at the time) until CMU will accept mail;
or CMU should allow mail even when the system is in this state.

Harvard and NBS-10 both occasionally lose mail with a reply of
"?Ill Mem Ref at user PC 000001".  This message seems to indicate
a bug in the mail program at their end, which I am told is non-
repeatable but has been known for a long time.  I wish they would
do something about this.

RAND-UNIX occasionally says "local system failure" or some such
thing.

Part of my unhappiness stems from the fact that SAIL's mail queuer
does not mail the user the message s/he sent back, meaning it is
lost forever.  I've asked our mail maintainer to fix this problem
but he hasn't gotten around to it yet.  However, there is no good
reason why mail should be lost in these cases.

I wonder how many other sites have problems like these.  Such things
really degrade the reliability of ARPAnet mail greatly.

-- Mark

-------

Date:     21 March 1978 0915-est
From:     Robert M. Frankston      <Frankston at MIT-Multics>
Subject:  Mail refusals
To:   Header-People at MIT-MC, MsgGroup at USC-ISI
To:   Feinler at SRI-KL, Malman at BBN-TENEXE

I too have experienced CMU's login refusal.  The long term solution is
not for systems to refuse to communicate or fix all bugs.  Rather there
should be a reply code within FTP to say, I cannot process your request
now, but perhaps at some other time I will be able to.  The sender could
then treat that as a refusal.  Fancy senders can even inform the user's
of the progress of their message.

The issue of whether or not to return dead letters is a matter of local
policy. An alternative solution, one that I prefer, is for the mail
composition/sending program log a copy of the message for further
reference in any case so that the user can get back the original if the
copy sent is lost for any number of reasons, including those not
apparent to the actual mail queuer/server program.

Date: 21 Mar 1978 0640-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: Re: message reliability, and a plea!  
To:   MRC at SU-AI, Header-People at MIT-MC, MsgGroup at USC-ISI,
To:   Malman at BBN-TENEXE
cc:   FEINLER

In response to the message sent 21 Mar 1978 0038-PST from MRC@SU-AI 

The NIC has received no word from Wharton  for quite some time.
At the last encounter they indicated that they were up and that
the mailbox was now Wharton (instead of whatever else they had been
using).  This worked fine for a while and then mail to
Howard Morgan began being rejected.  He had used HMorgan also, so
I changed to this.  Again didn't work.  Was about to call to find out
what the problem was, but Mark seems to have pinpointed it.

Since I will have occasion to send them some hardcopy mail, I
will drop a copy of your complaint in the envelope.

Jake
-------

Date: Tue, 21 Mar 78 08:47-PST
Subject: Re: message reliability, and a plea!
From: Greep at Rand-Unix
To: MRC at Su-Ai (Mark Crispin)
cc: Header-People at Mit-Mc, MsgGroup at Usc-Isi, Feinler at Sri-Kl,
cc: Malman at Bbn-Tenexe
Message-ID: <Greep.78.79.084754 @ Rand-Unix>
In-Reply-To: Your message of 21 Mar 1978 0038-PST

Regarding your comment about  the  Rand-Unix  server  FTP  saying
`local  system failure', we return, as do all other sites, what I
believe to be appropriately numbered replies on conditions  which
temporarily  make  mail  delivery  impossible,  such  as no space
available  or  inability  to  access  necessary  resources.   Any
information  you or anyone else can provide on improper responses
coming from here (e.g. unnumbered replies) would be  appreciated;
yours is the first such report I have had.

From:  Pogran at MIT-Multics
Date:  03/21/78 1457-est
Subject:  Message reliability; reflected ICP's and interface looping
To:  MRC at SU-AI
cc:  Malman at BBN-TENEXE, Feinler at SRI-KL,
cc:  MsgGroup at USC-ISI, Header-People at MIT-MC
Message-ID:  [MIT-Multics]1.1.BBBJHLLcFpBhKM

Mark,

I'd like to elucidate the "reflected ICP" problem that you
mentioned with regard to Wharton.

It's not Wharton's fault, believe me.  It's the fault of the
designers and maintainers of the IMP hardware and software, in
not recognizing the effect that IMP-level maintenance software
would have on high-level (e.g., FTP and mail) software throughout
the ARPANET.  We have experienced precisely this problem a number
of times when the IMP port serving MIT-Multics was out of order
and was being repaired (or, more likely, waiting to be repaired)
by the Network Control Center.

The problem is that, as a diagnostic aid, the NCC likes to "loop"
the IMP's interface to a host.  This can be done in either of two
ways, both of which result in all messages directed at the host
in question being returned to their sender!  The first way this
can be done is that a bit can be set in the IMP to cause the host
interface in the IMP to loop the data around within the
interface.  This bit is normally turned on or off under program
control remotely from the NCC.  The NCC can then send messages to
that host port, and they will be returned, via the looped host
interface, to the IMP and to the NCC.  The NCC software then
looks for errors in the returned bits.  The NCC can turn this bit
on whenever they want to -- and they can just as easily forget to
turn it off again!

Looping can also be done physically at the IMP, by replacing the
normal cable to the host's IMP interrface with a "loop-around
plug" supplied with each IMP.  Tests just like the ones used with
the internal loop-around can be performed by the NCC, verifying
the last of the interface hardware.  Installation or removal of
this plug is generally done by site (host) personnel at the
request of the NCC.

I've gone into all this detail because I believe it will aid in
understanding the crux of the problem, which is this:  The NCC
seems to have the notion that while they've got the interface
"looped", in whatever manner, nobody but the NCC will try to send
messages to that host!  Of course, that's not true.  And, by
virtue of the symmetry in the IMP-Host protocol which causes the
IMP to route the wrapped-around NCC test messages back to the
NCC, ANY message sent to that host port will be routed back to
ITS sender.  And -- this is the point the NCC ignores -- the
symmetry of the Host-Host protocol results in any RFC directed at
a looped host port being re-directed to the SAME destination
socket at the ORIGINATING host!  So, an ICP gets reflected, a
mail request gets reflected, ...  you get the idea.

Now, because the NCC has the mistaken notion that nobody will try
to send messages to a host port which is broken, and therefore
looped, they will often leave an interface looped overnight,
when, for example, a problem has been diagnosed in the late
afternoon and a serviceman cannot be dispatched until morning.
When the host in question is a major Network server, you can
imagine the chaos!

When I first discovered this problem affecting MIT-Multics, I
suggested to Alex McKenzie that the IMP software be modified so
that, when an interface is looped under program control, the IMP
accepts messages for that interface ONLY from a designated host
-- e.g., the Network Control Center.  But nothing was ever done
about it.

So, Mark -- don't be cross with the Wharton people!  Complain to
the NCC instead!

Yours for better networking,
 Ken Pogran

Date: 24 Mar 1978 0958-PST
From: MRC at SU-AI (Mark Crispin)
To:   Header-People at MIT-MC, MsgGroup at USC-ISI   

Date: 24 Mar 1978 1253-EST
From: SANTOS at BBN-TENEXE
Subject: Re: Interface Looping
To:   Pogran at MIT-MULTICS, MRC at SU-AI
cc:   Feinler at SRI-KL, Malman, JHaverty, McKenzie, Walden,
cc:   Santos



Ken and Mark,

Ken's message of 3/21 was forwarded to me. Ken is basically correct
in his description, although it should be pointed out that there is
an internal IMP "Host test" that the NCC frequently uses which does
not have these problems, i.e. the Host appears dead to the rest of
the network.

I have expanded the procedure for the NCC to use when conducting
tests on a Host interface. They will now first change the Host's
access control bits so that only the testing connection will be
allowed. Other attempted Host connections will get back a
Destination Dead (type 7, subtype 3). When they are done testing,
the NCC will restore the normal Host access bits. By the way,
the NCC does not often loop an interface and forget about it!

I would appreciate it if you could update all the people on the
original message's CC list as to our remedy. Also, feel free to
report this kind of thing to me in the future.

Regards,
Paul
-------

-------

Date: 30 Mar 1978 1209-EST
Sender: HENDERSON at BBN-TENEXD
Subject: Proposed MIL-STD-1679 (Navy)
From: HENDERSON at BBN-TENEXD
To: Header-people at MIT-MC
Message-ID: <[BBN-TENEXD]30-Mar-78 12:09:37.HENDERSON>

This standard is entitled:
	
               Military Standard
         Tactical Software Development

The cover also contains the folloing NOTE:

       NOTE: This darft, dated 1 August 1977, prepared
       by Headquarters, Naval Material Command has not
       been approved and is subject to modification.

Excerpt from contents:

       Section 5. Detailed Requirements.
       Section 5.3. Subprogram Design.
       Section 5.3.6 Recursive Programs. (page 5-6)
               Recursive procedures or programs shall not be used.
		
The interesting part is that this section is in the midst of a
design requirement which relects a strong requirement that
structured programming discipline be used.

Austin

Date: 25 APR 1978 0035-EST
From: PGA at MIT-MC (Phillip G. Apley)
To: HEADER-PEOPLE at MIT-MC

People at other installations:
Please place this conspicuously or put it on your message system.

If you have seen this information already and are not interested, sorry
to keep bugging you.  If you are interested please read this fully.  Some of
the information has been changed.

This is information about the MITERS Memory Co-op, a non-profit effort
dedicated to getting cheap silicon for hackers everywhere.  
The more people involved, the cheaper the deal.
No order is  too small or large.  Please tell your friends.

Date: 25 APR 1978 1127-EST
From: PGA at MIT-MC (Phillip G. Apley)
To: HEADER-PEOPLE at MIT-MC, pga at MIT-ML

People at other installations:
Please place this conspicuously or put it on your message system.

If you have seen this information already and are not interested, sorry
to keep bugging you.  If you are interested please read this fully.  Some of
the information has been changed.

This is information about the MITERS Memory Co-op, a non-profit effort
dedicated to getting cheap silicon for hackers everywhere.  
The more people involved, the cheaper the deal.
No order is  too small or large.  Please tell your friends.


                                       MIT ERS
                                    MEMORY  CO OP
                                 16K bits for $14.20
      
           The TMS4116-30 is  a 16K  by 1  bit dynamic  memory device  normally
      available for a minimum cost of $38. It is compatible with the NEC UPD416
      and  the MK4116. The version  we are purchasing is  a device with maximum
      access time 300ns, and read  write cycle time 500ns  in a 16 pin  plastic
      package.    Refresh  needs  to  be   completed  every  millisecond,   and
      temperature  is speced at 55C.   Thus far we  have data sheets for the 4k
      300 ns chip, for which timing is the same as the 4116-30. The  difference
      in  pinout is the substitution of an address bit for the Chip Enable line
      (the device must be externally latched).   Data is also available for the
      4116-25 (see your TI 'MOS Memory Handbook').
      
           The  Massachusetts  Institute   of  Technology-Electronic   Research
      Society is sponsoring this non-profit group purchase of TMS4116-30 memory
      components  from Texas  Instruments, intended  to bring  the low  cost of
      large purchasing to individuals  engaged in electronics  research.   Your
      signature  on this order  form indicates your  guarantee that you qualify
      for tax exemption as a  member of an educational organization  (including
      undergraduates)  engaged in electronics research.   The Massachusetts tax
      exemption number for your educational institution should be provided.
      
           The cost  of  the components  has  been calculated  to  include  the
      minimum  shipping and handling charge.   Cambridge residents will pick up
      their chips at  MITERS.   Unfortunately we are  unable to accept  credit,
      much as we would like to.   Your university can send a check along with a
      purchase order, otherwise a personal check will be fine.   Checks  should
      be  payable to 'MITERS Memory Co-op'.   No  orders will be accepted after
      May 5 1978.
      
      Any questions you may have will  be answered at 617-494-0168, or  contact
      PGA@MIT-ML through the ARPANET.
      _________________________________________________________________________
                                     ORDER FORM
      Send to:
           Phillip G Apley
           MITERS
           4 Ames St.
           #301C
           Cambridge, MA 02139
      Please order me n= ____ (where n is any integer) units of the TMS4116-30.
      Enclosed find a check or money order for n x $14.20= ____.
      I  realize that  MITERS is  responsible only  for delivery  of the stated
      number   of  new  memory  components   from  Texas  Instruments,  handled
      appropriately by  MITERS and  tested by  TI, or  for refund  of the  full
      amount  of  my  remittance,  at the  option  of  MITERS.   Components are
      guarranteed by  Texas Instruments  to meet  the specs  described  herein.
      MITERS  is not responsible  for any other  warranties either expressed or
      implied.
                   Name                 _____________________________
                   Net Address(?)       _____________________________
                   Shipping Address     _____________________________
                   City, State          _____________________________
                   Telephone            #____________________________
                   Tax exemption        #____________________________
                   Signature            _____________________________


P.S.
Real data sheets should be available shortly.

The chip is a little slow, but is just fine for microprocessors and
video displays.If your processor is a Z-80 you don't have to worry about
refresh at all unless you are doing DMA, in which case you have to
guarrantee certain timing constraints on your DMA channel.  

For comparison the next cheaper chip I was able to find was a
250ns version from NEC @ $20 in thousands.  

I have some and expect some more information about s-100 memory boards
which use these chips.  The SD Sales Board should be available at 30%off
if we get a $2500 purchase.

For further information stay tuned to the file ML:PGA;ERS TTY on ITS (MIT-ML)
or ask me.

Thanks for your interest.

Date:  3 May 1978 1906-PDT
From: Kahler at SUMEX-AIM
Subject: Moving to Oklahoma
To:   MsgGroup at ISI, Header-People at MC

	My family and I will be leaving California shortly after May 18,
1978 for Tulsa, Oklahoma to live with the summer heat, the winter cold,
the locusts and the oil wells.  I got married a year ago this month and
came face-to-face all of a sudden with the housing situation here on the
San Francisco Peninsula.  I will be working for Honeywell in Tulsa doing
software support for their Series 60, Level 68 (Multics) and Level 66
(GCOS) customers.  (I don't yet have the offer letter in my hand, but I
should in a few days.)

	This will be my first venture out into the "real world".  I
think it will do myself and my career a lot of good to find out what
corporate people want from their computers after helping here at
Stanford to meet the needs of medical AI researchers and college
students taking computer-assisted instruction (CAI) courses.  I am
looking forward to learning about Multics first-hand.  I'd like to see,
after reading Elliot Organick's book and many of the technical papers,
how such a secure system with a virtual memory such as Multics has can
be implemented without a prohibitive amount of overhead.  I'm glad it
can.

	If any of you with Multics experience can tell me your feelings
about the operating system and its user interfaces, I would greatly
benefit from your comments.  I haven't yet seen any literature more
recent than 1971, except for a 1976 Multics Pocket Guide, Commands and
Active Functions.

	In the human engineering category, TENEX (especially with our
local SUMEX-AIM stuff in it) will be hard to beat.  But since with
Multics you can in theory put any teletype interface you please between
you and the programs you run, maybe Multics is not at a disadvantage
there.  Not that any of my future customers would want terminal I/O that
wasn't vanilla Multics.

	I will retain my network address here at SUMEX-AIM for a year
or so, so it is not time yet to remove me from any mailing lists, but
I expect to be much less of a contributor than before (not that I have
contributed all that much), and much more a passive listener.

				Rich Kahler
-------

Date: Wednesday,  3 May 1978 2247-EDT
From: Brian Reid at CMU-10A
Subject: Re: Moving to Oklahoma
To:   Kahler at SUMEX-AIM
CC:   MsgGroup at ISI, Header-People at MC
Message-ID: <03May78 224737 BR10@CMU-10A>
In-Reply-To: Kahler's message of 3 May 78 21:06

Please keep us posted.
Go read Mark Twain's "Letters from the Earth"
Then perhaps "The Grapes of Wrath".
Do they have electricity in Oklahoma?

Date: Tuesday,  9 May 1978 0354-EDT
To:   Header-People @ mc

Date: 12 Jun 1978 1613-EDT
From: Rick Gumpertz at CMU-10A
Subject: The header of your last mail
To:   Feinler at SRI-KL (Jake Feinler)
CC:   Header-People @ MIT-MC
Message-ID: <12Jun78 161357 RG02@CMU-10A>
In-Reply-To: Jake Feinler's message of 11 Jun 78 23:26

Jake -

I think the sysntax of your TO: list is illegal -- it appears
to read To: [SRI-KL]<FEINLER>nlg-sndmsg-6-78: without any
terminating ";".  Am I correct??

                Rick

Date: 12 Jun 1978 1613-EDT
From: Rick Gumpertz at CMU-10A
Subject: The header of your last mail
To:   Feinler at SRI-KL (Jake Feinler)
CC:   Header-People @ MIT-MC
Message-ID: <12Jun78 161357 RG02@CMU-10A>
In-Reply-To: Jake Feinler's message of 11 Jun 78 23:26

Jake -

I think the sysntax of your TO: list is illegal -- it appears
to read To: [SRI-KL]<FEINLER>nlg-sndmsg-6-78: without any
terminating ";".  Am I correct??

                Rick

Date: 12 Jun 1978 1613-EDT
From: Rick Gumpertz at CMU-10A
Subject: The header of your last mail
To:   Feinler at SRI-KL (Jake Feinler)
CC:   Header-People @ MIT-MC
Message-ID: <12Jun78 161357 RG02@CMU-10A>
In-Reply-To: Jake Feinler's message of 11 Jun 78 23:26

Jake -

I think the sysntax of your TO: list is illegal -- it appears
to read To: [SRI-KL]<FEINLER>nlg-sndmsg-6-78: without any
terminating ";".  Am I correct??

                Rick

Date: 12 Jun 1978 1708-EDT
From: Rick Gumpertz at CMU-10A
Subject: Header-People
To:   KLH @ SRI-KL
CC:   Header-People @ MIT-MC
Message-ID: <12Jun78 170817 RG02@CMU-10A>

Why am I getting multiple copies of Header-People mail that I sent today??

                        Rick

Date: Tue, 13 Jun 78 16:52-PDT
Subject: Re: text message format question
From: Dcrocker at Rand-Unix
To: POSTEL at Usc-Isib, Rick.Gumpertz at Cmu-10a
cc: Dcrocker at Rand-Unix, postel at Usc-Isib, Header-People at Mit-Mc,
cc: Pogran at Multics, Vittal at Bbnb, Henderson at Bbnd,
cc: Feinler at Sri-Kl, Borden at Isd
Message-ID: <Dcrocker.78.163.165242 @ Rand-Unix>
In-Reply-To: Your message of 13 JUN 1978 1249-PDT

The requirement for the semi-colon was known when we specified
it, but I agree that it would be nice to be nice to old programs
if we can be so without purturbing the syntax unreasonably. This
leads me to ask for opinions about the following change to the
syntax in RFC 733:

Page 15, Section D, definition of <address>, change

    / ([phrase] ":" #address ";")

to be

    / ([phrase] ":" [#address ";"])

I would appreciate reactions from everyone receiving this note.
If the reaction is solidly enough positive, then we can probably
simply adopt it.

(Note that a address consisting only of a colon would become
legal.)

Dave.

Date: 13 JUN 1978 1939-PDT
Sender: CAINE at USC-ECL
Subject: Re: text message format question
From: CAINE at USC-ECL
To: Dcrocker at RAND-UNIX
Cc: POSTEL at USC-ISIB, Rick.Gumpertz at CMU-10A, 
Cc: Header-People at MIT-MC, Pogran at MULTICS, Vittal at BBNB, 
Cc: Henderson at BBND, Feinler at SRI-KL, Borden at ISD
Message-ID: <[USC-ECL]13-JUN-78 19:39:56.CAINE>
In-Reply-To: <Dcrocker.78.163.165242 @ Rand-Unix>

Dave,

I concur with your proposed syntax change. 

Steve

Date: 13 JUN 1978 2246-EDT
From: MOON at MIT-MC (David A. Moon)
To: HEADER-PEOPLE at MIT-MC

As long as Header-People seems to be active again, may
I push for public condemnation of mail systems which send
out headers containing user names with no host name?
For example:
	From: JRLuser at Some-Random-Tenex (J. Random Luser)
	To: Moon at MIT-MC
	CC: JRLuser, SOLuser, Foo at 3rd-Party
where JRLuser and SOLuser are users at the originating host.

Date: Wednesday, 14 Jun 1978 0020-EDT
From: Brian Reid at CMU-10A
Subject: Re: text message format question
To:   Dcrocker at Rand-Unix
CC:   Dcrocker at Rand-Unix, postel at Usc-Isib, Header-People at Mit-Mc,
      Pogran at Multics, Vittal at Bbnb, Henderson at Bbnd, Feinler at Sri-Kl,
      Borden at Isd, POSTEL at Usc-Isib, Rick.Gumpertz at Cmu-10a
Message-ID: <14Jun78 002007 BR10@CMU-10A>
In-Reply-To: <Dcrocker.78.163.165242 @ Rand-Unix>

I suspect that no matter what RFC733 reads, people are going to keep
generating those old TENEX-style address-list TO fields anyhow,
so I suspect that they ought to be legal.  Though I haven't tried it,
it seems that the "null address ==> optional semicolon" rule ought
not to be hard to parse.

Date: Tue, 13 Jun 78 21:25-PDT
From: Mike at Rand-Unix
To: MOON at Mit-Mc (David A. Moon)
cc: HEADER-PEOPLE at Mit-Mc
Message-ID: <Mike.78.163.212542 @ Rand-Unix>
In-Reply-To: Your message of 13 JUN 1978 2246-EDT

I agree with Mr. Moon.  Although a single user name without host
specification can be understood to refer implicitly to the host
the message came from, I would prefer that the host be explicitly
spelled out.  It also makes the 'reply' function in mail systems
easier to implement.

Date: 13 Jun 1978 2227-PDT
Sender: GEOFF at SRI-KA
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: Mike at RAND-UNIX
Cc: HEADER-PEOPLE at MIT-MC
Message-ID: <[SRI-KA]13-Jun-78 22:27:32.GEOFF>
In-Reply-To: <Mike.78.163.212542 @ Rand-Unix>

I disagree; I consider having the hostname there superfluous
information and cluttering up the to and cc lines is non-needed
crap.  It seems simple to me that users without host names after
them are on the host that the FROM person is.  Why should we tack
this on it each and every one of them again and again.  ugh.

Date: 14 JUN 1978 0145-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: Recipient names without host names
To: HEADER-PEOPLE at MIT-AI

If my RMAIL reply command had to parse the recipients
enough to find out whether they had hostnames,
it would be at least twice as slow.  So it just doesn't
handle them, and probably never will.


From:  Pogran at MIT-Multics
Date:  06/14/78 1005-edt
Subject:  Response to Geoff's anti-clutter comment
To:  Geoff at SRI-KA
cc:  Mike at Rand-UNIX, Header-People at MIT-MC
Message-ID:  [MIT-Multics]1.1.BBBJHXwhFcWwPP

Geoff,

I take issue with your statement that "users without host names after them
are on the host that the FROM person is".  It is equally reasonable that
one should interpret

CC: JRLuser, SOLuser, Foo at 3rd-Party

(to use Moon's example) to mean that all three of JRLuser, SOLuser, and Foo
are located at 3rd-Party.  At least, this interpretation was possible in
the pre-733 days.  The first mailer that came up on Multics did this, because
it seemed natural to me.  Of course, TENEX had already set a different,
de facto standard, and bigwigs out there in Networkland complained to me
that they could not use their TENEX "reply" commands, and would I please change
my program to conform to (harrumph!) "standard".

Ken

Date: 14 JUN 1978 1141-EDT
From: JZS at CCA
Subject: superfluous host names
To:   Geoff at SRI-KA
cc:   Header-People at MIT-MC

In the case of a message with all local recipients which is then
sent, forwarded or redistributed over the net, the inclusion of host
names would clarify rather than clutter -- especially for mail-reading
programs which try to sort out who is where and can't even after
extraordinary effort.  Oh well, it's at best an opinion from a
jaundiced perspective...
-------

Date: 14 Jun 1978 0752-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: headers & clutter  
To:   Moon at MIT-MC, Pogran at MIT-MULTICS
CC:   Header-People at MIT-MC    


I agree with Dave and Ken.  Like Geoff, I can't stand gigantic
mail headers, but at best, deleting the host name is only a drop
in the bucket, and it does have significant problems.

My feeling is that the clutter in mail headers are generated
mostly by programs which use all the hairy options by default (or
worse, because they can't be turned off).  An example of this is
getting a person-to-person message with a From, Reply-to, Sender,
Message-ID, and Cc all being the mailbox name of the originator
of the message!  [I won't name any names, to protect the guilty]
I really would like to see a public condemnation of all programs
which use extended header features for no good reason except that
they're there.

A secondary cause of message header clutter is when a message is
sent out to a large number of people (the famous DEC message
comes to mind instantly!) who do not need to know who the other
recepients of the message are, who probably do not want to know,
and in some cases should not know!  This problem seems to me to
be more of a case of insufficient usage of mailing lists, BCC,
and other ways to suppress the To list from coming out than a
lack in the protocol; although I wonder.  Maybe it would be a
good idea if suppression of To-lists was discussed in some
official context?  The only times I have seen these features used
were in formal system mailing lists (like Header-People) or in
private lists (like a person's "friends" mailing list, a party
invitation list, etc.), but almost never in one-shot mailings,
despite the length of the recepient list and the irrelevancy to
the recepient of whom else received the message.

About BCC's:  I recently received, as a BCC recepient, a fairly
sensitive message which the recepient of the message would have
been rather upset to know that I had gotten it.  Two other people
were on the BCC list, and all three of us saw the entire BCC
list!  This somehow seems morally wrong to me; it may be one
thing to talk about somebody behind their back (in a positive as
well as a negative sense) with another person, but doing it with
a group which knows the identity of its members seems to be
out-and-out conspiracy!

I thought BCC's were supposed to be truly blind; if the BCC item
is in the header, it is just to show the recepient why s/he got
the message.  Am I wedged?

-- Mark

-------

Date: Wed, 14 Jun 78 08:38-PDT
Subject: Re: Response to Geoff's anti-clutter comment
From: Greep at Rand-Unix
To: Pogran at Mit-Multics
cc: Geoff at Sri-Ka, Mike at Rand-Unix, Header-People at Mit-Mc
Message-ID: <Greep.78.164.083841 @ Rand-Unix>
In-Reply-To: Your message of 06/14/ [MIT-Multics]1.1.BBBJHXwhFcWwPP

If tenex sends out messages without explicit hostnames in the address
fields, then people sending messages from tenex should realize that
different interpretations exist and another host's system may not be
able to read their minds.

Date: 14 Jun 1978 1151-EDT
From: Rick Gumpertz at CMU-10A
Subject: Re: Recipient names without host names
To:   RMS at MIT-AI (Richard M. Stallman)
CC:   HEADER-PEOPLE at MIT-AI
Message-ID: <14Jun78 115141 RG02@CMU-10A>
In-Reply-To: Richard M. Stallman's message of 14 Jun 78 00:45

Although I think host names should be there whenever a message
goes out on the net, I cannot buy RMS's argument about doubling
the execution time.  Twice epsilon, or even 5 times it, is insignificant
when compared with the total cycles being expended in RMAIL, or for that
matter the MIT-ITS machines as a whole.  Arguments like that would have
us still using only upper case, because it is faster to parse.
When we argue execution time doubling, we really should take as a base
not the time spent in parsing but rather the entire time spent in compiosing
a reply!  We might even add the time expended by some poor human processor
trying to figure out why his mail didn't get through.

                Rick


Date: 14 Jun 1978 1157-EDT
From: Rick Gumpertz at CMU-10A
Subject: Re: headers & clutter
To:   MRC at SU-AI (Mark Crispin)
CC:   Header-People at MIT-MC
Message-ID: <14Jun78 115728 RG02@CMU-10A>
In-Reply-To: Mark Crispin's message of 14 Jun 78 09:52

It is not too hard for a mail printer to suppress the host name if it
is equal to the local host name.  Ours does this (I think) and it
seems to be a win.  Note that it is as easy as a single string comparison
(or maybe a few, if one allows decimal host numbers as well).

Therefore I say the host should always be there, letting the printer suppress it.

                Rick

Date: 14 Jun 1978 1302-EDT
From: JHAVERTY at BBN-TENEXD
Subject: (Response to message)
To:   GEOFF at SRI-KA, Mike at RAND-UNIX
cc:   HEADER-PEOPLE at MIT-MC, JHAVERTY

In response to the message sent 13 Jun 1978 2227-PDT from Geoff@SRI-KA 

Consider the problems which occur when a message gets forwarded,
redistributed, etc., and various places along the way add stuff
to the fields involved with host names.  Either you sacrifice
a little space in the header to carry the info, or you add
a fair amount of code everywhere to figure out when a 'naked' address
has to be changed to include the implied host, preparatory to forwarding,
replying, etc.
				Jack Haverty
-------

Date: 14 Jun 1978 10:28 am (Wednesday)
From: Horning at PARC-MAXC
Subject: Re: text message format question
To: Dcrocker at Rand-Unix
cc: POSTEL at Usc-Isib, Rick.Gumpertz at Cmu-10a, postel at Usc-Isib,
 Header-People at Mit-Mc, Pogran at Multics, Vittal at Bbnb, Henderson at Bbnd,
 Feinler at Sri-Kl, Borden at Isd,
 LAUREL Team: Brotz at PARC-MAXC, Horning at PARC-MAXC, Kierr at
 PARC-MAXC, Levin at PARC-MAXC, Schroeder at PARC-MAXC, Wegbreit at
 PARC-MAXC, Taft at PARC-MAXC;
In-Reply-To: Your message of Tue, 13 Jun 78 16:52-PDT

Dave,

By virtue of a programming error, Laurel (PARC's new message system) was
"nice to old programs," (i.e., we didn't detect a missing semicolon).  By popular
demand, we removed this "feature," because people would rather be notified of
header errors than have them interpreted other than they intended.

I think that that the proposed relaxation of syntax is a definite retrograde step;
we certainly wouldn't implement it again in Laurel.

Jim H.

Date: 15 Jun 1978 1001-EDT
Sender: HENDERSON at BBN-TENEXD
Subject: Re: BCC
From: HENDERSON at BBN-TENEXD
To: MRC at SU-AI
Cc: Header-People at MIT-MC
Message-ID: <[BBN-TENEXD]15-Jun-78 10:01:39.HENDERSON>
In-Reply-To: Your message of June 14, 1978

No, I don't think you're wedged.  I think the idea was to save on
computing different versions of the message for each BCC
addressee.  I think that this is a bad place to trade off
efficiency against function.

Actually I have from time to time advocated (the other days I get
very unsure) that the notion of different "versions" of a message
was immoral.  If I get a message indicating that three other
people got it I naturally assume that the other people got
IDENTICAL copies (CC = "carbon copy", which implies a pretty
strict copying function).  BCC copies are usually made by "typing
on a carbon".  Either that or they are put into an envelope which
indicates from whom they came, even though the message itself
does not.

There is nothing that prevents me sending out two messages saying
the same thing to two people, with neither knowing that I have
said it to the other.  So BCC-style cannot be legislated against.
But (on the advocating days) I feel that BCC should be removed
from our mail systems, and mechanisms for preparing a number of
messages with similar contents be relied upon for this function.
Then at least the Message-ID's will show that the messages are in
fact different, rather than versions of the same one.

(In re-reading this I discover that this is not really an
advocating day.  Regard this, therefore, as musings.)

Austin

Date: Thu, 15 Jun 78 09:31-PDT
Subject: Re: BCC
From: Greep at Rand-Unix
To: HENDERSON at Bbn-Tenexd
cc: MRC at Su-Ai, Header-People at Mit-Mc
Message-ID: <Greep.78.165.093108 @ Rand-Unix>
In-Reply-To: Your message of 15 Jun
In-Reply-To: <[BBN-TENEXD]15-Jun-78 10:01:39.HENDERSON>

If you consider the header to be an `envelope' and  not  part  of
the message proper, then it makes more sense to fudge things like
address lists on different  copies.   In  this  case,  though,  a
closer analogy would be the address on a letter showing through a
window envelope, since the header is seen  by  the  recipient  as
well as being used for delivery.

There is no reason the BCC field has to show up at all,  even  on
the BCC recipients' copies.  Then all copies are the same.

Date: 15 Jun 1978 1026-PDT
Sender: GEOFF at SRI-KA
Subject: Re: BCC
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: Greep at RAND-UNIX
Cc: HENDERSON at BBN-TENEXD, MRC at SU-AI, 
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KA]15-Jun-78 10:26:56.GEOFF>
In-Reply-To: <Greep.78.165.093108 @ Rand-Unix>

I think it is quite necessary for the BCC field to show up
because this then gives the receiver of the message an
`indication' of his `status' (if you will) on his seeing the
message.

i.e.  if you got a copy of a message addressed to some group
address like `To: Security-council-members:' and a copy of the
message showed up in your mailbox, with BCC: Greep at RAND-Unix
then you would know that is how you got the message, if the BCC
field was not required, you'd right away assume you've been added
to the members list and raise cain and possible embarrass the
person who BCC'd you in the first place.

I do agree though that people who are BCC'd should be aware of
other BCC'd parties -- however, perhaps this could be an option
of the particular message system to suit each persons feelings on
this matter.

g

Mail from OFFICE-1 rcvd at 15-Jun-78 1117-PDT
Date: 15 Jun 1978 1115-PDT
Sender: WMARTIN at OFFICE-1
Subject: Re: BCC
From: WMARTIN at OFFICE-1
To: Geoff at SRI-KA
Cc: wmartin
Message-ID: <[OFFICE-1]15-Jun-78 11:15:50.WMARTIN>
In-Reply-To: <[SRI-KA]15-Jun-78 10:26:56.GEOFF>
Redistributed-To: Header-People at MC
Redistributed-By: GEOFF
Redistributed-Date: 15 Jun 1978

It is logical that a BCC: field should appear in a
BCC-addressee's copy, as you said, to identify how that person
got the message.  However, why is BCC necessary at all?  It seems
more a source of problems and trouble than the minimal use it
gets is worth, at least in my eyes.  The simple way around the
situation is not to use BCC at all; the originator of a message
simply sends aa FORWARDed copy of his own file copy of the
message to the BCC recipient.  This is invisible to the original
recipients, of course, and, if the sender wants the BCC-type
receivers to know who else got a copy, he sends it to a list of
addressees--otherwise he sends it to a single address at a time.

This doesn't take much effort, and permits the inclusion of
comments to the BCC-type addressees as a side benefit.

Why have BCC at all if this fills the requirements?  What could
BCC do that this would not?

Regards, Will Martin

PS Please forward this to Header-People if you want.  WM

Date: Thu, 15 Jun 78 11:39-PDT
Subject: address list syntax
From: Dcrocker at Rand-Unix
To: Header-People at Mit-Mc
Message-ID: <Dcrocker.78.165.113921 @ Rand-Unix>

Nothing like asking a simple question and starting a war...

1.  In a previous note, I gave a group list example which did not
contain a group name.  I had forgotten that we agreed to require
them.  (To make it easier to distinguish group specs from
"extended data-types, which are delimited by surrounding colons.)

2.  The use of the BCC is and should be entirely up to the
sender.  IF the sender wants BCC recipients to know who they all
are, then they should all be shown in the field; otherwise, not.
Our personal preferences for its use shouldn't be imposed on
others.

3.  Only because nobody has mentioned it in the discussion about
absent host names from address lists, I'd like to point out that
that is patently illegal w/respect to 733.  In addition, the
degree of discussion, virtually free of consensus, that has just
taken place on the topic makes it clear to me that we should not
mess with the current spec.

4. Now about the optional semi-colon...

The semi is needed only in order to terminate an address sublist
(type = group).  It seems quite silly to require the thing when
that sublist is empty (i.e., when that name of the group is in
the address field, but its contents are not shown.  Horning
(PARC) raised the only objection and that seems mostly to rest
on the old use of group names to indicate a path to a file
containing the address list for the group (ergo, allowing
automatic inclusion of the list by functions like "reply").
Path-pointing is done in 733 completely separately, through the
:Include: construct.

Therefore, it seems that we can change the spec in RFC733, page
15, Section D, line 3 of <address> from

/ (phrase ":" #address ";")

to be

/ (phrase ":" [#address ";"])

I am very tempted to suggest that the sub-<address> should
be "1#address" thereby making the semi:colon legal ONLY when the
address sub-list is specified; but I doubt it's worth the hassle.

Comments?

Dave.

Date: Thursday, 15 Jun 1978 1459-EDT
From: Brian Reid at CMU-10A
Subject: BCC fields
To:   Header-People at MIT-MC
Message-ID: <15Jun78 145910 BR10@CMU-10A>
In-Reply-To: <Greep.78.165.093108 @ Rand-Unix>

CMU's RDMAIL does not generate a BCC field in the message at all;
nobody has yet complained about this characteristic.

Date: 15 Jun 1978 1203-PDT
Sender: GEOFF at SRI-KA
Subject: Re: BCC
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: WMARTIN at OFFICE-1
Cc: Header-People at MC
Message-ID: <[SRI-KA]15-Jun-78 12:03:00.GEOFF>
In-Reply-To: <[OFFICE-1]15-Jun-78 11:15:50.WMARTIN>

Your simple way around the BCC situation would be somewhat of an
inconvience for me because of the way I handle my mail.  I notice that
you and most others who keep copies of their outgoing mail merely just
CC themselves in the message itself.  I do not do this because it
makes the message system rescan my message file each time i send out a
message which takes time -- even more time in the middle of the
afternoon when the system is loaded, and 2ndly creates a garbage
collection problem in my MESSAGE.TXT primary file.  What I do is that
for every message i send out I put a copy (HERMES FCC) into a file
called SAVED.MESSAGES -- I also have my FDESTINATION in HERMES set to
SAVED.MESSAGES as well, so that when i am 'done' with a message I
simply MOVE it into SAVED.MESSAGES -- hence 'active' and unanswered
mail remains in my primary MESSAGE.TXT file while all processed mail
for the current month ends up in SAVED.MESSAGES -- then at the end of
the month I archive SAVED.MESSAGES and start afresh.

So for me, if I simply FORWARDed a copy of a message to someone (as
you suggested for BCCing ) it would require me to quit out of my
primary MESSAGE.TXT file, read in SAVED.MESSAGES, go scanning for that
message, then FORWARD it off (therefore adding more header trash), and
then return to my primary message file.  This operation also has some
sad side effects in that it makes me lose all 'recent' status on
messages i was handling before in my primary message file.

Also, in order for me to keep a record that I sent off this forwarded
BCC I must keep an ENTIRE copy of the forwarded message around!

Admittingly, BCC is only a convience to be had at COMPOSING time;
however, I have been using the REDISTRIBUTE feature of HERMES to send
later BCC's instead of FORWARDing them since REDISTRIBUTE then
modifies the header of the message in my SAVED.MESSAGES file to
indicate who i have redistributed it to, and doesn't require that an
entire separate copy of the message itself exist.

g 

Date: 15 JUN 1978 1618-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: Illegal headers
To: HEADER-PEOPLE at MIT-MC

During the recent flurry of Header-People messages I have received some
headers I'd like to complain about.  One message GEOFF redistributed to
Header-People contained "Mail from OFFICE-1 rcvd at 15-Jun-78 1117-PDT"
as the first line.  This is, of course, illegal and caused my mail reading
program to complain.  I suggest OFFICE-1 change its mail system to not
include such annotations in redistributed messages.  Also, for quite some
time some hosts have been sending headers with identical Sender: and From:
lines. For example, one recent Header-People message contained both
"From: HENDERSON at BBN-TENEXD" and "Sender: HENDERSON at BBN-TENEXD".
Since this is strongly discouraged in RFC733 for good reason I'd like to ask
that BBND correct its mailer.

These small gripes really shouldn't have been sent to Header-People but I have
no idea who to complain to at OFFICE-1 and BBND.  Perhaps I should be able to
mail to MAIL-MAINTAINERS@SOME-HOST (or some such name) to report problems
with the mailer at SOME-HOST.  The ITS systems do this (e.g. mail to
BUG-MAIL@MIT-MC).

Date: Thursday, 15 Jun 1978 1637-EDT
From: Brian Reid at CMU-10A
Subject: Re: Illegal headers
To:   HEADER-PEOPLE at MIT-MC
Message-ID: <15Jun78 163734 BR10@CMU-10A>
In-Reply-To: Earl A. Killian's message of 15 Jun 78 15:18

As long as we're flogging particular mail systems, I'd like to gripe to
the relevant party about the CRLF SPACE CRLF that separates header from
message in a lot of Unix sites' mail systems.  Will the person who
maintains these things (if any such person exists) please fix?
It should be, as we all know, CRLF CRLF.

Date: Thu, 15 Jun 78 14:36-PDT
Subject: Re: text message format question
From: Dcrocker at Rand-Unix
To: Header-People at Mit-Mc
cc: Postel at Usc-Isib, Feinler at Sri-Kl, Borden at Isd,
cc: Brotz at Parc, Horning at Parc-Maxc, Levin at Parc-Maxc,
cc: Schroeder at Parc-Maxc, Kierr at Parc, Wegbreit at Parc,
cc: Taft at Parc
Message-ID: <Dcrocker.78.165.143619 @ Rand-Unix>

Well, I think we now understand the problem and the solution:

    With respect to 733, if the semi-colon is made optional, then
formal ambiguity can result with the nesting of several group
lists.  Since the idea of the semi is to delimit the end of a
sub-list, it seems foolish to use/require the semi if the sub-
list is emtpy.

    This leads now to recommending that the spec in RFC 733, page
15, section D, <address> definition, line 3 be changed from:

/ (phrase ":" #address ";")

to be

/ (phrase ":" [1#address ";")

which means that the semi is PROHIBITED if the list is empty and
the semi is REQUIRED if the list is not empty.  No ambiguities
can result, since the first character after a colon resolves
whether the sub-list is empty -- a comma or end-of-field
indicates empty sublist and any other character says it is not
empty and that a semi is required.  Group specs nest so that a
semi matches the most recent group-name colon.

    The problem at Parc stems from their having a user community
which had a variant of MSG that used the group name as a path
indicator and automatically fetched the referenced contents.
Since that is handled very differently is 733, it is useful for
the new Parc message system to flag the behavior (in an old
message) as an error.  That is, they are relying on the old
behavior as being illegal in the new environment and we are
trying to make it no longer illegal.  Sigh.

    I suppose that the issue isn't really worth all of this text,
but it bothered me during the initial specficiation stage since
it looks silly to have "foo:;" in an address list.

Date: 15 JUN 1978 1441-PDT
Sender: DCROCKER at USC-ISI
Subject: Re: Illegal headers
From: DCROCKER at USC-ISI
To: Brian.Reid at CMU-10A
Cc: HEADER-PEOPLE at MIT-MC
Message-ID: <[USC-ISI]15-JUN-78 14:41:47.DCROCKER>
In-Reply-To: <15Jun78 163734 BR10@CMU-10A>

For one and all: there are two problems with fixing the offending
Unix message program (a pseudo MSG): No one really maintains it
and the effort needed to fix the behavior is remarkably
non-trivial.

At Rand, we keep deferring the effort in the belief that the
program will shortly be superceded.  We've been operating on the
assumption for two years...

Dave.

Date: 15 Jun 1978 1750-EDT
From: Rick Gumpertz at CMU-10A
Subject: Re: text message format question
To:   Dcrocker at Rand-Unix
CC:   Header-People at Mit-Mc
Message-ID: <15Jun78 175025 RG02@CMU-10A>
In-Reply-To: <Dcrocker.78.165.143619 @ Rand-Unix>

Is "XX: ,A,B;" legal??

What are the semantics of a group name without a group??  To whom
should a reply be sent if the message says "Reply-to: Nice-people:"
or such??

                Rick

Date: Thu, 15 Jun 78 15:03-PDT
Subject: Re: text message format question
From: Dcrocker at Rand-Unix
To: Rick Gumpertz at Cmu-10a
cc: Dcrocker at Rand-Unix, Header-People at Mit-Mc
Message-ID: <Dcrocker.78.165.150320 @ Rand-Unix>
In-Reply-To: Your message of 15 Jun <15Jun78 175025 RG02@CMU-10A>

In the proposed change, "foo: , A, B;" is NOT legal.  You have managed
to find something that woumld require changing the basic definiton
of the "#" construct so that the FIRST element of a list could
NOT be empty.  Seems like a terrible idea.

The Reply-to example would "prevent" replying, since no valid
address is shown; but that is legal now!

Any idea how we can salvage my suggestion?  

Dave.

Date: 16 JUN 1978 0051-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: HEADER-PEOPLE at MIT-AI


    Date: 14 Jun 1978 1151-EDT
    From: Rick Gumpertz at CMU-10A
    Subject: Re: Recipient names without host names

    Twice epsilon, or even 5 times it, is insignificant
    when compared with the total cycles being expended in RMAIL, or for that
    matter the MIT-ITS machines as a whole.  Arguments like that would have
    us still using only upper case, because it is faster to parse.
    When we argue execution time doubling, we really should take as a base
    not the time spent in parsing but rather the entire time spent in compiosing
    a reply!


Arguments like this are very common, so it is important to point out
why this one misses the point.  It would make sense for a batch
job, but mail systems are used by human beings!
If a user has to wait a long time for the reply command to parse his
header, it won't matter one whit to him that the CPU time used by that
operation was miniscule compared to a whole day, or compared to how
long it will take him to type his message, or compared to ANYTHING.
He won't usually mind the time it takes him to compose the message,
since he will be active then and not waiting for anything, but he will
mind a much shorter period of enforced idleness.  While Reply is parsing the
header, the user has to twiddle his thumbs, and if he has to twiddle
his thumbs too long he will decide it is unusable.  It is on the
borderline already, on our KA-10, and if it were twice as slow nobody
would ever use it.  I might as well just delete the facility as slow it
down AT ALL.


Date: 16 JUN 1978 0056-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: HEADER-PEOPLE at MIT-AI


    Date: 14 Jun 1978 1151-EDT
    From: Rick Gumpertz at CMU-10A
    Subject: Re: Recipient names without host names

    We might even add the time expended by some poor human processor
    trying to figure out why his mail didn't get through.

How about my own built-in header parser, which I use because Reply is
slow?  It has been known to be confused by recipient names without
hostnames exactly like Reply.  Since I can't patch myself with prefect
reliability, and mail senders can, the only solution is not to generate
such names.


Date: 16 Jun 1978 1028-EDT
From: Rick Gumpertz at CMU-10A
Subject: header parsing
To:   RMS at MIT-AI (Richard M. Stallman)
CC:   HEADER-PEOPLE at MIT-AI
Message-ID: <16Jun78 102840 RG02@CMU-10A>
In-Reply-To: Richard M. Stallman's message of 15 Jun 78 23:51

RMS -

If your user can notice the header parsing time, even with lots of bells
and whistles, my faith in you as a hacker of code extraordinaire will be
shattered!

                Rick


Date: 16 Jun 1978 11:37 am (Friday)
From: Karlton at PARC-MAXC
Subject: Re: address list syntax
In-reply-to: <Dcrocker.78.165.113921 @ Rand-Unix>
To: Dcrocker at Rand-Unix
cc: Header-People at Mit-Mc

It should be clear in the syntax that the trailing semi-colon is required if any
more recipients are included in the list after the last member of the group.  Your
proposed change leaves things ambiguous.  How about just saying in the
semantic section that the end of string be allowed to close all open groups.

PK


Date: 16 Jun 1978 1538-EDT
From: Rick Gumpertz at CMU-10A
Subject: Re: address list syntax
To:   Karlton at PARC-MAXC
CC:   Header-People @ MIT-MC
Message-ID: <16Jun78 153810 RG02@CMU-10A>
In-Reply-To: Karlton's message of 16 Jun 78 11:37

I guess I don't really like empty groups in the first place -- they
should contain at least a :include: (or whatever that was) so that
I can find the members if I really want them.

                Rick

Date: 23 Jun 1978 1558-PDT
Sender: FEEDBACK at OFFICE-1
Subject: Illegal headers
From: FEEDBACK at OFFICE-1
To: eak@MIT-MC
Cc: FEINLER@SRI-KL, FEEDBACK, JORDAN, LIEBERMAN, header-people@MIT-MC
Message-ID: <[OFFICE-1]23-Jun-78 15:58:07-PDT.FEEDBACK>



In reply to your message of 15-JUN-78 1618-EDT  Earl A. Killian <EAK at 
MIT-MC>
Subject:  Illegal headers


   Hi Earl,
   The header "Mail from OFFICE-1 rcvd at 15-Jun-78 1117-PDT" on 
   messages from Office-1 or redistributed messages is generated by the 
   host that is receiving the message, not by the originating host.  I 
   suggest that you contact someone at the host where you receive your 
   mail, (MIT-MC?).  Jeff Peters, our resident TENEX expert, believes 
   this may be a feature on all TENEX operating systems.
   Regards,  Pamela Allen/Feedback at Office-1



Date: 29 JUL 1978 1010-PDT
Sender: DCROCKER at USC-ISI
Subject: Transition
From: DCROCKER at USC-ISI
To: [ISI]<MsgGroup>Mailing.List;161:, 
To: Header-People at MIT-MC, list:
Message-ID: <[USC-ISI]29-JUL-78 10:10:40.DCROCKER>

I  will  be  off  the  net  from 1 Aug to about 25 Aug, and will be in
transit from Los Angeles to the University of Delaware.  Once situated
in beautiful downtown Newark (De.), I'll be working on my doctorate.

Tho Delaware is not (currently) on the network, I'll still have access
to my mailbox and will be continuing as a consultant with Rand.

Dave.

Date: 24 Aug 1978 1313-PDT
Sender: WMARTIN at OFFICE-1
Subject: Change of address
From:  WILLIAM G. MARTIN
To: MsgGroup at ISI, Header-People at MIT-MC
Cc: DRXAL-HDA
Message-ID: <[OFFICE-1]24-Aug-78 13:13:50.WMARTIN>

Please change WMARTIN at OFFICE-1 to DRXAL-HDA at OFFICE-1.


Change is eternal. Thanks, Will.

Date: 26 AUG 1978 2338-PDT
Sender: STEFFERUD at USC-ISI
Subject: Re: Change of address
From: STEFFERUD at USC-ISI
To: WMARTIN at OFFICE-1
Cc: MsgGroup, Header-People at MIT-MC, DRXAL-HDA at OFFICE-1
Message-ID: <[USC-ISI]26-AUG-78 23:38:08.STEFFERUD>
In-Reply-To: <[OFFICE-1]24-Aug-78 13:13:50.WMARTIN>

Hi Will - I will make the change with the next batch.  I assume
you will have a forwarding reflector put up at O-1.

Best - Stef

Date: 19 Sep 1978 0756-PDT
From: BH at SU-AI (Brian Harvey)
Subject: MAIL, MLFL, dots    
To:   Header-people at MIT-AI    

(Gee, I hope this mailing list still exists!  This isn't actually about
headers but it is about mail so I figured I'd start here.)  Some of you
have lately been receiving net mail about the fact that one of our users
innocently tried mailing a message which included a line containing only
a dot, and of course it didn't work.  This has started some discussion of
the relative merits of MAIL vs. MLFL.  Basically it seems that although
MLFL is in some abstract sense "the right thing" because it does away
with all need for in-band signalling, it sometimes doesn't work, and it
is alleged that some hosts sometimes even give positive acknowledgement
of MLFL and then lose the message.  MAIL on the other hand has a lot of
problems besides the one about the dot, like the fact that normal editing
functions are supposed to be allowed, so if you send a control-A or a
control-C or the like to a TENEX as part of the text all is lost.

It seems to me that it would be a lot of work for everyone to fix up MLFL
and start using it in mail programs.  That's why it hasn't been done all
these years.  So what I'd like to know is how hard it would be to create
a new protocol command called XMAI or something which would be just like
MAIL except that NVT editing functions would be disabled during it, and
possibly some rule like "a line starting dot space should have the space
ignored" to allow a line containing only a dot to be transmitted that way.
(I choose dot space rather than, say, dot dot because then if some host
doesn't actually strip off the space it won't generally look too bad.)
Would this be an easy thing for everybody to implement?  Is there a TENEX
mail wizard in the house?




Date: 19 Sep 1978 1204-EDT
From: Rick Gumpertz at CMU-10A
Subject: Re: MAIL, MLFL, dots
To:   BH at SU-AI (Brian Harvey)
CC:   Header-people at MIT-AI
Message-ID: <19Sep78 120414 RG02@CMU-10A>
In-Reply-To: Brian Harvey's message of 19 Sep 78 09:56

What the hell is so hard about everyone supporting MLFL?  That seems far
easier than adding yet another new protocol!

                Rick


Date: 19 SEP 1978 1116-PDT
Sender: GEOFF at USC-ISI
Subject: Re: MAIL, MLFL, dots    
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: BH at SU-AI
Cc: Header-people at MIT-AI
Message-ID: <[USC-ISI]19-SEP-78 11:16:25.GEOFF>
In-Reply-To: Your message of SEPTEMBER 19, 1978

I think that creating XMAI is a bad idea, and is a half solution
to the problems with MAIL and MLFL.

I do not know of any hosts that take MLFL and then lose the
message, can do document this for anyone host?

I don't think it would be all that demanding of each sites MAIL
wizard to implement MLFL in their mail sending programs, and also
MLFL in their FTPSRVr.  Actually, the last time i checked around
the net the only site I can rember that didn't support MLFL was
RAND-RCC (370/158 MVS), but even though they don't support it I
don't see why you can't have your mail sending programs sense
this and then re-try to send the message via regular MAIL.  Tis
is currently what the BBN MAILER program does, first try MLFL if
it fails, then use MAIL.

Lastly, if the MAILER program endsup using MAIL to transmit the
message, why not just have it look at the text as it passes it
thru to the foreign host for a line imbedded with just a "." on
it and then patch it onthe fly to ".<space>"?



Date: 09/19/78 1507-EDT
From: HAINES at LL
Subject: XMAIl
To: Header-people at MIT-AI

I agree with Brian and Geoff that XMAI is a bad idea.  Something
we do NOT need is yet another way to send mail.  Geoff's remarks
about using MLFL when possible and (in MAIL) appending a blank to a line
consisting of only a dot are good.

Concerning MLFL:  I fixed our FTP server to support MLFL over a year
ago in response to a case where CMU couldn't get mail throught to us.
To the best of my knowledge, it has never been used since.  In particular,
all the Header_People mail, the 'Usual Notice's, etc. use MAIL.

What was that remark about 'normal editing allowed'?  I am not aware
that the FTP server should support any editing, let alone exotic
handling of control characters.

Ted Haines
-------


Date: 19 Sep 1978 1526-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: Header-people at MIT-AI
Subject: MLFL Discussion -- Further Data
Message-id: <[MIT-DMS].86646>

     What follows is a table of results of trying MLFL on every host
listed as a Server in the ITS/SAIL host table.  The data may be some-
what out of date (this was compiled in November, 1977), both as to the
hosts surveyed and the results.  However, Header-People might find it
interesting.

     The survey was taken by trying to find a legal addressee on each
Server and doing a MLFL to him/her.  On those for whom I had no such
addressee, I just did "MLFL *******", with varying degrees of success.

     I'm not sure what the official FTP protocol says about asking for
a LOGIN on MLFL, but since my survey program didn't do it, sites that
asked for that are listed as "losers".

     Winners:  Either MLFL worked or was correctly reported as not being
implemented.

1) Transfer complete and acknowledged:  29 hosts.

   1 == UCLA-ATS  	  86 == USC-ISI
   5 == BBN-TENEXE	 101 == DEC-MARLBORO    
  10 == LL		 113 == BBN-TENEXD 
  11 == SU-AI		 116 == USC-ISIE   
  15 == I4-TENEX	 129 == UCLA-SECURITY   
  16 == AMES-67		 134 == MIT-AI  
  31 == CCA-TENEX	 150 == USC-ISIC   
  32 == PARC-MAXC	 197 == BBN-TENEXA 
  49 == BBN-TENEXB	 198 == MIT-ML
  51 == SRI-KA		 199 == RAND-UNIX  
  62 == UTEXAS		 215 == USC-ECL    
  66 == SRI-KL		 236 == MIT-MC  
  70 == MIT-DMS		 241 == BBN-TENEX  
  76 == ILL-NTS		 244 == USC-ISIB   
  78 == CMU-10A

2) Command not implemented:  4 hosts.

   7 == RAND-RCC	506 COMMAND NOT IMPLEMENTED OR NOT RECOGNIZED
  42 == LONDON		500 Command unrecognized
  48 == AFWL		501 ML<?>FL *******
  65 == UCLA-CCN	500 COMMAND UNRECOGNIZED

     Losers:

3) Hung forever at some point in dialogue:  6 hosts.

   6 == MIT-MULTICS	after icp in reply to "255 SOCK 13058"
  18 == RADC-MULTICS	after "230  Mail Server Process ready."
  21 == LLL-COMP	after "250 Mail transfer started."
  44 == MIT-DEVMULTICS	after icp in reply to "255 SOCK 4354"
  56 == SUMEX-AIM	after icp in reply to "255 SOCK 3276965378"
 211 == NBS-UNIX   	after icp in reply to "255 SOCK 2060"

4) Asked for login:  5 hosts.

   9 == HARV-10		504 USER command required before MLFL.
  19 == NBS-10		454 Login please
 110 == WHARTON		454 Login please
 111 == WPAFB-AFAL	454 Login please
 122 == BNL		530 NOT LOGGED IN.

5) Misc.:  4 hosts.

  14 == CMU-10B		454  IMP1 Connection error - refused
  46 == RUTGERS-10  	"250 MLFL started." "452  Device DATA: does not exist
"
 142 == CMU-10D		454  IMP3 Connection error - timeout
 231 == SDAC-44		"MLFL *******" "431 User name invalid"

6) ICP never succeeded:  7 hosts.

  28 == ARPA-DMS 
  45 == MOFFETT-ARC 
  55 == ANL    
  58 == NYU    
  99 == LOGICON
 143 == I4B-TENEX 
 179 == SRI-UNIX   

---

    


Date: 19 Sep 1978 1237-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: MAIL, MLFL, etc.   
To:   Header-People at MIT-MC    

I agree with Ted, Geoff, and Rick.  I don't understand why it would be that
difficult to implement MLFL, yet easy to implement XMAI.  Since mail is in
the FTP server, supposedly a host has the capability to use data channels.
I have heard accusations of some hosts losing mail with MLFL, but have
never heard of definite blame being put on any one.  I certainly seem to
be able to send mail from Tenex (which, as Geoff describes, tries MLFL then
MAIL if MLFL loses) and haven't had any problems.

Suggestion: why don't people switch their USER programs to MLFL, and record
any cases where MLFL alleges to work but doesn't (or an experimental MAIL,
which asks the liaison at that site just to send a message back saying "yes
I got your message").  If it comes through, win.  If it loses, try to make
sure it really lost and it isn't some human problem at that end.  Once all
the facts are in, perhaps something can be done to pressure the wizard at
any truly losing site to fix it; or, the mail programs could have a special
check for that site.  [That last idea sounds too horrible to contemplate,
but it's done all the time, due to quirks in different MAIL servers (*sigh*).]

Something else which could be tried:  I suggested long ago that MAIL should
be divorced from FTP (an unhappy marriage at best).  If there are still
enough network wizards in the world, maybe socket nnn could be created to
mean "MAIL protocol socket," and have duplexing similar to MAIL/MLFL at
Tenex.

One last note.  My impression from reading the FTP protocols (real and
imaginary, *sigh*) is that all editing capabilities belong in the USER
host on FTP, and the server is under no obligation whatever to provide
any.  Since FTP uses old, not new, TELNET, you shouldn't have the problems
with IAC editing commands.  Actually, the only TELNET command which should
be groked at all is old TELNET Data Mark, nicht wahr?  I know that is a
source of confusion for many new network wizards, who innocently write
code for the published FTP, and then send damning letters across the
network because they can't talk to anybody!

-- mark



Date: Tuesday, 19 Sep 1978 1705-EDT
From: Brian Reid at CMU-10A
Subject: Re: XMAIl
To:   Header-people at MIT-AI
CC:   HAINES at LL
Message-ID: <19Sep78 170512 BR10@CMU-10A>
In-Reply-To: HAINES's message of 19 Sep 78 14:07

CMU maintains a table of the net sites that do and don't support
MLFL.  We try to use MLFL to those sites that supposedly support it.
LL is in our list of sites that don't.  I'll change it.

There are about 35 sites that don't support MLFL.  I include in this
list a lot of sites that claim to support MLFL, because they won't
allow MLFL without a USER, PASS, and ACCT.  Bogus.

Greep's mailer (Rand-Unix) is the right approach, as far as I am
concerned--he tries MLFL, and if that doesn't work, he resorts to
MAIL.

It would be much more worthwhile if people would agree on a common
set of reply codes for MAIL and MLFL, including the "no such user"
message.  After that's done, then we can think about exotica like
lines with bare periods in them.

Brian


Date: 19 SEP 1978 1423-PDT
Sender: GEOFF at USC-ISI
Subject: Re: XMAIl
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: HAINES at LL
Cc: Header-people at MIT-AI
Message-ID: <[USC-ISI]19-SEP-78 14:23:24.GEOFF>
In-Reply-To: Your message of SEPTEMBER 19, 1978

Re -- your remark about "normal editing allowed".  -- For
sometime there have been two versions of the TENEX FTP Server
program.  Both authored by Bob Clements@BBN (who apparently isn't
in on Header-people!), the frist version known as FTPSRV runs as
one user job on TENEX logged in as SYSTEM or as a fork of SYSJOB.
For each incoming FTP request, FTPSRV forks up an FTP Server
process under itself to handle MAIL, FILES, etc.  The flaw in
this version was that all of the file system refereces made by
uses had to be faked in FTPSRV since the user was really logging
into a WHEEL (privilged) account which has access to everything,
FTPSRV has to play like the file system and see if you were
really able to do what you wanted to.  About every 6 months or
so, someone would find a new way to fake FTPSRV in believing that
you rally had access to a file you weren't supposed to.  About
this time, 1.34 TENEX was up, and thus CRJOB, a way for one
program to create a job with another user actualy logged in, so
Clements ditched FTPSRV and wrote FTSCTL & FTPSER.  What happens
now, is that instead of all FTP Service functions being carried
out by a single system job as sub forks there-of, FTSCTL spawns a
not-logged-in FTPSER job (on an NVT) for each new user.  When the
user LOGGES in, FTPSER does a LOGIN just like when you login on a
terminal, in fact, FTPSER runs on a terminal, hence I guess Bob
Clements decided to add the regular TENEX editing and interupt
characters to FTPSER (which I personally think was a mistake).

One last thing to note is tht shoving characters down a TELNET
connection to an FTPSER job on a TENEX is quite expensive in
terms of overhead and processing, that is why I am very glad to
see this discussion going on in hopes that MLFL will triumph and
makes things easyer and more efficient in more ways than one.

Perhaps someone will invite Bob Clements to join header-people
and forward him all that has transpired since BH's message that
started this round of discussions.


Date: 19 SEP 1978 1445-PDT
Sender: GEOFF at USC-ISI
Subject: Re: XMAIl
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: Brian.Reid at CMUA
Cc: Header-people at MIT-AI, HAINES at LL
Message-ID: <[USC-ISI]19-SEP-78 14:45:02.GEOFF>
In-Reply-To: <19Sep78 170512 BR10@CMU-10A>

I cannot understand why your MAILER needs a table of who does and
doesn't support MLFL, I would think it would be much easyer to do
what Greep's UNIX MAILER and BBN's TENEX MAILER do by trying MLFL
first then MAIL if MLFL loses.  Hence, why the list approach?

I agree too that is is absolutely bogus of anyone who supports
MAIL not logged in cannot support MLFL not-logged in.

While we are on the subject of USER, PASS, ACCT , lists, and
not-logged-in, it is equaly as cretinous for all our mail sending
programs to have a special exception list (and crock/kludge code
to go along with it) to support this nonsense wrt MULTICS hosts
and the MLFL USER & PASS hack.  Yuk!



Date: Tue, 19 Sep 78 14:49-PDT
Subject: Re: XMAIl
From: Greep at Rand-Unix
To: Brian Reid at Cmu-10a
cc: Header-people at Mit-Ai, HAINES at Ll
Message-ID: <Greep.78.261.144922 @ Rand-Unix>
In-Reply-To: Your message of Tuesday, 19 Sep 1978 1705-EDT
In-Reply-To: <19Sep78 170512 BR10@CMU-10A>

I should mention that the version of the mailer you mentioned, the
one that tries MLFL first, is not actually installed yet, partly because
of my recent relocation from Rand to Stanford.  Another reason is that,
embarassingly enough, MLFL did not always work to our own host!  This
was caused by an NCP bug which I fixed but which may still be present on
other Unix systems.


Date: 19 SEP 1978 1751-EDT
From: Earl A. Killian <EAK at MIT-MC>
To: HEADER-PEOPLE at MIT-MC

Perhaps we should all go de-implement the MAIL command in our FTP servers;
making MLFL the only way to send mail.

From: Mike at Rand-Unix
Date: 19 Sep 1978 at 1600-PDT
To: Geoff at SRI-KA (Geoffrey S. Goodfellow)
cc: Header-people at MIT-AI, HAINES at LL,
    Brian.Reid at CMUA
Subject: Re: XMAIl
In-reply-to: Your message of 19 SEP 1978 1445-PDT
             <[USC-ISI]19-SEP-78 14:45:02.GEOFF>

Folks,

Rand-Rcc has supported MLFL command for a few months now to the
best of my knowledge.  So please take us off your lusers lists
in your various ftp's.


Date: 19 Sep 1978 1752-PDT
From: BH at SU-AI (Brian Harvey)
Subject: boy I really started something
To:   Header-people at MIT-MC    

I agree with everyone who has said that my XMAI idea is a crock.  I knew
all along it was a crock, but I suggested it because people have known for
years now that MLFL was the right thing and nobody does it.  I figured
there were two possible reasons for that: (1) MLFL is harder since it
involves an extra net connection and negotiations about sockets and such,
and (2) it was alleged to me that it often didn't work, even sometimes
when it was supposed to.  I have no relevant first-hand information on
that score.

As to telnet editing, I am at home right now and don't have all the
documents with me, but I have a distinct recollection of having read that
the MAIL command in FTP was intended to be usable from someone at a TIP
without having to log in first at some other host, so that the server was
supposed to provide editing capability as for a telnet connection.  I am
forcefully reminded of this problem every time I RETR a file from an ITS
system and try to mail it to a TENEX, because control-C is the ITS end of
file character and sometimes shows up at the ends of the files they send,
and TENEX aborts the entire operation when it sees one!  (At least the
tenices I talk to do that.)

Since people seem to think that MLFL is more widely supported than I
thought, I'll try it in our mailer; I just wanted to suggest something
that everybody could get on the air quickly if MLFL wasn't going to
solve the problem without a lot of work.



Date: 19 SEP 1978 1926-PDT
Sender: DCROCKER at USC-ISI
Subject: Addition to distribution lists
From: DCROCKER at USC-ISI
To: Header-People at MIT-MC, MsgGroup
Cc: Szurko at RAND-UNIX
Message-ID: <[USC-ISI]19-SEP-78 19:26:37.DCROCKER>

Please add Szurko at Rand-Unix to the lists.  Ed Szurko is the U
of Delaware Electrical Engineering Department's Unix system
honcho, and is just getting involved in network mail
distribution.

Thanks.  Dave.

Date: 19 SEP 1978 2247-EDT
From: Earl A. Killian <EAK at MIT-MC>
To: HEADER-PEOPLE at MIT-MC

By the way, I asked a Multics person to look into fixing the login before
mail lossage and he thinks it just might get done this time (Honeywell has
gotten complaints from RADC about some mail not getting through so...).

Date: 20 SEP 1978 1006-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: RCC, MLFL/MAIL, etc.
To: geoff at SRI-KA, header-people at MIT-MC
CC: Clements at BBN-TENEXA

	If my memory serves me correctly, I did ask Bob Clements
if he'd like to join the header-people group, but he decided
against it owing to enormous time pressures working with DEC on
20X development.  Perhaps things now are more relaxed; he's
certainly welcome.  By the way, technically this mailing
list is for fighting about header formats and I'm not sure how
many people are really interested in working on straightening
out things like FTP reply codes, which certainly need it.  For
the time being it doesn't matter; if several people announce
that they are annoyed with "junk" mail re FTP, or that the size of
the list intimidates them from talking about it, then we can just set
up a "FTP-PEOPLE" group.

	It would be interesting if PDL could fire up another
survey to get a snapshot of the MLFL picture nowadays.  Anyway,
as far as efficiency goes, MAIL is much better than MLFL for
the ITS servers, as it avoids the overhead and real-time lag of
negotiating and opening the data connection, which can be a drag
with many small messages.  The difference in transmission
speed once things are set up is negligible, and chars are passed
directly with no funny editing etc (I always considered the
TNX PTY'ing kludge a big loss), and only about 2 people
a year notice anything funny owing to the substitution of
"crlf,crlf" for "crlf.crlf".

	If one really wanted to be efficient (and not just
try to pass over a pristine stream of bytes) using XRSQ/XRCP
(RFC 743) would save an amazing amount of time.


From:  Pogran at MIT-Multics
Date:  09/20/78 1039-edt
Subject:  MAIL & MLFL, etc.
To:  Header-People at MIT-AI
Message-ID:  [MIT-Multics]1.1.BBBJHjgGkHwxgl

[I feel like I'm commenting as an "outsider" now, since I haven't had
a thing to do with Multics software for nearly a year, but here goes ...]

The Multics mailer has never maintained an exception list, and as
far as I know, is capable of mailing to every ARPANET host that supports
MLFL and/or MAIL in some way.  It's more or less a
"try this; if the response is unsatisfactory, try that" type of algorithm,
where "this" and "that" are most commonly MLFL and MAIL, but with
subsidiary decision points for trying USER and PASS, backing out of a
MLFL when the server asks for a login after the SOCK reply, etc.
If anybody really needs it, I'll try to write up the algorithm.

And a comment on Honeywell eliminating Multics' need for USER/PASS:
Once upon a time there was NO WAY to do mail-receiving on Multics without
it; a year or so ago it was made possible in principle.  If Honeywell,
the maintainers of Multics ARPANET software these days, can put the manpower
into it, it can be made to happen in fact.  Let's hope they decide to do it!

Ken


From: Kiessig at Rand-Unix
Date: 20 Sep 1978 at 1121-PDT
Message-Id: <[Rand-Unix]20-Sep-78 11:21:58.kiessig>
To: KLH at MIT-AI
Cc: Header-People at MIT-MC
Subject: Re: RCC, MLFL/MAIL, etc.
In-reply-to: Your message of 20 SEP 1978 1006-EDT.

I for one think that an FTP-PEOPLE mailing list would be  a  good
idea.   Seems  there's  enough  problems with FTP to make another
list worth while.

Date: 21 Sep 1978 1824-EDT
From: PDL at MIT-DMS (P. David Lebling)
To: Header-people at MIT-AI
Subject: New MLFL Survey (A Long Message)
Message-id: <[MIT-DMS].86941>

    Here are the results of the MLFL Survey I ran September 20 and 21.
As before, sites listed as SERVERs by the ITS host table were surveyed.
Where I had the name of a real mailbox at a site (a Header-person, for
example) I used that, otherwise the name "**".  Once I got a "response"
that seemed final I stopped surveying that site.  If a site asked for
a password after the MLFL command I gave "USER NETML" "PASS NETML" and
retried the MLFL.  Sites are grouped by the general result I got.

    Complete FTP scripts may be found, if you are interested, on
MIT-DMS, file PDL;MLFL >.

-site-		-last ftp reply if lost-		-when-

1) Sites that lost for various reasons:

BNL		530 NOT LOGGED IN.			after MLFL
CMU-10A		454  IMP4 Connection error - timeout	after SOCK
CMU-10B		454  IMP2 Connection error - timeout	after SOCK
CMU-10D		454  IMP3 Connection error - timeout	after SOCK
HARV-10		431 INVALID ENTRY - Try again		after USER
LLL-MFE		454 Login please			after SOCK
LONDON		000 INDRA FTP Version 2.00  ...		after ICP
LONDON-VDH	000 INDRA FTP Version 2.00  ...		after ICP
NBS-10		454 Login please			after SOCK
WHARTON		454  DATA Connection error ...		after SOCK
WPAFB-AFAL	454 Login please			after SOCK

Note: "when" describes the last action performed by the surveyer before
the indicated anomalous response.

	after ICP --	surveyer had done ICP to socket 3
	after MLFL --	surveyer had sent MLFL command
	after USER --	surveyer had sent USER NETML in response to
			"504 Login please"
	after SOCK --	surveyer had attempted to connect to specified
			data socket

2) Sites that don't support MLFL and say so:

AFWL		501 ML<?>FL **
EGLIN		501 ML<?>FL **
LBL		506 Command not implemented.
UCLA-CCN	500 COMMAND UNRECOGNIZED
WPAFB		501 ML<?>FL **

3) Sites that support MLFL (or at least go through all the right
   motions):

AMES-67		LL-ASG		SRI-KA
BBN-TENEX	MIT-AI		SRI-KL
BBN-TENEXA	MIT-DMS		SU-AI
BBN-TENEXB	MIT-MC		SUMEX-AIM
BBN-TENEXD	MIT-ML		UCLA-ATS
BBN-TENEXE	NBS-UNIX	UCLA-SECURITY
BBN-UNIX	PARC-MAXC	USC-ECL
CCA-TENEX	PARC-MAXC2	USC-ISI
DEC-MARLBORO	RADC-TOPS20	USC-ISIB
I4-TENEX	RAND-RCC	USC-ISIC
ILL-UNIX	RAND-UNIX	USC-ISIE
LL		RUTGERS		UTEXAS

4) Sites that support MLFL but require "USER NETML" "PASS NETML"
   (Multics):

MIT-DEVMULTICS
MIT-MULTICS
RADC-MULTICS

5) Others:

   a) Sites that might support it if I could mail to a real user (some
      of these run operating systems that are "known to work", e.g.
      TENEX):

DCEC		450 User Unknown
DTI		451 User Not Recognized
LL-11		450 User Unknown
LL-XN		450 User Unknown
NOSC-SDL	451 User Not Recognized
NTIA-ITS	451 User Not Recognized
OFFICE-1	450 No such mailbox at this site
RADC-XPER	451 User Not Recognized
SDAC-44		431 User name invalid
SDAC-UNIX	451 User Not Recognized
SRI-UNIX	451 User Not Recognized

   b) Sites that either never responded to an ICP to socket 3, or were
      not accepting FTP users:

ANL		I4B-TENEX	NOSC-CC
ARPA-DMS	ISI-SPEECH11	NOSC-SECURE1
CCA-SDMS	LBL-UNIX	NRL
CCTC		LLL-COMP	NSWC-WO
CMU-CMMP	LOGICON		NUSC
CTO-DDS		MOFFETT-ARC	NWC
DTNSRDC		NADC		NYU
FNWC		NCSC		OFFICE-2
GUNTER-UNIX	NDRE		PENT-UNIX

---

    


Date: Thursday, 21 Sep 1978 1933-EDT
From: Brian Reid at CMU-10A
Subject: MLFL to CMU
To:   PDL at MIT-DMS (P. David Lebling)
CC:   Header-people at MIT-AI
Message-ID: <21Sep78 193316 BR10@CMU-10A>
In-Reply-To: <[MIT-DMS].86941>

CMU supports MLFL.  Since all 3 of our hosts gave the same error,
you must have caught us at a time when the IMP was flaky.  


Date: 21 Sep 1978 2009-EDT
From: Rick Gumpertz at CMU-10A
Subject: Re: MLFL to CMU
To:   Brian Reid at CMU-10A, PDL at MIT-DMS (P. David Lebling)
CC:   Header-people at MIT-AI
Message-ID: <21Sep78 200955 RG02@CMU-10A>
In-Reply-To: <21Sep78 193316 BR10@CMU-10A>

It looks to me like the connection protocols are somehow getting out of step
since we seem usually to show as connection timeout.  Perhaps we should
look into this further -- MLFL certainly works for us from CMU to CMU!

                Rick


ELLEN@MIT-MC 09/23/78 09:06:59 Re: Mis-directed message
To: header-people at MIT-AI
Begin forwarded message:
________________________________________________________________
From:  Pogran at MIT-Multics
Date:  09/19/78 1531-edt
Subject:  MAIL and MLFL discussion
To:  Header_People at MIT-MC
Message-ID:  [MIT-Multics]1.1.BBBJHjdGdMJqfc

Folks:

I agree 100% with Geoff's comments.  The Multics mailer also
uses the "first MLFL, then MAIL" rule (which means, Ted Haines,
that mail sent directly from Multics to LL should use MLFL if you
support it.  Perhaps we can arrange a test?).  In particular,
I'd prefer to see, as Geoff suggests, the mailer that uses MAIL to scan
for the newline-dot-newline sequence, rather than put the onus on
FTP servers, in any way.

Whether or not editing is allowed on the FTP TELNET control connection,
used for sending MAIL, is, as far as I can tell, an open question.
MAIL was originally intended SOLELY to permit "naked" TIP users to]
open an FTP connection to a host and type mail (ah, the good old days!),
so, mindful of this, some implementors allowed editing characters
to have their normal effect over the FTP control connection.
Multics tried this -- and then changed, when we discovered that mail
tended to contain at-signs -- the Multics line-kill character!
So an arriving messge which said:

     ... I'm not sure how you will feel about this, so please
     reply to me immediately.  My mailbox is FOOBAR@ISI.

     George

would come out:

     ... I'm not sure how you will feel about this, so please
     ISI.

     George

Similar experiences elsewhere prompted implementors to drop the
use of editing characters.

The Multics net-mailing program (which either sends immediately or queues
for the mailer) scans the text for newline-dot-newline and warns the
user that there may be a problem.

I think the consensus of the group is that Brian should bite
the bullet and implement MLFL!

Ken



Date: 11 Oct 1978 0636-PDT
From: Klh at SRI-KL (Ken Harrenstien)
Subject: "Deafnet" project!
To:   header-people at MC

[Some of you will be receiving this message twice -- my apologies...]

Greetings--

Pardon me for such a late and broadcast-style announcement, but really
there are too many of you!  In lieu of a reasonably personalized
message, pray accept this short pointer; those curious souls wishing
more information have but to ask.

In brief, we at SRI International have just been awarded a contract
from DHEW/OE/BEH for "Research in Telecommunications for the Deaf".
The project will last 15 months, and has two primary tasks.  The first
is to provide a "service delivery demonstration" of a computer message
system for the deaf community; the second is to conduct a survey and
engineering study aimed at the design of a nationwide communications
system for the deaf.

Being deaf, and having a great store of experience in developing and
using mail systems, I find this project peculiarly fulfilling and
exciting.  While keeping fingers in all the various pie-slices of the
project, I'll be primarily responsible for Task 1, in which a DEC
PDP-11/70 running UNIX will be installed at Gallaudet College and
thereby will serve the Washington, D.C. deaf community.  Managing
things so that software gets modified, features added, users
trained, public relations handled, etc. will be more than
challenging... if my mail goes slightly unanswered over the next
few months, at least you'll know why.

There are many people who actually made this happen, and I can't possibly
list them all even if I knew for sure who did what, but the following
deserve special mention:
   Mario Grignetti, Dick Rubinstein, and others at BBN,
       for making many first steps;
   Chuck Jackson, Jeff Krauss, and Vint Cerf,
       for pushing and authoring the RFP;
   Plus unnamed and unknown entities within HEW/BEH, innumerable people
       at MIT, and SRI's Telecommunications Sciences group...
In 15 months doubtless this list will be greatly expanded.

Those wishing slightly more detail should read [SRI-KL]
<KLH>DN-INTRO.DOC which is the excerpted introduction to our original
proposal (ITS types can read AI:KLH;PROP INTRO); the only change is
that the proposal mentions a 11/60 which later was finalized to a
11/70.  This introduction is 10 pages long; anyone who wants to tackle
the entire proposal at 100 to 150 pages should contact me.

--Ken
-------

Date: 11 Oct 1978 0636-PDT
From: Klh at SRI-KL (Ken Harrenstien)
Subject: "Deafnet" project!
To:   header-people at MC

[Some of you will be receiving this message twice -- my apologies...]

Greetings--

Pardon me for such a late and broadcast-style announcement, but really
there are too many of you!  In lieu of a reasonably personalized
message, pray accept this short pointer; those curious souls wishing
more information have but to ask.

In brief, we at SRI International have just been awarded a contract
from DHEW/OE/BEH for "Research in Telecommunications for the Deaf".
The project will last 15 months, and has two primary tasks.  The first
is to provide a "service delivery demonstration" of a computer message
system for the deaf community; the second is to conduct a survey and
engineering study aimed at the design of a nationwide communications
system for the deaf.

Being deaf, and having a great store of experience in developing and
using mail systems, I find this project peculiarly fulfilling and
exciting.  While keeping fingers in all the various pie-slices of the
project, I'll be primarily responsible for Task 1, in which a DEC
PDP-11/70 running UNIX will be installed at Gallaudet College and
thereby will serve the Washington, D.C. deaf community.  Managing
things so that software gets modified, features added, users
trained, public relations handled, etc. will be more than
challenging... if my mail goes slightly unanswered over the next
few months, at least you'll know why.

There are many people who actually made this happen, and I can't possibly
list them all even if I knew for sure who did what, but the following
deserve special mention:
   Mario Grignetti, Dick Rubinstein, and others at BBN,
       for making many first steps;
   Chuck Jackson, Jeff Krauss, and Vint Cerf,
       for pushing and authoring the RFP;
   Plus unnamed and unknown entities within HEW/BEH, innumerable people
       at MIT, and SRI's Telecommunications Sciences group...
In 15 months doubtless this list will be greatly expanded.

Those wishing slightly more detail should read [SRI-KL]
<KLH>DN-INTRO.DOC which is the excerpted introduction to our original
proposal (ITS types can read AI:KLH;PROP INTRO); the only change is
that the proposal mentions a 11/60 which later was finalized to a
11/70.  This introduction is 10 pages long; anyone who wants to tackle
the entire proposal at 100 to 150 pages should contact me.

--Ken
-------

Date: 11 Oct 1978 0636-PDT
From: Klh at SRI-KL (Ken Harrenstien)
Subject: "Deafnet" project!
To:   header-people at MC

[Some of you will be receiving this message twice -- my apologies...]

Greetings--

Pardon me for such a late and broadcast-style announcement, but really
there are too many of you!  In lieu of a reasonably personalized
message, pray accept this short pointer; those curious souls wishing
more information have but to ask.

In brief, we at SRI International have just been awarded a contract
from DHEW/OE/BEH for "Research in Telecommunications for the Deaf".
The project will last 15 months, and has two primary tasks.  The first
is to provide a "service delivery demonstration" of a computer message
system for the deaf community; the second is to conduct a survey and
engineering study aimed at the design of a nationwide communications
system for the deaf.

Being deaf, and having a great store of experience in developing and
using mail systems, I find this project peculiarly fulfilling and
exciting.  While keeping fingers in all the various pie-slices of the
project, I'll be primarily responsible for Task 1, in which a DEC
PDP-11/70 running UNIX will be installed at Gallaudet College and
thereby will serve the Washington, D.C. deaf community.  Managing
things so that software gets modified, features added, users
trained, public relations handled, etc. will be more than
challenging... if my mail goes slightly unanswered over the next
few months, at least you'll know why.

There are many people who actually made this happen, and I can't possibly
list them all even if I knew for sure who did what, but the following
deserve special mention:
   Mario Grignetti, Dick Rubinstein, and others at BBN,
       for making many first steps;
   Chuck Jackson, Jeff Krauss, and Vint Cerf,
       for pushing and authoring the RFP;
   Plus unnamed and unknown entities within HEW/BEH, innumerable people
       at MIT, and SRI's Telecommunications Sciences group...
In 15 months doubtless this list will be greatly expanded.

Those wishing slightly more detail should read [SRI-KL]
<KLH>DN-INTRO.DOC which is the excerpted introduction to our original
proposal (ITS types can read AI:KLH;PROP INTRO); the only change is
that the proposal mentions a 11/60 which later was finalized to a
11/70.  This introduction is 10 pages long; anyone who wants to tackle
the entire proposal at 100 to 150 pages should contact me.

--Ken
-------

Date: 11 Oct 1978 0636-PDT
From: Klh at SRI-KL (Ken Harrenstien)
Subject: "Deafnet" project!
To:   header-people at MC

[Some of you will be receiving this message twice -- my apologies...]

Greetings--

Pardon me for such a late and broadcast-style announcement, but really
there are too many of you!  In lieu of a reasonably personalized
message, pray accept this short pointer; those curious souls wishing
more information have but to ask.

In brief, we at SRI International have just been awarded a contract
from DHEW/OE/BEH for "Research in Telecommunications for the Deaf".
The project will last 15 months, and has two primary tasks.  The first
is to provide a "service delivery demonstration" of a computer message
system for the deaf community; the second is to conduct a survey and
engineering study aimed at the design of a nationwide communications
system for the deaf.

Being deaf, and having a great store of experience in developing and
using mail systems, I find this project peculiarly fulfilling and
exciting.  While keeping fingers in all the various pie-slices of the
project, I'll be primarily responsible for Task 1, in which a DEC
PDP-11/70 running UNIX will be installed at Gallaudet College and
thereby will serve the Washington, D.C. deaf community.  Managing
things so that software gets modified, features added, users
trained, public relations handled, etc. will be more than
challenging... if my mail goes slightly unanswered over the next
few months, at least you'll know why.

There are many people who actually made this happen, and I can't possibly
list them all even if I knew for sure who did what, but the following
deserve special mention:
   Mario Grignetti, Dick Rubinstein, and others at BBN,
       for making many first steps;
   Chuck Jackson, Jeff Krauss, and Vint Cerf,
       for pushing and authoring the RFP;
   Plus unnamed and unknown entities within HEW/BEH, innumerable people
       at MIT, and SRI's Telecommunications Sciences group...
In 15 months doubtless this list will be greatly expanded.

Those wishing slightly more detail should read [SRI-KL]
<KLH>DN-INTRO.DOC which is the excerpted introduction to our original
proposal (ITS types can read AI:KLH;PROP INTRO); the only change is
that the proposal mentions a 11/60 which later was finalized to a
11/70.  This introduction is 10 pages long; anyone who wants to tackle
the entire proposal at 100 to 150 pages should contact me.

--Ken
-------

Date: 11 Oct 1978 1004-PDT
From: Klh at SRI-KL (Ken Harrenstien)
Subject: Message Multiplicity
To:   Header-people at MC

To forestall N people telling me they received N*4 copies of that
message, let me point out that MIT-MC crashed several times while
in the middle of handling the distribution request, and the mailer's
failsafe policy obligates it to start over again... sigh.
-------

Date: 30 NOV 1978 1522-PST
Sender: DCROCKER at USC-ISI
Subject: Address change
From: DCROCKER at USC-ISI
To: header-people at MIT-MC, 
To: [ISI]<MsgGroup>Mailing.List;170:
Message-ID: <[USC-ISI]30-NOV-78 15:22:15.DCROCKER>

Effective immediately, my official arpanet address is

DCrocker at Rand-Unix

Dave.

Date: 7 Dec 1978 1423-PST
From: Mark Crispin <MRC at SU-AI>
Subject: RFC 733 & MSG    
To:   MsgGroup at USC-ISI, Header-People at MIT-MC   

Hey, guys, guess what's happened down in the San Francisco Bay?  Yah,
you got it, we here at SAIL send RFC 733 style headers to the world.
And just guess what happens?  We blow the minds of almost every mail
reading program in the world!  The usual one is the Tenex MSG program.

About one a week I get a complaint from some poor Tenex person that
my mail headers zap MSG (and what's worse, I'm not the MAIL program
maintainer here!).  I understand (not that I should spread evil
rumors) that the author and/or maintainer of MSG is ... who is one
of the authors of 733 (name deleted to protect the guilty).

Hey, pardners, why don't we get our act together?  Is MSG going to
be fixed?  Will there be a widely available substitute for it (HERMES
is NOT since BBN jealously guards it from other sites)?  Or should
SAIL roll back to pre-RFC 733?

-- Mark

P.S.  Am I wedged, or do I remember the purpose of 733 being to
make it easier for everybody's reader to parse everybody's headers?



Date: 07 DEC 1978 1857-EST
From: JZS at CCA
Subject: Re: RFC 733 & MSG    
To:   MRC at SU-AI, MsgGroup at USC-ISI, Header-People at MIT-MC

In response to the message sent 7 Dec 1978 1423-PST from Mark Crispin <MRC@SU-AI>

And here in Cambridge, we've been archiving the world's Arpanet mail
on the Datacomputer -- with a parser specially trained to scan RFC #733
style headers.  (Rather naive, eh?)

After much grief scanning past the several flavors of old Unix-style
messages [from LL-ASG (since reformed), UTEXAS, Rand-Unix, etc. -- and
more recently from CCTC(!)], and the internal ITS-style messages which
keep leaking out all over the net, we finally gave in and are now
parsing the darn things.

How about a consciousness raising effort?

Let's rally 'round The Standard (and fix MSG, too)!

--Joanne
-------

Date: 7 DEC 1978 1632-PST
Sender: DCROCKER at USC-ISI
Subject: Re: RFC 733 & MSG    
From: DCROCKER at USC-ISI
To: JZS at CCA
Cc: header-people at MIT-MC, msggroup
Message-ID: <[USC-ISI] 7-DEC-78 16:32:25.DCROCKER>
In-Reply-To: Your message of DECEMBER 7, 1978

The issue is not one of consciousness-raising, per se, but of
convincing the people with money that they should pay for the
system modifications.

good luck.

Dave.

Date: 7 DEC 1978 1724-PST
Sender: GEOFF at USC-ISI
Subject: Re: RFC 733 & MSG    
From: the tty of Geoffrey S. Goodfellow <Geoff@SRI-KA>
To: MRC at SU-AI
Cc: MsgGroup, Header-People at MIT-MC
Message-ID: <[USC-ISI] 7-DEC-78 17:24:44.GEOFF>
In-Reply-To: Your message of DECEMBER 7, 1978

as far as i am aware MSG and MM (TOPS-20 Mail Munger by MMcM) and
HG can't handle the new style headers, in fact, as far as i am
aware, HERMES is the ONLY(!)  program available on TENEX or
TOPS-20 which can parse the RFC733 style headers.


maybe if someone approached the author of MSG and offered to make
MSG win with 733 he might release the sources, but last i heard
the author had no time to work on it (or funding i imagine)...

Date:  7 DEC 1978 1716-PST
From: POSTEL at USC-ISIB
Subject: re: standards
To:   DCrocker at ISIA
cc:   Header-People at MIT-MC, msggroup at ISIA


Dave:

who was it paid you to produce the standard?

--jon.
-------

Date: 7 DEC 1978 1732-PST
Sender: FARBER at USC-ISI
Subject: Re: RFC 733 & MSG    
From: FARBER at USC-ISI
To: JZS at CCA
Cc: MRC at SU-AI, MsgGroup, Header-People at MIT-MC
Message-ID: <[USC-ISI] 7-DEC-78 17:32:42.FARBER>
In-Reply-To: Your message of DECEMBER 7, 1978

Unfortunately  the task of standard setting is ALWAYS easier than
that  of  really  adopting  the  standard  by  changing  existing
software  to conform to it.  In the case of programming languages
the ONLY pressure that worked was that from major buyers  (  like
the  Feds  etc)  to  conform  to  the  standard or not to get the
business.

Unfortunately our message systems are used to much  to  take  the
tack  that  "well if you don't conform you cannot play the game".
That suggests that the only reasonable path is for major users  (
with $'s) force conformity by pressure on those they buy computer
time from.

If some of them said conform or we will see if there  is  another
supplier that will then it MAY work.

BUT  giving up and saying hell it will not happen guarantees that
that will be the case.

Dave


Date:  7 DEC 1978 1808-PST
From: POSTEL at USC-ISIB
Subject: re: standards & rfc 733
To:   Geoff at SRI-KA
cc:   header-people at MIT-MC, msggroup at ISIA


i am sure that the sources of msg can be provided to anyone who will take on
the responsibility of modifying MSG to rfc 733 standards, and maintaining it
thereafter.

--jon.
-------

Date: Thursday,  7 Dec 1978 2119-EST
From: Brian Reid at CMU-10A
Subject: Re: RFC 733 & MSG
To:   MsgGroup at USC-ISI, Header-People at MIT-MC
Reply-To: MsgGroup at USC-ISI, Header-People at MIT-MC
Message-ID: <07Dec78 211929 BR10@CMU-10A>
In-Reply-To: Mark Crispin's message of 7 Dec 78 17:23

As I recall, one of the forces that motivated RFC733 in the first place was
the rather disagreeable @i[de facto] standard of Tenex mail format.  We
minority sites were told "Be compatible with Tenex or you are wrong".  The
Tenex conventions were the product of convenience and not good design, and
RFC733 was intended to be a legislated standard that would solve many of
the known problems of the Tenex conventions-become-standards, with room to
grow.

We are now in a very amusing situation.  The network has 3 to 5 TOPS-10
sites (depending on how you count), 1 360-67 (rah!), some ITS, some
Multics, some Unixes, some IBM stuf, and some random and mysterious
military machines who don't seem to get in on these header frays.  And it
has many Tenices/Twenices.  20?  30?  Who knows.  The interesting point is
that essentially all of the minority sites -- the Tops-10 and the Waits and
the Its and the Unix and the TSS people -- have implemented RFC733.  The
sluggards, the Tenex sites, have not.

This is all quite strange in the light of the economics of software.  The
replication cost of software is zero.  One person, somewhere in some Tenex
site, has only to produce a good mail program, and everybody can use it.
But nobody has, and I don't think anybody will soon.  I have a lot of ideas
about why this is happening, as the craft of the devoted hacker slowly
dies.  But as far as I'm concerned, the best way to deal with this problem
is to ignore it.  Let those of us who can use our ANSWER commands just
smile, and continue to send out standard-format mail smug in the knowledge
that it's going to barf up Tenex mail readers, until sooner or later
somebody isn't going to be able to stand it any longer, and something will
get done about it.

Brian

Date: 07 DEC 1978 2253-EST
From: JZS at CCA
Subject: re: standards & rfc 733
To:   Postel at USC-ISIB
cc:   MsgGroup at ISIA, Header-People at MIT-MC

In response to the message sent  7 DEC 1978 1808-PST from POSTEL@USC-ISIB

Alas for the lack of a SAILer...

I think it would remove one of the impediments to updating MSG if the
source were available for FTPing by anyone willing to look at it.
Offering a SAIL compiler along with MSG might help too.

--Joanne
-------

Date:  7 DEC 1978 2248-PST
From: POSTEL at USC-ISIB
Subject: re: standards & RFC 733
To:   Brian.Reid at CMU-10A
cc:   Header-People at MIT-MC, msggroup at ISIA


Brian is right on.  The thing to do is send things out in the standard
format and when someone complains about not being able to parse it or
answer it, tell him/her its his/her problem for using a dumb old 
NONSTANDARD program.  

--jon.
-------

Date:  8 Dec 1978 1028-EST
From: VITTAL at BBN-TENEXD
Subject: MSG & RFC 733
To:   MsgGroup at ISI, Header-People at MC

Folks:

I agree with Jon and Brian.

My plans have been to fix MSG up for the last few months.  I hopefully
will have time toward the end of this month to make it understand the
new standard and fix some other problems that have been bugging people
for a long time.

John
-------

Date:    8 Dec 1978 1148-EST
From:    RICK.GUMPERTZ(N810RG02) at CMU-10A 
Subject: RFC 733
To:      Header-People at MIT-MC

Let RFC 733 not go the way of "NEW FTP", i.e. ignored and almost forgotten.

		Rick

Date: 8 DEC 1978 1340-EST
From: EAK at MIT-MC (Earl A. Killian)
Subject:  Re: RFC 733 & MSG    
To: Geoff at SRI-KA
CC: HEADER-PEOPLE at MIT-MC

Since when can Hermes handle RFC733??  I've used Hermes quite a bit on BBN
systems and never found in the slightest bit able to cope with RFC733
headers.

Date: 8 Dec 1978 1117-PST
Sender: MCLURE at SRI-KL
Subject: Re:  Re: RFC 733 & MSG    
From:  Stuart McLure Cracraft <McLure at SRI-KL>
To: EAK at MIT-MC
Cc: Geoff at USC-ISI, HEADER-PEOPLE at MIT-MC
Message-ID: <[SRI-KL] 8-Dec-78 11:17:49.MCLURE>
In-Reply-To: Your message of 8 DEC 1978 1340-EST

As another Hermes user, I can vouch that it can handle 733.  The
only things that it can't handle are all those (BUG MUMBLE)
messages from Its.

Date: 8 DEC 1978 1447-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Re: RFC 733 & MSG    
To: McLure at SRI-KL, Geoff at USC-ISI
cc: HEADER-PEOPLE at MIT-MC

Sorry for speaking out without checking first.  I guess it changed after I
gave up on it and started using a mail reader built in EMACS.  I just made
some tests and found that it indeed does know how to reply to a RFC733
header: it finds the machine name inside the angle brackets and also no
longer replies to the Sender: field.  However the headers it generates aren't
so great:

    Date: 8 Dec 1978 1426-EST
    Sender: EKILLIAN at BBN-TENEXE
    Subject: Testing
    From: EKILLIAN at BBN-TENEXE
    To: EAK at MC, 
    To: EKillian
    Message-ID: <[BBN-TENEXE] 8-Dec-78 14:26:05.EKILLIAN>
    
    Foo.

First of all it used the host name "MC" in the header, rather than the
official host name "MIT-MC".  This is illegal.  In addition notice that it
used two "To:" fields instead of one with a continuation line; this is
"strongly discouraged" in RFC733.  Finally it put in identical Sender: and
From: lines, something "discouraged" in RFC733.

Date: Fri, 8 Dec 78 11:59-PST
Subject: Re: RFC 733 & MSG
From: Greep at Rand-Unix
To: DCROCKER at Usc-Isi
cc: header-people at Mit-Mc, msggroup at Usc-Isi
Message-ID: <Greep.78.341.115959 @ Rand-Unix>
In-Reply-To: Your message of 7 DEC
In-Reply-To: <[USC-ISI] 7-DEC-78 16:32:25.DCROCKER>

Whatdya mean money?  Didn't you know all this stuff is done by hackers?
If a few strategically located Chinese eateries (Coleen's, Louie's, etc)
were to close down for a few days the hackers wouldn't have anything else to
do with their time and would get all these mail fixes hacked pronto.

Date: 8 DEC 1978 1636-EST
From: MOON at MIT-MC (David A. Moon)
Sent-by: MOON5 at MIT-MC
Subject:  (BUG MUMBLE) MESSAGES FROM ITS
To: McLure at SRI-KL
CC: HEADER-PEOPLE at MIT-MC, GMP at MIT-MC, Geoff at USC-ISI

IF THE DAMNED STANDARD PROVIDED ANOTHER WAY TO DO THIS,
WE WOULD USE IT.  THE ONLY WAY IT PROVIDES IS
THE :ATOM: NOTATION WHICH IS NOT ACCEPTABLE FOR REASONS
WHICH HAVE BEEN EXPLAINED BY KLH AND ME MANY TIMES.  SINCE
THE NEW MULTICS MAIL SYSTEM ALSO NEEDS A WAY TO DO THIS, AND
SINCE THE 10X/20X MAJORITY IS EVIDENTLY NOT INTERESTED IN
CONFORMING TO THE RFC733 STANDARD IN ANY CASE, I SUGGEST WE
CREATE OUR OWN DE FACTO STANDARD.  I WOULD SUGGEST THE SAME
AS WHAT ITS DOES NOW, EXCEPT USING CURLY BRACKETS INSTEAD OF
PARENTHESES.  IT WON'T BE ANY MORE UNPARSEABLE BY HERMES AND
IT WILL CEASE TO CONFLICT WITH RFC733'S USE OF PARENTHESES
FOR COMMENTING.  ITS WILL CONTINUE TO ACCEPT THE PARENTHESES
NOTATION IN ANY CASE.

Date: 8 DEC 1978 1327-PST
Sender: DCROCKER at USC-ISI
Subject: re: standards
From: DCROCKER at USC-ISI
To: POSTEL at USC-ISIB
Cc: DCrocker, Header-People at MIT-MC, msggroup
Message-ID: <[USC-ISI] 8-DEC-78 13:27:30.DCROCKER>
In-Reply-To: Your message of DECEMBER 7, 1978

The standard specified in RFC 733 was instigated by Steve Walker,
while a Program Manager at Arpa's Information Processing
Techniques Office and was theoretically under the supervision of
the informal(?)  advisory group on Computer-Aided Human
Communication.

Arpa funds paid for the effort.

To keep the record straight, Unix message systems do not, yet,
support that standard.  The ISIA machine's Hermes also does not
support the full standard.  I expect the Unix situation will
change.

Dave.

Date: 8 DEC 1978 1324-PST
Sender: GEOFF at USC-ISI
Subject: Re:  Re: RFC 733 & MSG    
From: the tty of Geoffrey S. Goodfellow <Geoff@SRI-KA>
To: EAK at MIT-MC
Cc: Header-People at MC
Message-ID: <[USC-ISI] 8-DEC-78 13:24:40.GEOFF>
In-Reply-To: Your message of DECEMBER 8, 1978

version 4.1.6 seems to beable to handle them fine.  perhaps it is
up as NEWHERMES on your machine?  I suggest you "Compose
Suggestion" to ask why its not up on your machine.  I griped
about it a few months ago and they put it in shortly thereafter.

Date: 8 Dec 1978 1426-PST
From: Brian Harvey <BH at SU-AI>
Subject: What to do about (BUG MUMBLE) 
To:   Header-people at MIT-MC    

We at SAIL have a similar problem for file recipients and solve it by
quoting the string.  The way I read 733 it ought to be ok to say
	To: "(BUG MUMBLE)" at MIT-AI
and furthermore if the quoting doesn't override the commenthood of the
parentheses in the standard then it ought to.  We use it for distribution
list files, as in
	To: "@S1.DIS[DIS,S1]" at SU-AI



Date: 8 DEC 1978 1732-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

Another thing wrong with
    
    Date: 8 Dec 1978 1426-EST
    Sender: EKILLIAN at BBN-TENEXE
    Subject: Testing
    From: EKILLIAN at BBN-TENEXE
    To: EAK at MC, 
    To: EKillian
    Message-ID: <[BBN-TENEXE] 8-Dec-78 14:26:05.EKILLIAN>
    
    Foo.

is that there is no host name after Ekillian.
Isn't this forbidden?


Date: 8 DEC 1978 1847-EST
From: RMS at MIT-AI (Richard M. Stallman)
Subject: Why Tenex and Twenex don't handle 733
To: header-people at MIT-MC

The reason is that the people in the Tenex world who are competent to
do such work have come to care unbecomingly much about what their
"bosses" want them to work on.  They have become spineless.
Elsewhere, the hackers feel competent to decide for themselves what
needs to be done.  When some part of the system needs fixing up, the
hackers just do it.  But servility to managers seems to be part of the
culture that accompanies Tenex/Twenex wherever it goes.
People at BBN have frequently been unwilling to fix bugs that were
screwing users, because "We aren't funded to fix any bugs".


Date: 8 DEC 1978 1857-PST
Sender: FARBER at USC-ISI
Subject: Request for bibliographic information
From: FARBER at USC-ISI
To: [ISI]<MsgGroup>Mailing.List;172:, 
To: header-people at MIT-MC
Message-ID: <[USC-ISI] 8-DEC-78 18:57:25.FARBER>

Recently  IFIPS TC6 has authorized the formation of a new working
group WG 6.4 on Local Networks.  As part of the first activity of
that   group,  we  are  gathering  a  bibliography  of  pertinent
literature in this area.  We also expect to maintain  a  file  of
all   referenced  literature  and  to  develop  a  mechanism  for
supplying copies.

Now we need input into the bibliography.  Please send me items by
network and US mail.  References to internal papers would also be
very welcome.  If you send copies of the papers I will  put  them
in the file.

We expect to publish the first bibliography in January 1979.

Dave

my address for US mail is:

Prof David J. Farber

University of Delaware

Department of Electrical Engineering

Newark, Del 19711



Date: 8 DEC 1978 2227-EST
From: RMS at MIT-AI (Richard M. Stallman)
Subject: Long Live Structured Recipients
To: HEADER-PEOPLE at MIT-MC

I hope we don't have to go through all the arguments
about structured recipients again.
The "solution" of quoting the structured recipient
is no solution, because quoting clearly ought to override
the special meaning of the parentheses (or curly brackets)
as structurers.  Thus, "(BUG DDT)"@MIT-AI is NOT the same
as (BUG DDT)@AI.  The former is just a random (probably
meaningless) mailbox.  Note that things like (BUG "FOO BAR")@MIT-AI
also make sense, as does (BUG "(FOO((")@MIT-AI if we ever have
a program named "(FOO((" (which nothing prohibits).

The reason we are not willing to adopt the standard on this issue
is that it is not a mere incompatibility: our system is one level
of sophistication above RFC733 and we think that the standard
should advance to our level so that everyone can benefit from it.
We aren't willing to take a step backwards just to be standard.
We specifically do not want to find a crockish way of squeezing
our winning structured recipients into the existing standard.
Instead, we plan to implement what we claim the standard ought to be
as a way of encouraging the rest of the world to take a step forward.


Date: 8 DEC 1978 2227-EST
From: RMS at MIT-AI (Richard M. Stallman)
Subject: Long Live Structured Recipients
To: HEADER-PEOPLE at MIT-MC

I hope we don't have to go through all the arguments
about structured recipients again.
The "solution" of quoting the structured recipient
is no solution, because quoting clearly ought to override
the special meaning of the parentheses (or curly brackets)
as structurers.  Thus, "(BUG DDT)"@MIT-AI is NOT the same
as (BUG DDT)@AI.  The former is just a random (probably
meaningless) mailbox.  Note that things like (BUG "FOO BAR")@MIT-AI
also make sense, as does (BUG "(FOO((")@MIT-AI if we ever have
a program named "(FOO((" (which nothing prohibits).

The reason we are not willing to adopt the standard on this issue
is that it is not a mere incompatibility: our system is one level
of sophistication above RFC733 and we think that the standard
should advance to our level so that everyone can benefit from it.
We aren't willing to take a step backwards just to be standard.
We specifically do not want to find a crockish way of squeezing
our winning structured recipients into the existing standard.
Instead, we plan to implement what we claim the standard ought to be
as a way of encouraging the rest of the world to take a step forward.


Date: 8 Dec 1978 2029-PST
From: Mark Crispin <MRC at SU-AI>
Subject: Tenex and Tops-20 hackers    
To:   RMS at MIT-AI
CC:   Header-People at MIT-MC   


Richard,

I think it is unfair to the people who work on Tenex and Tops-20 to call
them servile and/or spineless.  A lot of those people share your distaste
for the "real world".  Many of them are there because they desire the
income of the real world, but not the lossages.  Working at a place like
MIT is fine if you're single with no ties, but painful otherwise.  Also, I
doubt that anybody at BBN (or elsewhere) is explicitly forbidden to fix
bugs.

I suspect it is more a matter of priorities: suppose I am hired to do [a].
Now I may be involved in [b] and [c] because I have a personal interest in
[b] and nobody else is qualified to work on [c].  I work on [a] because it
pays my rent, lets me eat at Louis' every night, etc.  I spend some time
on [b] because it especially interests me.  However, I totally neglect
[c], not because I'm afraid to work on it, or I'm forbidden to (I might
even be tacitly encouraged to), but just because it isn't worth it to me.
Work on [c] is unpaid time that could be spent on [b].

If people would like to flame about this more, I'd suggest starting a new
mailing list and not boring Header-People with this sort of bull.

-- Mark



Date: 8 DEC 1978 2044-PST
Sender: GEOFF at USC-ISI
Subject: Re: Long Live Structured Recipients
From: the tty of Geoffrey S. Goodfellow <Geoff@SRI-KA>
To: RMS at MIT-AI
Cc: HEADER-PEOPLE at MIT-MC
Message-ID: <[USC-ISI] 8-DEC-78 20:44:37.GEOFF>
In-Reply-To: Your message of DECEMBER 8, 1978

What an incredibly boorish message that was!  Let's keep LISPized
lossage out of this discussion since it has no bearing and
system-egotistical remarks appropriately squelched.

Since you seem to disdain the pedestrian present and therefore
refuse to implement "the standard" on the grounds its merely
below your level, why should anyone else implement it then?  If
you don't like it, why don't you direct your efforts on the next
version of RFC733 which corrects the deficiencies of the current
standard, and will make the world a better place for us all,
instead of just flaming about it, doing nothing,and not
implementing it.

Date: 8 Dec 1978 2110-PST
Sender: MCLURE at SRI-KL
Subject: Re: Tenex and Tops-20 hackers    
From:  Stuart McLure Cracraft <McLure at SRI-KL>
To: rms at AI
Cc: header-people at MC
Message-ID: <[SRI-KL] 8-Dec-78 21:10:36.MCLURE>
In-Reply-To: Your message of 8 Dec 1978 2029-PST

Needless inflammable remarks have no place in discussions of this
sort.  733 should be generally acknowledged; it is not so
unreasonable as you make it out to be.  i think the
unreasonableness comes in LISPing mailing groups and then trying
to propogandize that through hard-nosed oppressives

Date: 9 DEC 1978 0520-EST
From: rms at MIT-AI (Richard M. Stallman)
Sent-by: ___014 at MIT-AI
Subject: Refusing to fix bugs.
To: header-people at MIT-MC

When I say that people at BBN refuse to fix bugs because
they aren't funded to do so, I can cite a specific instance
in which a person working at BBN was given such an answer.
Anyone who wants details can ask for them.
So much for specifics.  That the general climate is also that
way ought to be well known.


Date: 09 DEC 1978 0843-EST
From: Joanne Sattley <JZS at CCA>
Subject: ITS format
To:   Header-People at MIT-AI

My program is trying to parse its way through ITS-format mail and will
index separately on as many different parts of each message as can be
isolated.

The line containing author/date/optional subject turns out to be easy
to do once it has been found;  since the order of header-lines is not
important to the program, and all the others begin with a field-name
followed by a colon, it picks out the author... line by finding an "@"
instead of the colon.

I'm looking for a reliable way to identify the beginning of the text
portion of an ITS message & would appreciate learning your thoughts on
this matter.

--Joanne
-------


Date:    9 Dec 1978 1154-EST
From:    RICK.GUMPERTZ(N810RG02) at CMU-10A 
Subject: quoting
To:      Header-People at MIT-MC

It seems to me that there are two possible uses for quoting:

1) To make names not understood by other hosts (i.e. not understood
by RFC 733) acceptable, with the proviso that the host that does
understand it will do the "right" thing.

2) To literally quote the atom for all time.

It seems that RMS thinks the second case is the only possibility.
Personally, I see that as not very useful, but let us not argue that.
Maybe RFC733 should have provided two sorts of quoting (what that
discussion again?).

In any case, it seems that te most reasonable compromise for
practicality of getting things implemented is to use the first
notation.  ITS can get the second notion either by establishing their
own internal quoting character such as \ (to keep the Lithpers happy)
or by nesting quotes.

Thus, "(BUG \MUMBLE)"@MIT-AI or "(BUG ""MUMBLE"")"@MIT-AI or maybe
even "(BUG 'MUMBLE')"@MIT-AI as the EXTERNAL (i.e. ARPANET, not ITS
internal) representation of a quoted MUMBLE parenthesized with BUG.

For the really peverse person who wants to have a single level name
with parens, """(BUG MUMBLE)"""@MIT-AI.

		Rick

Date: 9 DEC 1978 1206-PST
Sender: DCROCKER at USC-ISI
Subject: Re: Long Live Structured Recipients
From: DCROCKER at USC-ISI
To: RMS at MIT-AI
Cc: HEADER-PEOPLE at MIT-MC
Message-ID: <[USC-ISI] 9-DEC-78 12:06:08.DCROCKER>
In-Reply-To: Your message of DECEMBER 8, 1978

It is incredible to me that you still do not understand the difference
between what the "standard" interprets and what individual hosts interpret.
The quoting convention is to overide the syntax of the standard, in
case the contained text, which is presumed to be meaninfgul to the
referenced host, happens to include characters which has special
meaning to the standard.  For example,

"(Bug Mumble)" at mit-ai should cause

(Mug Mumble) 

to be given as the arguement of the MAIL/MLFL Ftp command.

(Bug "Mumble Foo") at mit-ai is likely meaningless, since everything 
between the parens is taken, by the standard, as a comment and therefore
NOT passed in the FTP command.  I believe you want

"(Bug \"Mumble Foo\")" at mit-ai.

dave.

Date: 9 DEC 1978 1753-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

Most of the replies to my message have misunderstood our goals.

We are not trying to find a way to compromise with RFC733.
We could indeed use the solution suggested by DCROCKER and Gumpertz,
if we thought that sort of "solution" desirable.
But that would make them ugly, and what do we have to gain by that?
Also, it would permit everybody else to forget about them, and never
give the idea any further consideration.  We don't want everyone
to forget about the idea;  we want everyone to adopt it.

We are also unwilling to disfigure a feature we have used for years
for the sake of a standard made by others who refused to consider our
needs.  It's not as if we didn't tell them or didn't try to help.
They simply decided that we weren't important enough to them to be
worth considering.  And now, they quote their decision as if it were
a fundamental fact that we are simply ignorant of (look at the tone
of DCrocker's message).  Well, we don't owe RFC733 any more consideration
than it gave us (though in fact, we give it a lot more than that).
We may be nothing in the eyes of the rest of the world, but to ourselves
we are more important than the standard.

Do not overlook the basic difference between the MIT situation and
that of all the other sites that had to convert (including Tenex,
which hasn't done so):  everyone else had to make just cosmetic changes.
They might well have been reluctant to do the work, but had no reason
to be opposed to the result of the work.  We don't mind doing some work,
be we will not agree to make our system worse.  We don't mind making
some cosmetic changes ourselves, such as using curly brackets instead
of parentheses, so that we have a system that other people could
conceivably adopt.  But we are adamant in keeping our system one
which we can approve of and think of as properly designed for
the goals that we have for it.


Date: 10 DEC 1978 1356-EST
From: EAK at MIT-MC (Earl A. Killian)
Subject:  ITS format
To: JZS at CCA-TENEX
CC: HEADER-PEOPLE at MIT-MC

Unfortunately the ITS "internal" header format was not really designed to be
parsable.  There is no real way to tell where the header ends and the text
begins.  Most of our programs stop when they find a line after the first which
doesn't begin with "TO:" or "CC:" which of course loses when the user starts
his text with one of those strings.

Some programs determine whether a message has an ITS or net header by looking
at the character after the first word; if it is an "@" then it is an ITS
header.  I much prefer, however, searching the first line for either "@" or
":" and seeing which is found (some people will set the from field of the
message to their full name (i.e. something with spaces) which will confuse
the first algorithm).

Finally, do you know the syntax used to specify the "Sender:" when it is
different from the "From:" in ITS headers?

Date: 10 DEC 1978 1954-PST
From: POSTEL at USC-ISIB
Subject: (BUG MUMBLE)
To:   RMS at MIT-AI
cc:   Header-People at MIT-MC


Richard:

pardon me, i seem to have forgot the details of just what winning thing
it is that your mail system does when a message to "(BUG MUMBLE)" arrives
and why it is that that syntax is so crucial to the operation of the
feature.

--jon.
-------

Date: 11 DEC 1978 1831-EST
From: MMCM at MIT-AI (Mike McMahon)
Subject: Re:  Re: RFC 733 & MSG    
To: McLure at SRI-KL, EAK at MIT-MC
CC: Geoff at USC-ISI, HEADER-PEOPLE at MIT-MC


    Date: 8 Dec 1978 1117-PST
    Sender: MCLURE at SRI-KL
    From:  Stuart McLure Cracraft <McLure at SRI-KL>
    In-Reply-To: Your message of 8 DEC 1978 1340-EST

    As another Hermes user, I can vouch that it can handle 733.  The
    only things that it can't handle are all those (BUG MUMBLE)
    messages from Its.

In fact HERMES cannot handle various quoting cases such as "@FILE.EXT[PRJ,PGM]" at SU-AI.

Just as a matter of fact, MM violates 733 right now in parsing by accepting
(BUG FOO) at MIT-AI as not a comment, and supplying the hostname in To fields that
10X/20X sites seem quite prone to leave out.

Date: 11 DEC 1978 1933-EST
From: KLH at MIT-MC (Ken Harrenstien)
Subject: What is (BUG MUMBLE) for?
To: Postel at USC-ISIB
CC: HEADER-PEOPLE at MIT-MC

Jon asks what (BUG MUMBLE) is for.  I'll explain again for
the benefit of new-comers and others not up to the task of
scanning Header-people archives.

	For many years, long before the dawn of CAHCOM or
Header-people, and long long before RFC733, the ITS sites have been
using the idea of "structured recipients".  In brief, recipients are
expressed as a LIST of elements, which may have sub-lists.  The fact
that the printed representation is LISP-like merely reflects a desire
to accomodate the primary user population on these systems, which is
accustomed to this sort of list representation; LISP itself is not
involved.

	 Each recipient has a TYPE and a NAME, and perhaps other
ATTRIBUTES, in this general form:
	(<type> <name> <attrib1> <attrib2> ... )
	where each <attrib> is expressed as (<attribname> <attribval>).

EVERY recipient is expressed in this syntax or a degenerate
form thereof.  For example, the following are equivalent:

	Header-people@MC
	(Header-people @MC)
	(NAME Header-people (SITE MC))

It should be clear that this scheme has great flexibility and power.  In
current practice, we make use of the following recipient <type>s:

	NAME	- regular vanilla recipient NAME; send to personal mailbox
	BUG	- NAME is a program name; send to implementors
	FILE	- NAME is a filename; send to that file
	@FILE	- NAME is a filename; send to recipients listed in file
	PGM	- NAME is a program; run it with message text as argument
	*MSG	- NAME is a bulletin-board name/site; post message there

For example, what "Header-people" equivalences to is

	(@FILE [KSC;HEADER PEOPLE])

which is why that particular file always represents the Header-people group;
if you furnished that recipient to the MC FTP server, the message would
be handled in practically the same way as "Header-people".
How this equivalencing is done is another subject, but it also involves
structured lists of recipients and options, to a greater degree.

The example (BUG MUMBLE) causes COMSAT to see if it knows who the
maintainers of the MUMBLE program are; this information is
kept in a public database.  If there aren't any, the message is forwarded
to MIT-AI, where most little-known programs are maintained, and if
there are still no maintainers, the address is changed to (BUG RANDOM-PROGRAM)
which is simply a vector to those people willing to accept bug messages
about random programs.  The point is that this behavior is special
and is different from that accorded to a regular NAME-type recipient.

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

Anyway, that should answer the question of "what good is it".  As far
as the RFC733 form of representation goes, I agree with Moon and RMS
that 733 was not responsive to our needs.  (It should be noted that
there was a fair amount of message traffic on the subject between the
733 authors and some ITS people, which was not distributed to
Header-people, but nothing came of it).  We made a considerable
compromise in allowing "()"s to enclose comments; this was done in the
expectation that a substitute would become available, but none was
forthcoming.

I might as well repeat some of RMS's message here:

	We could indeed use the solution suggested by DCROCKER and Gumpertz,
	if we thought that sort of "solution" desirable.
	But that would make them ugly, and what do we have to gain by that?
	Also, it would permit everybody else to forget about them, and never
	give the idea any further consideration.  We don't want everyone
	to forget about the idea;  we want everyone to adopt it.

Those who think "ugliness" is a trivial reason probably under-estimate
both the volume of ITS message traffic and the use of structured
recipients in same.  And it isn't necessary to force a revolution among
mailers to "adopt" the idea; all that is required is some syntactical
rule extensions to 733 which recognize bracket nestings.  We have in
fact proposed some specific extensions, but I don't suppose most people
bothered to read the file describing them; this can be remedied by
mailing it out.

Date: 12 Dec 1978 0918-PST
From: Reid at SRI-KL
Subject: FTP question
To:   Header-People at MIT-MC

This is a straight technical question which has got me stumped.
I want to FTP binary files to a Unix, setting all 8 bits of each
character.  I can't find any way to set that last bit, since FTP
on both this 20 and CMU's 10 uses 7-bit characters when you give it
BYTE 8.  Any ideas?
-------

From: Kiessig at Rand-Unix
Date: 12 Dec 1978 at 1142-PST
Message-Id: <[Rand-Unix]12-Dec-78 11:42:26.kiessig>
To: Reid at SRI-KL
cc: Header-People at MIT-MC
Subject: Re: FTP question
In-reply-to: Your message of 12 Dec 1978 0918-PST.

I have had this same problem going from Unix => PDP-10/20's.  There are
two solutions that I have used with equal probabilities of success:

1) Send the sources of your "binary file", or the sources of the program
   that created this file.  This can then either be recompiled or translated
   to a supported language.

2) Send the file as 4-bit bytes, and then reassemble these bytes on the
   receiving side.  I'm not sure if your FTP will perform the correct
   operation if you specify 4-bit bytes, so you may in fact have to
   break the file up before you send it  (someone else should know
   about this, right??).

Transmitting "image format" between PDP-11's and 10/20's has been a
problem for some time.  I try to avoid it unless absolutely necessary
by using 1) above.

Rick

Date: 12 Dec 1978 1457-EST
From: Rick Gumpertz at CMU-10A
Subject: Re: FTP question
To:   Reid at SRI-KL
Message-ID: <12Dec78 145728 RG02@CMU-10A>
In-Reply-To: Reid's message of 12 Dec 78 12:18
Remailed-To: Header-People @ MIT-MC
Remailed-From: Rick Gumpertz at CMU-10A
Remailed-Date: 12 Dec 1978 1500-EST

What modes does UNIX support??  Will it take Byte 36 Type Image??

If not, maybe would could bounce it through C.mmp -- it supports
8 bit ascii!

See me for details

                Rick

From: Kiessig at Rand-Unix
Date: 12 Dec 1978 at 1226-PST
Message-Id: <[Rand-Unix]12-Dec-78 12:26:57.kiessig>
To: Rick Gumpertz at CMU-10A
To: Reid at SRI-KL
cc: header-people at MIT-MC
Subject: Re: FTP question
In-reply-to: Your message of 12 Dec 1978 1457-EST.
             <12Dec78 145728 RG02@CMU-10A>

UNIX does not support byte 36 type images (at least none that I know
of do).

Another way which I have transferred binary files between machines with
much more success than the others I mentioned is to convert the whole
file to its octal equivalent, and then ftp that file.  This can then
be converted back to its binary equivalent on the receiving machine
with relative ease.

Good luck,

Rick

From: Dcrocker at Rand-Unix
Date: 12 Dec 1978 at 1244-PST
Message-Id: <[Rand-Unix]12-Dec-78 12:44:15.dcrocker>
To: KLH at MIT-MC (Ken Harrenstien)
cc: HEADER-PEOPLE at MIT-MC,
Subject: Re: What is (BUG MUMBLE) for?
In-reply-to: Your message of 11 DEC 1978 1933-EST

Ken -- many thanks for your lengthy exposition about "structured addresses".

Just to make sure I understand correctly, I take your note to say that RFC733
does  NOT  prevent you from transmitting the addresses but that you do not
APPROVE of the proffered mechanism(s) and CHOOSE not to conform with it/them.

Correct?

(Please note that the above is truly intended to make a particular issue clear and
is NOT intended to comment on the sagacity of your stance.  That is an entirely
separate discussion.)

Thanks.  Dave.

Date: 12 DEC 1978 1259-PST
Sender: DCROCKER at USC-ISI
Subject: Re:  Re: RFC 733 & MSG    
From: DCROCKER at USC-ISI
To: MMCM at MIT-AI
Cc: McLure at SRI-KL, EAK at MIT-MC, Geoff, 
Cc: HEADER-PEOPLE at MIT-MC
Message-ID: <[USC-ISI]12-DEC-78 12:59:42.DCROCKER>
In-Reply-To: Your message of DECEMBER 11, 1978

(ISI) Hermes handles SOME of RFC733.  It does NOT handle ALL of
it.

The following was a trivial test I conducted that should have
succeeded.  Lest you think I was being capricious, please note
that it should have been handled, as per rfc733, and that its
form really does occur on the net, now, with (at least) mail from
CMU:

	
Mail from USC-ISI rcvd at 12-DEC-78 1250-PST
From: David Crocker at Rand-unix
Subject: a test of 733


          --------------------
		
The From: field is semantically invalid, in that Rand-Unix
won't handle it properly, but Hermes doesn't know that.  Nevertheless,
its Reply function hiccuped on the syntax.

Dave.

Date: 12 DEC 1978 1655-EST
From: Joanne Sattley <JZS at CCA>
Subject: On beyond (BUG MUMBLE)
To:   DCrocker at RAND-UNIX, KLH at MIT-MC
cc:   Header-People at MIT-MC

There are two other points of conflict between ITS-style mail and the
733 Standard Format which seem to have been overlooked:

  .  The Standard does not provide for the unnamed ITS header line
     which contains the author/date/subject information; and

  .  ITS-mail does not provide an unambiguous way of separating
     the message-header from the text body.

I have no arguments to add to the structured recipients issue, though
-- for what it's worth -- my program would be grateful for curly braces
rather than parentheses.

--Joanne
-------

Date: 12 Dec 1978 1614-EST
From: Rick Gumpertz at CMU-10A
Subject: Re: FTP question
To:   Reid @ SRI-KL
CC:   header-people at MIT-MC
Message-ID: <12Dec78 161409 RG02@CMU-10A>
In-Reply-To: <[Rand-Unix]12-Dec-78 12:26:57.kiessig>

CMU-Cmmp (Hydra) will support a funny form of image file.  It assumes
the PDP-10 has packed four bytes per word, with garbage in the top
two bytes of each halfword.  This is the /P format used by MACN11,
LINK11, et.  al.  In any case, Hydra FTP knows how to transfer in 36
bit image mode from the PDP-10 and then throw away the padding and
store it as a byte sequence.

This all is used to transfer binary files compiled on the PDP-10 to
be run on Hydra.  It also can do the reverse (add 2 bits before each
16) for the inverse operation.

Therefore, to transfer a file, one could shove it from the PDP-10 to
Hydra in this funny image mode and then from Hydra to UNIX in ASCII
mode, assuming UNIX allows arbitrary 8 bit data in ASCII mode.  The
inverse could be used for transferring in the other direction.

To obtain a Hydra account, contact me.  To copy the source of the
funny packing/unpacking (which is in Bliss-11) contact me for that
too.  Aren't you sorry you asked?

                Rick Gumpertz

From: Kiessig at Rand-Unix
Date: 12 Dec 1978 at 1532-PST
Message-Id: <[Rand-Unix]12-Dec-78 15:32:35.kiessig>
To: Rick Gumpertz at CMU-10A
To: Reid at SRI-KL
cc: header-people at MIT-MC
Subject: Re: FTP question
In-reply-to: Your message of 12 Dec 1978 1614-EST.
             <12Dec78 161409 RG02@CMU-10A>

I believe most Unix installations accept 8-bit ASCII with no problems,
so the scheme you suggest should work well, assuming all three machines
are up and available at one time, etc.

Date: 12 DEC 1978 1941-EST
From: MOON at MIT-MC (David A. Moon)
Subject: On beyond (BUG MUMBLE) <JZS>
To: HEADER-PEOPLE at MIT-MC

Now, wait a minute!  There are two issues here.  So-called ITS headers
are an internal format which is not supposed to go out to anyone else
on the network and which makes no attempt to conform to anyone else's standard.
Unfortunately there is a misfeature of the way our mail system
works whereby it can think it's sending from one ITS to another, and therefore
uses an ITS header, but the mail ends up at a non-ITS site, causing grief
to all concerned.  It would have been fixed long ago except that it is
difficult to fix.

We certainly don't propose proseletyzing the use of these headers!
ITS headers don't provide any extra feature, they are simply a compact form
of header designed to avoid hassling humans with excess information.

What we would like to see spread to the world in general, and be accomodated
within RFC733, is ITS structured addresses.  These are not headers but names
for receivers of mail.  Unlike ITS non-standard headers, these are not a cosmetic
change but a semantic capability not otherwise present.

Date: Tuesday, 12 Dec 1978 2017-EST
From: Brian Reid at CMU-10A
Subject: Structured Recipients
To:   HEADER-PEOPLE at MIT-MC
Message-ID: <12Dec78 201722 BR10@CMU-10A>
In-Reply-To: David A. Moon's message of 12 Dec 78 19:41

From where I sit (which is in California this week) all of this 
brouhaha over structured recipients really boils down to quoting conventions.
ITS people would like to be able to use XXX as a recipient name, for some 
binding of XXX.  RFC733 says "If you want to use certain XXX values, you
have to put them in quotes".  But then ITS people say, "We can't guarantee
that the string XXX won't contain a close-quote character and thereby 
screw up the quoting; we need a better quoting convention.

Is this not the essence of the dispute?  Are we not just fighting over
the fact that some ITS addresses are hard to quote in the current RFC733
quoting convention?  Or is there some deeper meaning that totally
escapes me, by which there is a serious and irreversable semantic difference
between putting "(BUG MUMBLE)" and (BUG MUMBLE) into one's TO list?

Brian

Date: 12 DEC 1978 2200-EST
From: KLH at MIT-MC (Ken Harrenstien)
Subject: Clarification
To: Dcrocker at RAND-UNIX
CC: HEADER-PEOPLE at MIT-MC

Yes, you are correct that while ITS sites are not prevented from
transmitting the addresses, we don't approve of the mechanism
and thus chose not to implement it.  This is not quite as obstructionist
as it might appear, since it derives from a belief that a better
way exists and can be made a part of 733 with little perturbation.

I was hoping to include the previously mentioned syntax
specification here, but the only copy I can find is on paper and
will require some work (I also want to make sure it synchs with
733 as published, as opposed to one of those intermediate versions).
A little patience will suffice...

Date: 12 DEC 1978 2241-EST
From: MMCM at MIT-AI (Mike McMahon)
Subject: FTP question
To: Reid at SRI-KL, Header-People at MIT-MC

incanting "TYPE L" to the user FTP on SRI-KL will cause it to read and write
8-bit files correctly.

Date:     13 December 1978 0031-est
From:     Robert M. Frankston      <Frankston at MIT-Multics>
Subject:  Requoting
To:       header-people at MIT-MC

1. I'd like to state that between the FTp issues and the structured
address, I am impressed by the impulse response of a dormant
header-people.

2. I think the basic issue is not quoting, it is one of requoting. For
example, when one wants to send a letter to host A, via host B, what is
the correct syntax? The problem with naive quoting is that it doesn't
tell Host B whether to preserve the quoting, or remove it for the next
level of interpretation.  The advaantage of the nesting notation is that
one only need to remove the top level nesting for local interpretation
and then pass it on.  Of course, both techniques, quoting to get odd
characters in, and quoting for hiding atoms from interpretation are
necessary but it should be realized that both functions are necessary. 
Thus one could say:

 to: {sas at arcmac} at mit-multics.

Of course there is still the problem of how to express something like

 to: {sas at arcmac} at Frankston at mit-multics

Where "Frankston at mit-multics" is the normal a3net address of my
process which would then forward the mail out via the DDD network to the
arcmac host.  The first example is simpler since we assume tha the
standard network server at mit-multics will parse {sas at arcmac} and do
the forwarding itself.. In the second case, we can treat the address as
a path through the network (specified backwrds} to the destination. 
Each processor handles the last token in deciding where the message is
to go next.

From: Dcrocker at Rand-Unix
Date: 13 Dec 1978 at 0759-PST
Message-Id: <[Rand-Unix]13-Dec-78 07:59:57.dcrocker>
To: KLH at MIT-MC (Ken Harrenstien)
cc: HEADER-PEOPLE at MIT-MC,
Subject: Re: Clarification
In-reply-to: Your message of 12 DEC 1978 2200-EST

Boy am I confused!  Why is it that you cannot simply specify:

sas at arcmac at mit-multics

and

sas at arcmac at Frankston at mit-multics

??

Dave.

Date: 13 Dec 1978 1153-EST
From: Rick Gumpertz at CMU-10A
Subject: Structured addresses
To:   Dcrocker at Rand-Unix
CC:   Header-People @ MIT-MC
Message-ID: <13Dec78 115327 RG02@CMU-10A>
In-Reply-To: <[Rand-Unix]13-Dec-78 07:59:57.dcrocker>

Although it may conflict somewhat with your conception of the meaning of "at",
it seems to me that ITS could use the form
        MUMBLE at BUG at MIT-MC
as their external representation of structured names.  Similarly,
        "[FILE NAME etc.]" at FILE at MIT-MC
and so on.  Of course, their mail reading programs could pretty this up internally
for consumption by people, in LISP format or whatever they want.

                Rick

Date: 13 Dec 1978 1657-PST
From: Klh at SRI-KL (Ken Harrenstien)
Subject: New syntax for <Host-phrase> - <balanced>s
To:   Header-people at MC

Okay, here is some syntax to chew on.  All I am going to furnish in this
message is simply what a reader would have to know in order to
do "Answering" correctly.

Change to existing rule:

      Host-phrase = (phrase / balanced) host-indicator

Add 2 new rules:

    balanced = ("[" *(btext / balanced / quoted-pair) "]")
             / ("{" *(btext / balanced / quoted-pair) "}")

    btext = *<any CHAR excluding "\", "[", "]", "{", "}" and CR> ; can fold

This syntax is exactly the same as that for <comment>, with the
delimiting characters changed.  I wish 733 had adopted RMS's notion of
"Parameterized BNF" so that comments and balanceds (and other stuff)
could all share the same rules with different delimiters as parameters.
As for semantics, the brackets and everything inside except the
quote-next characters are retained when passing the string to the
remote FTP server.

You will note that this definition does not allow the use of
quoted-strings within the body of the <balanced>.  This means
that quotemarks can be included in the text, and passed to the
remote site, with no special quoting.

This definition also does not count <>s or ()s as necessary to
balancedness.  I don't see any particular reason for doing so,
and in fact can think of some arguments against it.  For
example, filenames on both ITS and Multics make use of unbalanced
">"'s and files are a common form of structured address.

I have at hand a more detailed definition which lays out the
basic rules for what can be put inside a <balanced>, but they
may not be necessary and it seems better not to confuse
matters at this stage of discussion.
-------

Date: 13 DEC 1978 2109-EST
From: KLH at MIT-MC (Ken Harrenstien)
Subject: foo at bar at mumble at bletch
To: Gumpertz at CMU-10A, Dcrocker at RAND-UNIX
CC: HEADER-PEOPLE at MIT-MC

You should be addressing R. Frankston, not me.
I'm confused too.
Forget about MUMBLE at BUG at MIT-AI.  Remember our addresses
are not just simply a type and a name.  They are a structured
form which could be called maximally general if you accept the
premise that tree structure is so.

I do agree that the quoting problem involves "re-quoting".
Note also that the originating site of a message can theoretically
always specify how its own addresses are to be quoted, by nesting
things as deeply as necessary.  However this is not true for
messages that originate at other sites wherein the address is
furnished by user typein.  It seems perfectly reasonable to me to
talk about standards for the FTP MAIL/MLFL commands (although
probably not in as much depth as Hathaway would have liked), since
there is already an implicit limitation (no CRLF allowed in the string)
which 733 disregards (You can quote a CRLF in an address).

Another thing some people may not realize is that the quote-next
character is not allowed to quote the next character anywhere
but within a comment or quoted-string, according to 733.  Thus
the only thing it is good for is quoting (,),", and perhaps CRLF.
I think it should be more general than this.

It should be clear that quoting is a big hairy problem and that
the less one has to quote, the fewer snarls and tangles one
will have in pushing addresses through various channels.  This
is one of the reasons we don't like a syntax which would force quoting
of so many of our constructs, when reasonable non-quoting
alternatives exist.

Date: 15 Dec 1978 1236-EST
From: Rick Gumpertz at CMU-10A
Subject: Re: New syntax for <Host-phrase> - <balanced>s
To:   Klh at SRI-KL (Ken Harrenstien)
CC:   Header-People @ MIT-MC
Message-ID: <15Dec78 123653 RG02@CMU-10A>
In-Reply-To: Ken Harrenstien's message of 13 Dec 78 19:57

1) I think balanced text should only be delimited by (and count) braces.
   Brackets should be ignored as are <>.  Make the parser as simple as
   possible.

2) Balanced text should be allowed anywhere an identifier is allowed
   rather than just in host phrases (syntactically anyway).
   I forget the exact 733 syntax so I am not describing this very
   exactly, but my intent should be clear.  Why restrict things
   to particular contexts when they may be useful elsewhere as well?

                Rick

Date: 20 DEC 1978 1008-PST
From: POSTEL at USC-ISIB
Subject: re: rfc 733 & extensions
To:   Header-People at MIT-MC
cc:   postel


i vote yes on the extensions put forward by KLH. Lets vote it in and
produce a revised document.

--jon.
-------

Date: 20 DEC 1978 1940-PST
Sender: DCROCKER at USC-ISI
Subject: KLH's Proposed Changes to the RFC 733 Standard
From: David H. Crocker <DCrocker at Rand-Unix>
To: Header-People at MIT-MC, 
To: [ISI]<MsgGroup>Mailing.List;174:
Message-ID: <[USC-ISI]20-DEC-78 19:40:48.DCROCKER>

   KLH is proposing changes to the standard specified in RFC 733.
These changes would allow the standard to more directly support
features currently in use at the MIT 10's and deemed by them and
others to be beneficial.

   A while ago, I verified that RFC 733 does not prevent the encoding
of information which uses the features; rather, the mechanism for
doing the encoding is deemed awkward.  The encoding causes the
information to be treated as a simple literal string, rather than a
structured data object.  It was claimed that one advantage to changing
the standard was that it would make it more difficult for message
system implementors to ignore the good things that one could do with
the structure-encodings.

   If I understand the proposal correctly, two things are recommended:
a) allow nesting of certain parentheses, and b) allow an additional
parenthesization set (curly-brackets) within the standard.  Angle-
brackets now define mailbox-references, within addresses, and regular
parentheses define (non-semantic) comments.  The curly-brackets would
define lists (or trees, since they could be nested) which could occur
in place of an atom in an address.

   First, I hope the above is reasonably accurate, since what follows
is based upon it.  Second, let me slip in the comment that I think the
use of structured data is generally a good idea.  Third, what follows
does not continue in such a supportive vain.  I will first comment on
the tactics of the proposal and then on its technical merits,
within the current standard.

   The standard was defined over the course of one year and was
published, in its current form, more than one year ago.  Many (though
of course not enough) sites have implemented parsers for the standard
and some of these are being used.  To incorporate the proposed change
would require that these implementors go back and (again) change their
message system address parsers.  We are having enough difficulty in
getting systems to conform to the standard even minimally; I have
little hope that we would have even that much success in getting them
to make further revisions.  Remember that RFC733, itself, is claimed
to be a revision.  It attempts to re-specify the standard contained in
RFC 680, with as few changes as possible, so that the message-using
world can conduct business as it currently wants to while we go off
and define a really good protocol/standard.  That was our intent at
the outset and nothing has changed since then.

   Some people seem not to appreciate the real-world difficulties in
getting a place to allocate (and spend) the programmer-time to make a
system change.  Good intent on the part of a programmer is not enough,
given that s/he has work to do which a) is what they are paid to do
and b) takes up all/most of their time.  The absence of strong
motivation by the programmer is even worse, since then ONLY a
directive from the boss will cause the change to happen (maybe).
("Good intention", of course, can really mean "possessiveness" and
thereby can have the negative effect of prohibiting others from
working on one's system.)  All of this is intended to suggest that
getting many tens of independently owned and operated systems to
incorporate a standard is a non-trivial process and one ought to keep
it as smooth as possible.  (Some people wanted the standard phased in
in a way that would have made it distinguishable from the old
standard, expressly for the purpose of smoothness; unfortunately, it
also would have added substantially to the cost of making the change,
in some cases affecting other software.)

   There is a vast array of nifty features that we (collectively or at
least individually) would like to see in message communication
software.  I have my set; each of you has yours; and though I would
expect considerable overlap, the sets are not identical.  If you look
back to earlier drafts of the current standard, you will find that
several features are no longer in it.  Some fields are no longer
defined and the list of special (reserved) characters has been
shortened.  In fact, curly- brackets used to be reserved.  The reason
the things were removed was to streamline the standard.  This goes
back to the basic intent of the effort.  We were NOT trying to embody
all -- or even all of the best -- of the good message system ideas;
just enough of them to keep the real world quiet for a few years.
That goal, I think, is being forgotten.

   Clearly, building a parser that maintains nesting of parentheses is
no difficult thing.  It is, however, more difficult than not
maintaining the nesting.  (We even require it at one point in the
standard.)  In this case, it seems particularly ill-advised to incur
that cost for all RFC733 parsers when a) only a few are likely to use
it in the near term, and b) the information embodied in the "list-
isizing" can be encoded without imposing the burden on everyone.
Should you think that the burden is trivial enough to be warranted,
then note the confusion about "levels of quoting" that continues in
our group even after TWO YEARS of discussion.

   From the perspective of the standard, address information occurs in
two kinds of places.  The first is an RFC733-oriented place and the
second is everywhere else.  Quoting only takes place within
RFC733-oriented places.  When information is put into an
RFC733-oriented place, quoting is added as necessary and it is removed
when translation takes place into a non- RFC733-oriented place.
Translation between two RFC733-oriented places is a simple copy, with
quoting preserved; no changes to the data should take place.

   For example, an MIT address might be "(Bug Mailer) at MIT-MC".  In
RFC733, this would be:

        "(Bug Mailer)" at MIT-MC

and when it is translated, it is passed in a way that indicates that:

	(Bug Mailer)    is a mailbox reference, and
	MIT-MC          is a host reference

For example, the FTP server should get exactly the first string and it
does not need the second.

   Personally, I find it difficult to sustain the claim that the
presence of the surrounding quotation marks is all that offensive,
since we encounter them regularly in prose and most of us are fairly
used to them.  (For example, note how I specified the address when
introducing it in the text.)  However, such a quotation scheme does
not support ALL character sequences and an added quoting mechanisms is
provided, WITHIN QUOTED STRINGS.  It was limited to that location
because that is the (only) place that highly site-dependent
information is SUPPOSED to occur.  Only three characters need to be
quoted:  carriage-return and the two quotation characters.  (I just
discovered that the standard does not properly indicate that the
single-quoting character (back-slack) itself needs to be quoted by a
back-slash.)  Neither is terribly popular within addresses.

   For example, it has been noted that the carriage return could not
be supported in the Arpanet, since it terminates the ftp MAIL/MLFL
command lines.  (I suspect that that is not entirely true, but don't
think the issue worth pursuing.)  The second and third characters seem
equally unlikely, but it did not seem reasonable to prohibit their
use.

   It was claimed that the ":<atom>:" construct is not adequate
either.  This wasn't elaborated upon, so I am not certain what
objections there were.  Note that this mechanism was specifically
intended to provide a mechanism encoding new and experimental
features.  That is why, on its own, a ":<atom>:" address is supposed
to be ignored by those who do not understand it.  The standard allows
multiple address to be supplied for a single "person".  This provides
the necessary handle for the use of the special structure:

	Mailer Bugs <:list:(bug mailer) at mit-mc,
		     "(bug mailer)" at mit-mc>

The current standard says that the meaning of the list is that EACH
mailbox is to receive a copy.  However, ignorant sites couldn't use
the first form and would therefore only send to the second, while
knowledgeable sites should be able to discern that the two addresses
resolve to the same mailbox and therefore they would only send one
copy out.

   Well, enough of this.  I am claiming that the timing of the
proposal is wrong.  The features were proposed before, analyzed,
deemed meritorious for longer-term goals and rejected for the current
standard.  Some may feel that the proposal was "ignored" but, since I
attended the relevant meetings, I am painfully certain that it
received considerable attention.  I am also claiming that the current
standard allows encoding the information fairly easily, though
admittedly, in a way which does not require/expect other sites to use
it.

   I will end by commenting that I object to the idea of coercing
others to conform to a special set of features, felt to be good by
some but not in general use, without an extremely strong set of
additional needs to support the coercion.  It is one thing to OFFER
something that you (privately) think is worthwhile; and it is quite
another to IMPOSE it.  The intent of RFC733 is to impose a standard.
That is only reasonable in the face of a VERY strong need.  The need
has been demonstrated in the variety of difficulties experienced and
expressed by many message system implementors.  The current proposal
fails to make an adequate case for ITS being imposed on everyone.

Date: 20 Dec 1978 2022-PST
From: Mark Crispin <MRC at SU-AI>
Subject: KLH's proposed changes to RFC 733 
To:   Header-People at MIT-MC, MsgGroup at USC-ISI   

Yes, yes, yes, let's adopt KLH's changes.  The argument that it would be
an "imposition" is superfluous.  RFC 733 in itself is an imposition; look
at all the sites that haven't implemented it!  The "real world" probably
is never going to implement RFC 733.

From my experience in dealing with the real world, they would consider
two-year-long arguments about mail headers to be not only bullshit, but a
waste of time and money.  These are the sort of people who consider MSG
needlessly hairy, and use it instead of the TYPE monitor command only
because TYPE would type every message they've received since the year 1.
And by real world I mean the REAL world.  The REAL world has no representation
on the Arpanet.

Let's not kid ourselves; this stuff about mail headers is strictly for
Arpanet hacker types like us.  I doubt if anybody cares, other than
perhaps being outraged at this use of taxpayer's money (think what would
happen if Proxmire found out!).  I have heard much of this sort of thing
from several people: "Why does your [RFC 733] mail system send headers my
[Tenex] mail reader can't read?"  "Why is all of this cruft in the mail
headers I receive"...as if it's MY fault as a hacker that this is
happening.

In light of all this, KLH's changes are reasonable.  They seem to be of
greater benefit than some of the RFC 733 options, like postal addresses
and header comments, etc.  They will provide a good deal of benefit to a
certain group of extensive and sophisticated mail users without
significantly screwing the rest of the world.  So much violation of 733
goes on that is much more of a screw to others than supporting these
addresses.

Is the standard supposed to be a network-supported and designed standard,
or a DCrocker-supported and designed standard?  There doesn't seem to be
much attention paid on the part of the authors of 733 for opposing
viewpoints.  In fact, it seems that any opposing viewpoint seems to get
an immediate veto on what seems to be one person's esthetic standards.

Sorry for this needlessly long message, but a scan of my incoming mail
on this topic seems to indicate that this sort of thing is in vogue again.

-- Mark



Date: 21 DEC 1978 0058-EST
From: RMS at MIT-AI (Richard M. Stallman)
Subject: In the spirit of Fortran
To: HEADER-PEOPLE at MIT-MC

When RFC733 was about to come out, I tried to move for structured
recipients to be included by talking with all the CAHCOM members
in my vicinity.  They liked the idea, but said that it was too late
to include, and they would think about putting out a revised standard
that included structured recipients in the not too distant future.
(What was too late was when I started phoning them.  Previously I
had confined myself to using network mail, which is considerably
worse for the task, as I found out).

Now a lot of time has gone by with no such revision, and I am told
that to change now would require people to change the changes they have
already made, thus wasting their previous efforts.

This is peculiar, because the person telling me this is the very person
responsible for making things happen that way.  A year ago, some CAHCOM
people asked me to be patient and accompany them down the wrong road
for a little while until they turned back;  now, the othr CAHCOM person
tells me that we have been going that way too long to turn back.
This is a cheap swindle which I am not going to be moved by.

DCrocker speaks of short-term vs. long-term goals.  This is distinctly
different from what I was told back then, though superficially similar.
Perhaps he and the rest of CAHCOM were agreeing on two different things.
In any case, given that he agreed that structured recipients were ultimately
desirable, his belief that they ought to be delayed was a mistake, pure
and simple.  It is always easier to do a change along with ten other
changes than to do it by itself, and this particular change was just a
fraction of the changes that 733 ended up asking for.

But this mistake was just an extension of an earlier wrong decision:
that there should be an "interim" revision for the present, because
the ultimate protocol of the future would be too far to aim for.
This was based on a mistaken idea of what that ultimate should be:
that it would be something very different from anything now in use
in Arpanet mail - some mysterious non-ascii representation.
This is the fundamental error, because text that is both human-
readable and machine-readable is the ideal way for diverse systems
to communicate, superior in robustness and the equal of any
other scheme in flexibility.  In fact, the ideal protocol would
not be fundamentally different from 733.  It would just involve
a few extra features and escapes added in at the fringes.
And the most prominent one, the one which is best known already
to be useful, is our friend the structured recipient.
If CAHCOM hadn't decided to put off structured recipients till
the ultimate future, the ultimate future would be here today.

Concerning the suggested syntax
  Mailing-list<:list:(bug mailer@mit-ai,"(bug mailer)"@mit-ai>,
I doubt that we will adopt it in preference to just (bug mailer)@mit-ai,
which is much simpler and easier to read.


Date: 21 Dec 1978 2201-EST
From: SANTA at BBN-TENEXA
Subject:   A Very Merry Christmas
To:   Good little girls and boys:


Near the end of 4th quarter
	comes a wonderful season,
With long range projections 
	and exchange without reason.

But in case you've forgotten
	to tell Santa your dream,
Or your wife and child must have 
	just one more machine...

This year Santa's prepared
	for the last-minute rush,
With electronic mail, 
	only buttons he'll push.

His "office of the future"
	is equipped to the hilt,
Now that TRS-80's and 
	Qyx must be built.

If your TI's at home and
	your children are curious,
Tell them Santa's responding
	to those who send mail to us.

From the Guttenberg Galaxy
	Santa sends you his best,
May Christmas bring you peace,
	prosperity and rest.


Rudolph T.R.N. Reindeer

R.S.V.P.
-------

Date:     6 January 1979 0058-est
From:     Robert M. Frankston      <Frankston at MIT-Multics>
Subject:  Electronic Office of the Future/MIT Seminar
To:       header-people at MIT-MC


The following wound up in my mailbox via the AI-Folks
distribution list at BBN.  Thought that some of the header people
might be intersted and may have missed learning of this from other sources:

Lyn:
	Could you please post this announcement at BBN?

		Thanks!

		Carl




              Electronic Office of the Future
                        January 8-12
                         NE43-512A


        An integrated series of seminars will explore issues
in the design  and implementation of the  "electronic office
of the future."  The subject is not hardware or software per
se.  It  is the information  systems used by  office workers
and  how  these  systems  can  be  observed,   modeled,  and
transformed  in   a  new  technological   environment.   The
activity  will consist  of lectures,  discussions,  and work
sessions  led by  researchers from  universities, industrial
research laboratories, and consulting firms.   Enrollment is
limited.  Regular attendance is preferred.

                      Monday January 8
10:00  "Welcome and Preview"
                Carl Hewitt, M.I.T.
 1:00  "The Office--An Interactive Highly Parallel System"
                Clarence Ellis, Xerox PARC
 3:00  Demonstration of Prototype Systems

                     Tuesday January 9
10:00  "Database Alerting and Corporate Memory"
                Howard Morgan, Wharton
 1:00  "A Research Program in Office Automation"
                Michael Hammer and Mike Zisman, M.I.T.
 3:00  "Modeling and Measuring Automated Information Systems"
                Gary Nutt, Xerox PARC



                    Wednesday January 10
10:00  "Office Scheduling and the Production of Documents"
                Jack Buchanan, Harvard
 1:00  "Behavioral Characterizations of Office Systems"
                Carl Hewitt, M.I.T.
 3:00  Demonstration of Prototype Systems

                    Thursday January 11
10:00  "Campus Communication Networks in the 80's"
                Joe Garber, Booze-Allen and Hamilton
 1:00  "Future Modes of User Interaction"
                Panel Discussion
 3:00  To be Announced

                     Friday January 12
10:00  To be Announced
 1:00  "Social Implications of the Electronic Office of the Future"
                Panel Discussion


          --------------------
End forwarded message




Date: 8 JAN 1979 1656-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: News item
To: Header-people at MIT-MC

I thought the following message would be of interest to the
header-people group in general, so am passing it on.
                -------------

Date:  3 Jan 1979 1147-PST
From: GUERNYLUSBY at USC-ISIE
Subject: mtg on message service support
To:   cerf at ISI, carlson at ISIA, myer at BBN, jhaverty at BBN,
To:   bthomas at BBN, farber at ISI, dcrocker at ISI,
To:   pool at BBN, cianflone at BBN, lyons at ISI,
To:   dcacode535 at ISI, cohen at ISIB, postel at ISIB,
To:   av at MIT-DMS, phw at MIT-AI, craighill at SRI-KL,
To:   anderson at RAND-UNIX, wactlar at CMU-10A,
To:   rothnie at CCA-TENEX, mills at ISIE
cc:   adams, adams at ISIA, russell at ISIA


On 10 January 1979 we are holding a meeting at BBN in Cambridge, MA, 
starting at 0930, to discuss Message Service support on the ARPANET.  
The purpose of the meeting is to provide a basis for any standardization
of efforts which may be necessary.  We will take stock of the various 
message services currently available on the ARPANET, discuss problems 
which have been encountered between different message systems, review 
current protocols and review forthcoming developments.  An agenda is 
given below.  Each of you should be prepared to discuss current problems
you are aware of and any developments which will impact future message 
service.
                              AGENDA
1. Present State of Affairs
   o  Survey of Message Systems
   o  Current Problems
   o  Format Protocols - RFC 560, 680, 733
   o  Distribution Service
   o  Documentation
2. Future Developments in Message Technology
   o  Multi-Media Techniques
   o  Impact of Personal Computers
   o  Distributed Service
      -  NSW Project
      -  Internetwork Addressing and Forwarding
   o  Other
3. Impact of Changing Technology on the Message Service
   o  Protocols
   o  Distribution of Messages
4. Managing the Message Service
5. Supporting the Message Service
LtCol Duane Adams
DARPA/IPTO
-------


Date:  12 January 1979 01:01 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Dynamic addressing for intrnetworking
To:  header-people at MIT-MC
Message-ID:  <790112060127.242412 at MIT-Multics>
Message-ID:  <790112060144.214972 at MIT-Multics>


I am trying to solve a very specific problem.  Given  a  host  on
one  network  (such  as  the  Arpanet)  that is also connected to
another net.  How can messages be sent  via  this  interconnected
host  to  a user on the second net.  The other hosts on the first
net need not even be aware of the existance of  the  second  net.
In  fact,  the interconnecting host need not even be aware of the
existance of the second net!!!

I am not trying to add this conditions to be  difficult,  I  have
described  a  real  situation that occurs when a nondistinguished
process  on  the  interconnecting  host  does   the   forwarding.
Specifically,  I  may be using the interconnecting host as a mail
drop and my computer would dial in once a day and exchange  mail.
Farber  is already doing this at the University of Delaware.  The
primary requirement is that there be a syntax for  specifying  an
address  that  has  two  parts, the first part corresponds to the
Arpanet mailbox address that is currently  in  use.   The  second
part  has  information to be used only by the second network.  We
can observe that this  is  identical  to  the  two  part  address
already  used,  one part is the host name that specifys where the
mail is to be sent and the second part is a  name  fo  local  use
withhin the next host.  We can simply extend this syntax to allow
what is in effect a path through the net.  Thus one can specify:
 Frankston@Multics
 in the current protocol.  This would be extended to :
 Frankston@Bobs_net@Multics.
 Where Bobs_net would be a mailbox on Multics  that  my  computer
can check periodically.  For the LCS network, one can have:
 Frankston@LCS_net@MIT=MC.
 In this case, it would be most likely that LCS_net is a  process
giving immediate response.

 this is a minimal extension to  the  current  syntax.  The  only
requirement  on  senders  is that the parse for the @ (or " at ")
from the right.  There are two requirements on receivers.   First
they  need  to  parse  for  a  second @ to find the mailbox name.
Secondly they should insert, at the beginning  of  the  letter  a
"recipient:"  field  that  specifies the recipient name (possibly
with the last @Multics or whatever stripped off)  that  was  used
for  FTP so that the next network can continued to forward to the
specific recipient.

The drawback to this scheme is that  it  requires  chanes  to  th
senders  and  receivers.   But,  it  can be introduced gradually.
Though of course,  mail with ext4e4ended addresses  can  only  be
exchanged between hosts implementing the protocol.

I have not addressed all the issues of human  interefacing,  such
as hiding long and complicated pathnames from naive users.  It is
a  mistake  to  try  to  solve  that  at this level.  That is the
responsibility of aliasing and directory schemes.  For example, I
can have mail at ITS  (assuming  ITS  implements  this  protocol)
translated  from  "RMF@MIT-MC" to "Frankston@Bobs_net@Multics" so
that I can still receive mail from unmodified hosts and so as not
to burden a sender with a long pathname.  A less frequent user of
Arpanet mail might not setup an abbreviation, but would require a
full pathname.  That is  the  way  itmust  be  since  one  cannot
preregister  all  possible  recipients  in  the world.  Even less
likely is the registration of all processes  that  might  receive
mail.   We  cannot even predict which networks will exist since a
network can be created by any computer with access  to  the  dial
phone network and the ability to login to another host.


Date:  12 January 1979 01:03 est
From:  Frankston.Frankston at MIT-Multics
Subject:  via
To:  header-people at MIT-MC
Message-ID:  <790112060356.354291 at MIT-Multics>

It would be a good practice for mail servers to prefix received letters with a "via:" that specifies the host from which the letter was received.
This would aid in attempts to provide secure mail services.
The security is relative to one's trust of the previous handler.

Date: 12 JAN 1979 0128-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

I would like to second RMF's suggestion
but there is no need at all to specify what any receiver should
do on receiving a message address to FOO@BAR@RECEIVING-SITE.
This is only meaningful in whatever ways RECEIVING-SITE
thinks it is.  Machines that don't connect to anything but the
arpanet need not understand it at all in that context.
Machines that do have other nets to forward onto can do things
in a much better way than the way RMF suggests:  just mail the
thing off to FOO@BAR.  BAR will be able to process this in
the usual manner because he is told, at sending time, about FOO
just as when anyone on RECEIVING-SITE mails to FOO@BAR.

However, there is the problem that the From: will be
MUMBLE@OTHER-SITE, which might be meaningless to BAR
since they are not on any common network.  This can be
solved by adding "Via Gateway: RECEIVING-SITE" to the
front of the message.  Then FOO@BAR's automatic reply
program can take the From: and add "@RECEIVING-SITE" to it.
If there are several Via Gateway: fields then they must
be put on first one outermost.

To sum up, only mail sending systems need to be changed
to implement this, except on machines that are actually gateways.


Date:  12 January 1979 01:52 est
From:  Frankston.Frankston at MIT-Multics
Subject:  More on addressing
To:  header-people at MIT-MC
Message-ID:  <790112065239.985901 at MIT-Multics>

1> in reply to RMS, a slight correction, a message to FOO@BAR@RECEIVING-SITE will be forwarded
to BAR, not FOO@BAR.  This is necessary since only BAR is a known name at the host,  It is BAR itself that understand7s foo.

2. If we want to be even more compatable, we can use some character other than ! for the second level of pathnames.
Thus one can send mail to FOO!BAR@RECEIVING-SITE.  This has the advantage of not requiring modification
to senders.  It has the disadvantage that it does not nest well.  i.e. only works for one level.
For the moment, however, receivers understanding multinetting can process ! as a @ and old sites treat it
as an alpha thus requiring only sites interested in the protocol need be modified but all sites will
gain immediate acess to inernetting

Date:  12 January 1979 01:54 est
From:  Frankston.Frankston at MIT-Multics
Subject:  typo
To:  header-people at MIT-MC
Message-ID:  <790112065455.726813 at MIT-Multics>

I mwant to say:
2. If we want to be even more compatable, we can use some character other than "@", such as "!".

From: Dcrocker at Rand-Unix
Date: 11 Jan 1979 at 2308-PST
Message-Id: <[Rand-Unix]11-Jan-79 23:08:17.dcrocker>
To:  Frankston.Frankston at MIT-Multics
cc: header-people at MIT-MC
Subject: Re:  Dynamic addressing for intrnetworking
In-reply-to: Your message of 12 Jan <790112060127.242412 at MIT-Multics>

First of all, with all due modesty, I would like to correct your
attribution of our current use of Inter-net mail.  We, at
Delaware, are entering the initial experimentation phase (read:
we are working on transmitting the first message) of our "remote
mailer" system.  Granted, the difference between that and utility
is likely to be less than a week.  However, from the vantage
point of my current activity, that counts as a lot to me.

Minor point:  Vint Cerf, at Arpa, has suggested that the term
"gateway" be reserved for very low level network interfacing for
such functions as packet format transformtion.  The term "Mail
Forwarder" though not as sexy, has been suggested for this
context.

Now much more to the point, I think your and Stallman's
suggestions are excellent.  In fact, I think they are so good,
that I would like to recommend that the two of you read RFC #733,
the syntactic definitions of host-phrase and host-indicator in
Section III.E (page 15) and the semantic description in Section
IV.A.f (pp. 19-20).  I fail to see how your basic suggestion
differs from what is already in the standard.

Standardizing on the field-name "via:" seems quite reasonable to
me.  I have currently had our system adding it to a general-
purpose "Source-Info" field, but like factoring out the
information.

About two days ago, the problem of the From field struck me.  A
(very) short-term seems to be to take advantage of the fact that
systems are currently used to having NO hostname in the From
field.  A longer-term approach (still not optimal) is to have the
From field reflect a back-path for the recipient.

"Via gateway" requires that all receiving sites know how to use
that field.

In general, it seems to me that you can take a path or a location
approach to addressing.  The path approach should require no
knowledge on the part of the recipient, to be able to formulate a
reply.  The location approach ("London England", rather than
"dial <London England's telephone access code> ..." or "go to
L.A. Airport and take flight xxx") requires that the recipient
have some general world (inter-net) knowledge, at least to the
level of knowing about mail forwarders.  The "Via gateway" field
would be useful in the latter case, I should think.

---

Now that I have tried to make this note constructive, I would
like to comment on my feelings on having spent more than a year
in a group effort to produce a standard which has been repeatedly
criticized by participants of the process, only to discover that
they apparently have not bothered to become familiar with that
standard:  I bloody well do not like it, and I'm very glad that I
had to type this note, rather than generate my words during an
immediate reaction in a meeting.  The vocabulary would have been
quite different.

Doesn't help your credibility much, either, guys.

---

Dave.

Date: 12 JAN 1979 0211-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

Ok, I see what RMF means, but again that applies only to those
hosts that want to be able to accept mail for FOO@BAR@HOST
with BAR being a user at HOST.  I'm sure most hosts won't
be interested and they will not have to be changed; and only
HOST (and BAR's dialup program) have to know exactly how
HOST deals with such messages.

Please don't saddle us with any crock like FOO!BAR@RECEIVING-SITE.
Defining FOO@BAR@RECEIVING-SITE won't screw anybody, in the
sense that people who don't convert will not have
any problems communicating with the hosts they now communicate with.
Those hosts that want to send mail to other nets will hack this
trivial hack.  Those that don't care, won't.


Date: Friday, 12 Jan 1979 0300-EST
From: Brian Reid at CMU-10A
Subject: Re: More on addressing
To:   header-people at MIT-MC
Message-ID: <12Jan79 030044 BR10@CMU-10A>
In-Reply-To: <790112065239.985901 at MIT-Multics>

Isn't this what
        "Foo@Bar"@Mit-MC
was supposed to be for?

Date: 12 JAN 1979 0251-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC


DCrocker, I don't know whether you were at the meeting on Wednesday,
but although I walked in thinking that FOO@BAR@BLETCH was part
of the standard, nobody else there (including those who "ought"
to know" seemed to think so, and the idea was so controvercial,
that I and RMF walked out thinking that we had to push for it very hard.


Date: 12 JAN 1979 0607-PST
Sender: FARBER at USC-ISI
Subject: Re: More on addressing
From: FARBER at USC-ISI
To: reid at CMUA
Cc: header-people at MIT-MC
Message-ID: <[USC-ISI]12-JAN-79 06:07:14.FARBER>
In-Reply-To: <12Jan79 030044 BR10@CMU-10A>

Ah yes that is what foo@bar@mit-mc was supposed to do.  The
reaction to that notation by many ( including some who can
control such things) is not allowed to be put in print.

While its somewhat of a taste problem, it is essentailly
unacceptable as far as I can tell.  Note I am reporting not
necessarily stateing my opinion.

Dave

Date: 12 JAN 1979 1215-EST
From: MOON at MIT-MC (David A. Moon)
Sent-by: MOON5 at MIT-MC
Subject: Transfinite flaming about internet addressing
To: HEADER-PEOPLE at MIT-MC

An excellent application for structured-recipient syntax.

Date:  14 January 1979 17:44 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Friendly user @ hosta @ local-net1 @ major-netq
To:  header-people at MIT-MC
Message-ID:  <790114224425.907140 at MIT-Multics>

My original intent at the Wednesday meeting was  to  ask  whether
the  "foo  at  bar at nethost" syntax was valid.  A simple yes by
anyone present would have sufficed to answer my question and  Tom
Knight's  request  for  an  acceptable  syntax.   In any case, as
Dcrocker points out, "foo at bar at nethost" is in the standard.

The question now is, which mail servers  can  currently  properly
process  this  form  of an address?  And also, which mail sending
programs permit it?

In RFC 733, the example is "Friendly User @ hosta @ local-net1  @
major-netq".   The  assumption  is  that  major-netq  knows  that
local-net1 is a net  and  will  thus  be  able  to  pass  on  the
recipient  name in addition to the text of the message.  In order
to allow local-net1 to be a nondistingushed user on major-netq it
is necessary to have a mechanism such as the "recipient:" as I've
proposed.

I realize that there are many  more  issues  involved,  including
those  of  taste.  I am not addressing those -- they are related,
but separate issues.

From: Kiessig at Rand-Unix
Date: 15 Jan 1979 at 1606-PST
Message-Id: <[Rand-Unix]15-Jan-79 16:06:44.kiessig>
To: header-people at MIT-MC
Subject: Re:  Friendly user @ hosta @ local-net1 @ major-netq
In-reply-to: Your message of  14 January 1979 17:44 est.
              <790114224425.907140 at MIT-Multics>

After reading  over  a  dozen  messages  on  this  local  network
recipient problem, it seems to me that you people are approaching
it in the wrong way.  Shouldn't the  ARPAnet  host  be  the  ONLY
machine  which  knows  about  "hosta  @  local-net1"?   The  mail
receiver should easily be able to  determine  which  users'  mail
must  be  sent  out  over  the local net(s).  Hence for the above
example, "Friendly user @ major-netq"  should  be  all  you  need
specify.   "Foo  at nethost" seems much more reasonable than "Foo
at bar at nethost".

The problem with this scheme  could  be  in  adding  the  "From:"
field.  Perhaps  only  the host which actually sends the mail out
over the ARPA network should add in the host name.

Using this method, only the machines  that  actually  have  local
nets  need  make any changes to their software.

Date:  16 January 1979 03:58 est
From:  Frankston.Frankston at MIT-Multics
Subject:  For the doezenth time.
To:  kiessig at Rand-UNIX
cc:  header-people at MIT-MC
Message-ID:  <790116085811.144562 at MIT-Multics>

One cannot abbreviate "For at bar at nethost" as "Foo at nethost"
because "nethost" is utterly unaware of the existance of "foo". 
Furthermore, there may be a "Foo at bar" as well as a "Foo at Foo".. 
Not only that, "nethost" doesn't even know that "bar" represents a host
instead of simply being another user on "nethost".


Date:     Tue, 16 Jan 79 12:14-EST
To:       Header-People at Mit-MC
From:     Dcrocker at Rand-Unix
Subject:  RFC 733 Parsers

Does anyone have code for a parser and data-manager (the thing that
manipulates whatever structure you produce after the parse)
that they would be willing to share?

Dave.

Date: 19 Jan 1979 2059-PST
From: Tovar <TVR at SU-AI>
Subject: Inter-networking   
To:   Header-People at MIT-MC    


   As i see things, there are two issues being addresses here:  (1) how
to send, and (2) how to reply.
   I would first like to address the issue of how to send.  One suggestion,
"Smith@MSR"@MIT-XYZ has two strikes against it.  First, it looks ugly.
Second, it does not nest well.  That is, if another level of indirection
is necessary, how are more quotes going to be added and if so, what hope
is there for readability?
   Secondly, there has been some suggestion, which i do not completely
understand, that at least some '@ something' can be removed from a
construct like 'Friendly name @ hosta @ local-net1 @ majornetq'.  In
some instances, that is true, just as it is in the U.S. Postal Service,

			Tovar
			A.I. Project
			Stanford, CA 94305

not only works, but gets there faster than the official address of

			Tovar
			Artificial Intelligence Project
			Computer Science Department
			Stanford Universiy, Stanford CA
						94305

While if i tried to do something like that at UCSB, i'm afraid there
would be little hope, just as if i tried to send mail to

			John Smith @ IBM-Net @ CommercialNet
or
			John Smith @ Louisville @ CommercialNet

This, of course, assumes that everyone knows how to, and can legitimately
send messages to, CommercialNet.
   There are some additional problems besides trying to get unique
addresses.  If you think we have trouble keeping host tables up-to-date,
try adding how to get onto other networks.  If you think we have trouble
keeping host tables up-to-date, how about other networks that may well
be more informal, or may actually change dynamically.
   At least until and if there comes about a widely accepted, and
when i mean widely accepted, i mean in most accessable networks, i think
the safest and most reasonable thing is to let the user specify the
pathname and let each 'link' process what it understands or else complain.

   Or else complain?  This brings me to part 2 of this verbose note.  That,
is, complain to whom?  And how.  I would like to point out that in handling
a piece of mail, in general, one level of host/network addressing will be
stripped off the 'To:' field before passing it on to the forwarding entity.
This information will be lost unless we provide somewhere else to store it,
such as a 'Via:' field.
   It could be argued that the 'Sender:' or 'From:' field could contain a
full return address.  However, it's going to be a problem for an
intermediate site to decide where in the full return address to start, in
order to tell the Sender that (s)he lost.
   However, i would suggest saving the information stripped off by a
forwarding be inserted at the beginning of the 'Via:' field.  Then, assuming
all paths are bi-directional, the 'Via:' field would describe the path back
to the sender during and after transmission.  Question:  Is the assumption of
bi-directionality a reasonable one?
   Thus, i see the 'Via:' field serving several purposes.  It provides a
trace of where a message has been, to aid the human in chasing down problems.
It provides the human recipient with a path to send a return message.  It
also provides the mail-reader with a path to send a return message.  And it
provides a simple path back for the forwarding sites in case errors are
discovered along the way, like 'no such mailbox' or 'no such site'.

   I would like to remind people that whatever we do here is likely to
be copied by other networks, especially if such networks would like to
communicate smoothly with users of this network.  I believe it is to our
indirect benefit to make our protocols usable and acceptable to other
networks, even if this means we have to think a lot harder about issues
which do not directly affect us, and consider networks which may be
either more ephemeral or more rigid than our own.

								--- Tovar

To DCrocker:  Please excuse me if i'm not up-to-date on all the details of
RFC 733. I've been rather busy making sure i can pay the rent, so to speak.



Date: 19 Jan 1979 2101-PST
From: Tovar <TVR at SU-AI>
Subject: Inter-networking   
To:   Header-People at MIT-MC    

Inter-networking

   As i see things, there are two issues being addresses here:  (1) how
to send, and (2) how to reply.
   I would first like to address the issue of how to send.  One suggestion,
"Smith@MSR"@MIT-XYZ has two strikes against it.  First, it looks ugly.
Second, it does not nest well.  That is, if another level of indirection
is necessary, how are more quotes going to be added and if so, what hope
is there for readability?
   Secondly, there has been some suggestion, which i do not completely
understand, that at least some '@ something' can be removed from a
construct like 'Friendly name @ hosta @ local-net1 @ majornetq'.  In
some instances, that is true, just as it is in the U.S. Postal Service,

			Tovar
			A.I. Project
			Stanford, CA 94305

not only works, but gets there faster than the official address of

			Tovar
			Artificial Intelligence Project
			Computer Science Department
			Stanford Universiy, Stanford CA
						94305

While if i tried to do something like that at UCSB, i'm afraid there
would be little hope, just as if i tried to send mail to

			John Smith @ IBM-Net @ CommercialNet
or
			John Smith @ Louisville @ CommercialNet

This, of course, assumes that everyone knows how to, and can legitimately
send messages to, CommercialNet.
   There are some additional problems besides trying to get unique
addresses.  If you think we have trouble keeping host tables up-to-date,
try adding how to get onto other networks.  If you think we have trouble
keeping host tables up-to-date, how about other networks that may well
be more informal, or may actually change dynamically.
   At least until and if there comes about a widely accepted, and
when i mean widely accepted, i mean in most accessable networks, i think
the safest and most reasonable thing is to let the user specify the
pathname and let each 'link' process what it understands or else complain.

   Or else complain?  This brings me to part 2 of this verbose note.  That,
is, complain to whom?  And how.  I would like to point out that in handling
a piece of mail, in general, one level of host/network addressing will be
stripped off the 'To:' field before passing it on to the forwarding entity.
This information will be lost unless we provide somewhere else to store it,
such as a 'Via:' field.
   It could be argued that the 'Sender:' or 'From:' field could contain a
full return address.  However, it's going to be a problem for an
intermediate site to decide where in the full return address to start, in
order to tell the Sender that (s)he lost.
   However, i would suggest saving the information stripped off by a
forwarding be inserted at the beginning of the 'Via:' field.  Then, assuming
all paths are bi-directional, the 'Via:' field would describe the path back
to the sender during and after transmission.  Question:  Is the assumption of
bi-directionality a reasonable one?
   Thus, i see the 'Via:' field serving several purposes.  It provides a
trace of where a message has been, to aid the human in chasing down problems.
It provides the human recipient with a path to send a return message.  It
also provides the mail-reader with a path to send a return message.  And it
provides a simple path back for the forwarding sites in case errors are
discovered along the way, like 'no such mailbox' or 'no such site'.

   I would like to remind people that whatever we do here is likely to
be copied by other networks, especially if such networks would like to
communicate smoothly with users of this network.  I believe it is to our
indirect benefit to make our protocols usable and acceptable to other
networks, even if this means we have to think a lot harder about issues
which do not directly affect us, and consider networks which may be
either more ephemeral or more rigid than our own.

								--- Tovar

To DCrocker:  Please excuse me if i'm not up-to-date on all the details of
RFC 733. I've been rather busy making sure i can pay the rent, so to speak.



Date: 20 Jan 1979 0903-PST
From: Mark Crispin <MRC at SU-AI>
Subject: multi-networking   
To:   Header-People at MIT-MC    

Well, in the "ideal" implementation everybody would know about everybody's
network and how to get the message there.  Hair in routing is possible too;
it could know that there are several different ways with different costs,
and it can make an intelligent assessment of what would be the "best" way
(otherwise it could guess randomly).  Hence, "MRC@SU-AI" would work from
anywhere, regardless of whether or not the sending host has any direct
network connection to SAIL.

Of course, this is pie in the sky, but I feel it is the "right" way and
it's important that nothing be done to prevent this way from eventually
being implemented.  Of course, this will happen in a future time, when
everybody is using the same design hardware, the same operating system,
there is peace on earth, good will towards (wo)men, and a cure is found
for the common cold...

Until then, it seems that the suggested foo@bar@bletch@garply@mumble is
good enough, unless some hair needs to be stuck in for MIT's structured
recepients or whatever.  It has the gross disadvantage in that implicit
to this scheme is a fixed method of routing--I would have to be a smart
mail program indeed to know that the bar that I can get to by going through
bletch and garply is the same bar that I (mumble) have a direct link to
that the sender didn't know about!

A final note: isn't it a reasonable assumption that a participant in
inter-network mailing will be reasonably sophisticated, presumably enough
to be part of a single community with one meta-host-table?  If so you
can have your pie in the sky and eat it too (I like pumpkin myself, but
we bake apple and cherry too...).

-- m



From: Dcrocker at Rand-Unix
Date: 23 Jan 1979 at 1557-PST
Message-ID: <102.285983854@Rand-Unix>
To: Header-People at MIT-MC
Subject:  Modifications to RFC 733

Three things.

1.  As a reminder, the official spec was modified some time ago to
    make group "names" required and no longer optional, for group
    lists.  Syntactically, this changes "[phrase] ':' #address ';'" to
    be "phrase ':' #address ';'".  This was done to resolve a parsing
    abiguity pertaining to the use of colons.

2.  I would like to solicit opinions about imposing the same
    requirement on individual address lists, changing
    "[phrase]" '<' #address '>'" to be "phrase" '<' #address '>'".
    The only justification would be to make it consistent with
    the group list style.  Do any of you care if it is
    consistent or do you care if it is not?

3.  More important:  Currently, group and individual lists have
    a syntactic distinction, but no semantic one.  The semantics
    are that ALL mailboxes in the address list (#address) are
    to be referenced (e.g., receive copies of a reply).

    I would like to change that so the semantics for
    groups remain the same but for individuals it becomes
    ANY ONE OF the members of the list MAY be referenced (tho
    using more than one would be legal).  The justification
    is the presumption that the typical need by the individual
    will be to ensure that at least one copy gets through to
    one of his/her mailboxes, rather than worrying about
    getting them to all of their mailboxes.  In the (presumed)
    unusual case that the individual wants a copy in all
    mailboxes, they may use the group syntax.

    Again, do any of you care?  Why?  I feel rather strongly
    that the change should be made and would like to
    hear arguments in either direction.

My general justification for requesting the change in #3 is some of
the recent discussions we've had seemed to me to point up the need.  I
also presume no one would have to recode on the basis of the change.

Thanks.

Dave

Date: 24 Jan 1979 0603-PST
From: Zellich at OFFICE-1
Subject: Re:  Modifications to RFC 733
To:   Dcrocker at RAND-UNIX, Header-People at MIT-MC
cc:   ZELLICH

In response to the message sent 23 Jan 1979 at 1557-PST from Dcrocker@Rand-Unix

Whether a "phrase" is specified or not for an individual address (list)
seems to be more a matter of personal style of the sender, and shouldn't
really matter to any header-parsing program...The program will
just scan looking for a "<" and ignore anything found to the left if
the "<" is found.  I think it should be left as is.

I don't quite understand the proposed semantic change for the individual
lists - who/what decides which member(s) get referenced?  If the sender
is trying to assure that at least one copy gets through, s/he must
have some suspicion that some supposedly-functioning mail mechanism is
not really working somewhere.  A host can indicate that it received and
delivered the mail, and still fail to actually deliver it to the
intended recipient [in readable form].

Rich
-------

Date: 30 JAN 1979 1931-EST
From: RMS at MIT-AI (Richard M. Stallman)
Subject: Peculiar header
To: header-people at MIT-MC

    
    Date: 29 Jan 1979 2238-PST
    From: Bair at SRI-KL (James Bair)
    Subject: Workshop on Human-Computer Communication
    To:      DIST2:, To:, To:, To:, To:, To:, To:, To:, To:, To:, To:,
    To:   To:, To:, To:, To:, To:, To:, To:, To:, To:

Neat, eh?


Date: 30 Jan 1979 1642-PST
From: McLure at SRI-KL (Stuart McLure Cracraft)
Subject: Re: Peculiar header
To: RMS at MIT-AI, header-people at MIT-MC
In-reply-to: Your message of 30-Jan-79 1631-PST

That seems to have been caused by a file containing things like
	DIST2: foo@bar, foo1@bar, to: foo3@bar, to:foo4@bar, etc...
	ad infinitum.
-------

Date: 31 JAN 1979 0902-PST
Sender: FARBER at USC-ISI
Subject: Re: Peculiar header
From: FARBER at USC-ISI
To: McLure at SRI-KL
Cc: RMS at MIT-AI, header-people at MIT-MC
Message-ID: <[USC-ISI]31-JAN-79 09:02:45.FARBER>
In-Reply-To: Your message of 30 Jan 1979 1642-PST

someone used the header from a message he received.  Lik

To: farber,smith To: jow,sam To: abe etc

guess what that gives!!

Dave

Date: 3 Feb 1979 1402-PST
Sender: FEINLER at SRI-KL
Subject: Who can shed some light?  Replies to david@UTEXAS, cc: Feinler@SRI-KL
From: FEINLER at SRI-KL
To: HEADER-people@MIT-MC
Cc: FEINLER
Message-ID: <[SRI-KL] 3-Feb-79 14:02:23-PST.FEINLER>


 9 Jan 1979 at 0913-CST *REF* david at UTEXAS:  Aborted Mail Messages
   Distribution:  FEINLER AT SRI-KL, david
   Received at:   9-Jan-79 07:23:43-PST
   Occasionally we receive aborted Arpanet mail messages.  This con 
   cerns  some  users,  who  fear  they are losing good messages.  I
   wonder if you could point me to information to help resolve  this
   concern.
   The messages are always 60-odd bytes long.  They come  from  dif-
   ferent  places,  as  indicated  by different header line formats.
   There is a header line, usually with just the date, and there  is
   a line saying "*** SENDER ABORTED CONNECTION ***".
   It is unfortunate that the header line has just the date.  I  no-
   tice that MIT-ML includes the name of the sender in that line, so
   one can identify the sender of an aborted message.  A  line  with
   just  the  date  is frustrating, because you don't know what hap-
   pened.  I wonder if it is worth  suggesting  that  other  mailers
   follow  the  practice  of putting the sender name and date in the
   header?  I don't know what mechanism  would  be  appropriate  for
   that suggestion.
   As far as I know, the messages are legitimately  aborted  by  the
   sender,  and  it  is not caused by a problem at our end.  But I'd
   like to know if anyone has more information on this.  Do  senders
   know  they  are  aborting the connection?  If it happens sometime
   later, do the senders get notified?  Can  one  safely  ignore  an
   aborted message and assume the sender will resend?
   I you would forward this to others who might be able to shed some
   light on my questions, I would appreciate it.  Thank you.
           --David M. Phillips     david@utexas


Date: Sat, 3 Feb 79 16:07-PST
Subject: Aborted mail
From: Greep at Rand-Unix
To: david at Utexas
cc: Feinler at Sri-Kl, header-people at Mit-Mc
Message-ID: <Greep.79.33.160742 @ Rand-Unix>
Reference: <[SRI-KL] 3-Feb-79 14:02:23-PST.FEINLER>

The "sender aborted connection" message comes from the Unix server
FTP and means that the socket was closed before receiving the line
begining with a period that is supposed to end the message.  There
are a number of versions of the Unix NCP floating around, some of
which are not especially reliable.  My guess is that your NCP is just
flaky for some reason.  If you want to get a little more information,
you can modify the server FTP to put a line at the beginning saying
what host the message is coming from (some systems to this), then
you might be able to find out something about the message from the
wizard at that host.  In any case the sending host should notice
the failure and try to resend the message later, or at the least
notify the originator of the failure.

Jake: seems this sort of thing is more appropriate for MsgGroup
than for Header-People.

Date: 4 FEB 1979 0752-PST
Sender: FARBER at USC-ISI
Subject: Re: Aborted mail
From: FARBER at USC-ISI
To: Greep at RAND-UNIX
Cc: david at UTEXAS, Feinler at SRI-KL, header-people at MIT-MC
Message-ID: <[USC-ISI] 4-FEB-79 07:52:09.FARBER>
In-Reply-To: <Greep.79.33.160742 @ Rand-Unix>

To the header-people list maintainers.

Greep had a good idea in creating yet another list that could be
used by people who have queryies pertaining to operational mail
system problems.  MSGGROUP is not right for bug problems.  There
is the wrong people on that list.  How about a msg-maintainers
mailing list.

Dave

Date:  4 Feb 1979 1314-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: More groups
To:   header-people at MIT-MC, greep at RAND-UNIX,
To:   david at UTEXAS, farber at ISI
cc:   klh, feinler

It was my understanding that Header-People was a group made up
of the mail maintainers around the network which was why I directed
the message to them.  MSGGroup always seemed to be a group that
talked more about the broad issues rather than specific implementation.
If Header-People is made up of the implementors already, it seems
redundant to start a group named MSG-Maintainers.  However, I am just
an observer of all these groups for the most part so these shouldbe
considered comments from the sidelines.  If another group is started,
may I please be added to the distribution list for information purposes.

Thanks,

Jake
-------

Date: 4 FEB 1979 1522-PST
Sender: FARBER at USC-ISI
Subject: Re: More groups
From: FARBER at USC-ISI
To: Feinler at SRI-KL
Cc: header-people at MIT-MC, greep at RAND-UNIX, 
Cc: david at UTEXAS, klh at SRI-KL
Message-ID: <[USC-ISI] 4-FEB-79 15:22:01.FARBER>
In-Reply-To: Your message of  4 Feb 1979 1315-PST

to risk just one more note.  is there anyone on header-people who
does not want to receive messages that deal with system
maintenance issues as opposed to protocol matters.

If you send me a note I will see if it warrants yet another list.

Dave

Date: Monday,  5 Feb 1979 0143-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: Aborted messages
To:   FEINLER at SRI-KL
CC:   David at Utexas, Header-People at MIT-MC
Message-ID: <05Feb79 014319 BR10@CMU-10A>
In-Reply-To: <[SRI-KL] 3-Feb-79 14:02:23-PST.FEINLER>

CMU has had trouble getting messages through to UTEXAS; I don't know
enough about the inner workings of our mailer to know just what the
problem is, but it's the only site on the network with which we have
had such trouble.  It ends up looking like a receiver timeout from
this end.

Date:  5 February 1979 11:11 est
From:  Pogran.CompNet at MIT-Multics
Subject:  David's problem
To:  David at UTEXAS
cc:  Feinler at SRI-KL, Header-People at MIT-MC
Message-ID:  <790205161122.292528 at MIT-Multics>

Looks like a good old-fashioned case of NCP/FTP bug to me.
I would suggest that the scenario is something like this:

The host wishing to xmit mail to UTexas issues an RFC on
the FTP data connection.  The UTexas NCP for some reason "doesn't see"
the RFC; could be that the FTP Server didn't tell it to expect
the connection, or didn't tell it soon enough, or gave the NCP worng
parameters for the socket & the NCP didn't reject the RFC, or whatever.
In any event, the UTexas NCP sends neither a matching RFC nor a CLS,
and after a while the other host times out and aborts the FTP Telnet
control connection, resulting in the "*** SENDER ABORTED ..."
message at UTexas.  The key to solving the problem would therefore
seem to be the UTexas NCP maintainers' discovering why the data-connection
RFC is not being fielded properly.

Secondary issue:  Some mailers use the FTP MAIL command, whhile others
use MLFL.  Most likely, this problem occurs with mailers that use MLFL.
I'll let you know wheter Multics, which uses MLFL, was able to send this
to UTexas successfully!

Ken Pogran

Date: Mon, 5 Feb 79 12:55-PST
Subject: Re: More groups
Subject:     Aborted mail
From: Greep at Rand-Unix
To: Feinler at Sri-Kl (Jake Feinler), FARBER at Usc-Isi
cc: header-people at Mit-Mc, david at Utexas, klh at Sri-Kl
Message-ID: <Greep.79.35.125552 @ Rand-Unix>
In-Reply-To: Messages of 4 Feb 1979 1314-PST by Feinler and
In-Reply-To: 4 FEB by FARBER <[USC-ISI] 4-FEB-79 07:52:09.FARBER>

Jake, maybe you are right.  I had thought that header-people was for
people interested in the specifications of mail headers, not implementations
per se.

In response to Dave's suggestion, maybe just a general Wizards group
is what is needed, similar to the liaison-group which now exists for
administrative messages (but is sometimes used for technical correspondence).

Date: Monday,  5 Feb 1979 1731-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: WIZARDS mailing liit
To:   Header-people at MIT-MC
Message-ID: <05Feb79 173148 BR10@CMU-10A>
In-Reply-To: <Greep.79.35.125552 @ Rand-Unix>

I think that a WIZARDS mailing list would be a good idea.
The Liaison list is not available to us mortals, and it reaches the
wrong kind of people.

Date: 5 FEB 1979 1820-EST
From: MOON at MIT-MC (David A. Moon)
Subject: David's problem (Pogran's theory)
To: Pogran.CompNet at MIT-MULTICS, David at UTEXAS
CC: HEADER-PEOPLE at MIT-MC, Feinler at SRI-KL

I'd tend to doubt it was a connection-establishment problem,
since supposedly the first line of the message header got through.

Date:  5 Feb 1979 1611-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: <netinfo>liaison-sndmsg.txt
To:   header-people at MIT-MC
cc:   feinler

This file is available for FTP from SRI-KL.  It is updated monthly
after I send out the monthly liaison list  (will be
current by Weds of this week).  Not all the Liaison are
software maintainers by a large portion of them are.  WIZARDS might
be a better idea.  This is just to let you know that the Liaison
distribution list is publicly available as advertised in the front
of all the NIC documents.  Word of caution - it contains well over 
100 names which makes queuing the message being sent almost
mandatory unless you want to tie up your terminal until this time
next Thursday.

Jake
-------

Date: 5 FEB 1979 1604-PST
Sender: FARBER at USC-ISI
Subject: Re: WIZARDS mailing liit
From: FARBER at USC-ISI
To: BR10 at CMU-10A
Cc: Header-people at MIT-MC
Message-ID: <[USC-ISI] 5-FEB-79 16:04:56.FARBER>
In-Reply-To: <05Feb79 173148 BR10@CMU-10A>

Does sound like a wizard list is "voted".  I submit dcrocker at
rand-unix, szurko at rand-unix, and farber at office-1 for the
Univ of Delaware offerings.

Dave

Date:  5 Feb 1979 1627-PST
From: McLure at SRI-KL (Stuart McLure Cracraft)
Subject: Re: WIZARDS mailing liit
To: FARBER at USC-ISI, BR10 at CMU-10A
Cc: Header-people at MIT-MC
In-reply-to: Your message of 5-Feb-79 1604-PST

Please include me on the list. Where will it be kept? on
one of the ITS machines .MAIL.;NAMES > or where? It should
definitely be publicly acessible to modification.
-------

Date:  5 February 1979 21:15 est
From:  Palter.PDO at MIT-Multics
Subject:  Re: Re: WIZARDS mailing liit
To:  McLure at SRI-KL (Stuart McLure Cracraft)
cc:  FARBER at USC-ISI, BR10 at CMU-10a, Header-people at MIT-MC
In-Reply-To:  Msg of 02/05/79 19:27 from McLure
Message-ID:  <790206021532.012895 at MIT-Multics>

Please include me on the list (for Multics).  You should also include
Greenberg@MIT-Multics in the list.  I think it should indeed be kept on
an ITS like Header-People as this allows for simpler modifications when
necessary

Date:  5 Feb 1979 1818-PST
From: McLure at SRI-KL (Stuart McLure Cracraft)
Subject: Re:  Re: Re: WIZARDS mailing liit
To: Palter.PDO at MIT-MULTICS
Cc: FARBER at USC-ISI, BR10 at CMU-10A, Header-people at MIT-MC
In-reply-to: Your message of 5-Feb-79 2115-PST

Who is going to implement this list? I suggest the person who first
recommended it.
-------

Date: Mon, 5 Feb 79 18:51-PST
Subject: Re: <netinfo>liaison-sndmsg.txt
From: Greep at Rand-Unix
To: Feinler at Sri-Kl (Jake Feinler)
cc: header-people at Mit-Mc
Message-ID: <Greep.79.35.185130 @ Rand-Unix>
In-Reply-To: Your message of 5 Feb 1979 1611-PST

The problem with using the liaison list (in addition it to not being
appropriate for this sort of thing) is that you can't just send mail to
it, as you can with lists like header-people. (I never understood why
this hasn't been implemented on tenex.)   Each person has to FTP
it himself, meaning outdated copies invariably spread around.
Also it assumes that every mail-sending program can read tenex-style
mailing list files.

Date: 5 FEB 1979 1909-PST
Sender: FARBER at USC-ISI
Subject: Re:  Re: Re: WIZARDS mailing liit
From: FARBER at USC-ISI
To: McLure at SRI-KL
Cc: Palter.PDO at MIT-MULTICS, BR10 at CMU-10A, 
Cc: Header-people at MIT-MC
Message-ID: <[USC-ISI] 5-FEB-79 19:09:35.FARBER>
In-Reply-To: Your message of  5 Feb 1979 1818-PST

Well I would be happy to do so but alas I dont have an account on
the ITS machine.

Dave

Date:  5 Feb 1979 2037-PST
From: Klh at SRI-KL (Ken Harrenstien)
Subject: "wizards" list
To:   Header-people at MC

I think Jake did the right thing in forwarding that note to Header-People.
The list was, in fact, intended originally to help work out the header
issues; however the approach used was that of trying to include all
the message system maintainers and work things out directly rather
than trying to penetrate through bureaucracy or liaisons.  I don't
know of any better forum for discussion of mailer problems in general,
because I certainly hope that the current list includes all such
maintainers.
   Whether more lists are necessary isn't clear to me.  It would be
nice to have similar lists for FTP and TELNET maintainers in particular,
since these along with mail seem to compose the bulk of any arpanet
interactions, but I'm not sure if this is what people are asking for.
Seems as if something as general as "wizards" is going to have as much
if not more randomness in its mail as Header-people does.  Perhaps
those who want other lists can be more specific about the kinds of
people they want on the list, and the kinds of messages to be sent?


(I also have the feeling that most people currently on the list
(whether "interested observer" or "mail maintainer") are going to
want to get in on a new list as well...)
-------

Date: Tuesday,  6 Feb 1979 0851-EST
From: Diana.Bajzek at CMU-10B (S300DB33)
Subject: Re: "wizards" list
To:   Header-people @ MC
Message-ID: <06Feb79 085152 DB33@CMU-10B>
In-Reply-To: Ken Harrenstien's message of 5 Feb 79 23:37

I agree with Ken, I think most of the people in Header-people would liketo
think of themselves as, and include themselves in "Wizards". But, if a new list
is built, include Bajzek@CMUB.
 

Date:  6 Feb 1979 0909-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: Re: <netinfo>liaison-sndmsg.txt
To:   Greep at RAND-UNIX
cc:   header-people at MIT-MC, FEINLER

In response to your message sent Mon, 5 Feb 79 18:51-PST

I certainly agree with you that TENEX and TOPS-20 should implement
being able to send messages to a group.  If this were availabl
then one could use all of the group distribution stuff the NIC maintains.
We (the NIC) spent a lot of time trying to make this happen around TENEX
but the effort became prohibitive in time and programming bucks
and we gave up.  I think this should be a feature of the Mail Protocol.
I would also point out that just because one can send a message to a
group (which by the way is a feature that has been available
in NLS for many years but does not extend to non-NLS users
unfortunately) does not insure that the group distribution list is
up to date, as indeed many of them are not.

Jake
-------

Date: Tue, 6 Feb 79 09:14-PST
Subject: Wizards mailing list
From: Greep at Rand-Unix
To: Header-People at Mit-Mc
Message-ID: <Greep.79.36.091442 @ Rand-Unix>

Since nobody is volunteering to maintain (or create) this list, maybe
someone at MIT will add a feature by which this can be done without
any manual intervention, e.g. sending a message of the form
  To: Mailing-list-updater@MIT-MC
  From: Foobar@Rand-Unix
  Add-to-list: Wizards-group
would automatically add "Foobar@Rand-Unix" to the "Wizards-group". ,
with a similar "Delete-from-list" field.  (The address to be added or
deleted would not necessarily have to be taken from the "From" field.)
I believe ITS already has provisions for incoming mail to invoke a
program.

Date:  6 Feb 1979 0940-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: Re: Liaison Mailing List
To:   FURST at BBN-TENEXB, Klh
cc:   FEINLER, header-people at MIT-MC

In response to the message sent 5 Feb 1979 2356-EST from Furst@BBN-TENEXB 

Sheldon,

Ken does not maintain the Liaison Mailing List.  It is maintained 
by the NIC as I stated in one of my previous messages.  For
quite a while it was on MC but was frequently out of date because
the maintainer there did not bother to get a new copy from the
NIC.  There are other more serious problems involved in having
the Liaison mailing list (or any really long mailing list) 
available  on a given host, and that is that that host is bombarded
by mail traffic that it may not wish to handle.  My own feeling is
that all mail hosts should be able to handle sending
messages to a group distribution list.  If the list is for local
consumption it would be maintained locally.  If it is global (i.e.,
netwide) it should be maintained by the NIC and the mailer would
first look for the list locally.  If not found, it would go
to the global data base and look for the distribution list and
upon finding it, send the message to the individuals included in
the list.  We are in the process of trying to make this happen by
redoing the data base so that it is more universally usable.  We do
maintain many group membership lists already.  The group distribution
lists are very fluid and really do require a maintainer...they don't
maintain themselves.  However, there is a lot of work needed
by way of standardizing mailers and redoing the protocol before what
I am suggesting is a reality.

Another issue that comes up is the one of 'junk mail'.  If the mailing
lists are really easy to use, they will be used by people who hve
very little to say as well as by those who have something useful
to say.  I frankly don't know the answer to this one.  Up until now
I think peer group pressure has been the best deterrent for junk
mail.  If someone sends a really idiotic message he/she usually hears
about it in no uncertain terms.  I suppose at some point the mailing lists
will be restricted to only those members included - that is an outsider
won't be able to send a message to a given group unless he gets himself
included in the mailing list or some such.  Guess I have reservations
about that, but can see it may get to be a matter of  self preservation
or maintaining ones sanity.

Have more to say on the matter of group distribution but this will suffice
to give a flavor of some of the problems and some of the potential
benefits.  Maybe we should open this up as a topic for discussion
some time.

Regards,

Jake
-------

Date: 06 FEB 1979 1843-EST
From: Joanne Sattley <JZS at CCA>
Subject: Re: Liaison Mailing List
To:   Feinler at SRI-KL, FURST at BBN-TENEXB, Klh at SRI-KL
cc:   Header-People at MIT-MC

In response to the message sent  6 Feb 1979 0940-PST from Feinler@SRI-KL 

-- here's a suggestion for an alternative method of handling group(s)
mail using the CCA Datacomputer's public message store.  It eliminates
the need for maintaining mailing lists & allows members to select the
junk and non-junk mail they wish to view.

A.  Composing the message

Group mail could be written using exactly the same programs as are being
used at present.  The subject-field, however, would need to contain some
group-identifying keyword: i.e., "liaisons", "wizards", "header-people",
"FTPers", etc. or combinations of keywords, in addition to the usual
subject information.  The message would be addressed to: "public@CCA".

At CCA, a mail-filing demon (aka MARS-Filer) would store the messages on
the Datacomputer;  they'd ordinarily be available for retrieval within
the hour -- but the period could be adjusted if people felt a lack of
freshness and spontaneity, both of which are desirable characteristics
of the current practice.

B.  Reading group mail

Anyone wishing to see mail of particular interest in one or more areas
would send a message to: "MARS-R@CCA" (or to "MARS-Retriever@CCA") with
the retrieval criteria in the body of the message.  E.g., to see mail
for wizards and TELNETii sent on the 6th of February:

TO:  public
SUBJECT: wizards,TELNETii
DATE: 6 Feb 1979

would do the trick.  Or, to get a week's worth of mail, e.g., last week's:

AFTER: 27 Jan 1979
BEFORE: 4 Feb 1979
TO: public

with SUBJECT: field specs as desired.  You'd need to say "wizards or telnetii"
to see mail which pertained to either one or the other, rather than both.

The requested messages are mailed out from MARS-Retriever; they'll appear
as new mail in the requester's message file.

The CCA programs to do this exist -- and run round the clock (although access
to the Datacomputer from 7 to 9 AM EST is restricted to staged data because
of PM).  Please feel free to give it a try.

--Joanne
-------

Date: 6 FEB 1979 1943-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: HEADER-PEOPLE at MIT-AI

I am sure that if I got a message I thought was losing
I wouldn't be satisfied with sending it to a retrieval
system from which the other recipients of the losing message
merely might retrieve it.  I would want to make sure that
I sent it to them and as soon as possible.


Date: Tue, 6 Feb 79 18:13-PST
Subject: Re: <netinfo>liaison-sndmsg.txt
Subject:     Liaison Mailing List
From: Greep at Rand-Unix
To: Feinler at Sri-Kl (Jake Feinler)
cc: header-people at Mit-Mc
Message-ID: <Greep.79.36.181359 @ Rand-Unix>
In-Reply-To: Messages of 6 Feb 1979 0909-PST by Feinler and
In-Reply-To: 6 Feb 1979 0940-PST by Feinler

I meant that it is easier to keep one list up-to-date than to keep
many lists up-to-date since usually there is one place maintaining
the list and there is no way to assure that updates to that copy
are reflected in other copies.

I see two practical problems with the scheme of having the sending
site automatically retrieve a mailing list each time it wants to
send mail to that list (in addition to the inefficiency of retrieving
it): (1) it would require a standard format for mailing lists
(I can just imagine the squabbles between the ITS and tenex people);
and (2) it requires a fair amount of inteligence in each host to
implement.  A further (although non-technical) problem is that it
would require each host on which mailing lists are kept to allow
access to those files by anyone.


Date:  6 February 1979 22:56 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re: Re: Liaison Mailing List
To:  Feinler at SRI-KL (Jake Feinler)
cc:  FURST at BBN-TENEXB, Klh at SRI-KL, FEINLER at SRI-KL, 
     header-people at MIT-MC
In-Reply-To:  Msg of 02/06/79 12:40 from Feinler
Message-ID:  <790207035647.348106 at MIT-Multics>

It is nice to find a concrete example that justifies my flaming.  The support of
mailing list servers is a prime example of the need for an ability to  extend
the ability to provide mail services from the operating system maintainers to users.

It should be possible for a user process to act as a secondary server for mail.
Thus:

 LIASON-LIST at LIST-SERVER at NIC

The above would appear in the recipient: field.
either periodically the user process would service the mailbox, or in fancier systems,
(such as ITS9 would wakeup automatically when there is mail waiting.

the point is that one should not have to be dependent upon the local diety for
new capabilities.

Date:  8 Feb 1979 1633-EST
From: MICHAEL SHAMOS at CMU-10A (C370MS20)
Subject: Are we professionals?
To:   header-people @ MIT-MC, msggroup @ USC-ISI
Message-ID: <08Feb79 163318 MS20@CMU-10A>

I am preparing some recommendations about professional certification
of computer scientists to a subcommittee of the American Bar Association.
Your ideas are important.  Please read the following material and mail
your carefully considered responses to SHAMOS@CMU-10A.


   The American Bar Association Section on Science and Technology has a
subcommittee on Responsibilities of Computer Professionals.  This
group is studying issues relating to recognition of professional
status for computer and data processing personnel.  Such recognition
would have advantages and disadvantages for us.  For example, licensing
laws and a code of professional conduct would seem to improve the
image of the profession and the quality of its output but such status
might at the same time impose legal liabilities and the spectre of
malpractice.  (A licensed systems programmer might be successfully
sued by a user who paid for his code if it were not properly
debugged.)  As is the case with all licensed specialties, this risk
of liability would be compensated for by higher salaries.
   I fear that the ABA may arrive at its conclusions by listening far
more to lawyers than to computer scientists.  It is important for
those with intimate knowledge of the field and the nature of our work
to provide input for the study.  I thus propose to send a document
to the chairman of the subcommittee with some ideas for consideration
and I would like them to represent the thinking of a sizeable group of.
us.  Will you please mail me your thoughtful opinions?  A copy of my
memo will be made public.  If you need someplace to start, consider
the list of issues below.
   Please note that the ABA has NOT set itself up as any authrity in 
this matter.  It will NOT dictate to the government what is to be done
about computer professionals.  It will make recommendations.  In the
absence of input from the computer science community these recommendations
are likely to be followed.  We surely want the initial reports to reflect
our considered views.

General
   What are the real aims of improving professionalism?  The good of
       mankind, or bettering our own lot?  If the public knew that its
       computer peple were guaranteed to be well-trained and accountable
       for their work, we might find greater acceptance of computers in
       general. 
   Are computer people really professionals?  (In this context a
       professional is one who by virtue of his special training and
       appreciation of ethical values is invested with special privileges
       and concomitant responsibilities.)  Do the people you know fit 
       this mold?  Is one a professional just because he can work
       miracles with monitor UUOs (i.e. has technical skills the layman
       lacks)?  The impetus for professionalization comes from the
       recognition that computer people can do a great deal of harm,
       both deliberately and innocently.  How can we assure the public
       that we are qualified to do the job and that we will be answerable
       for the consequences?

Certification
   Should computer scientists be licensed?  This would presumably
       mean the intrusion of a government bureaucracy and the imposition
       of standards by the legislature.  Some professional society would
       be designated to accredit individuals.  Some excellent hackers
       might be shortchanged if there are stiff formal requirements.
       See if you can suggest a certification procedure that would avoid
       this problem.
   Should there be a division into professionals and paraprofessionals?
       For example, licensed systems analysts assisted by unlicensed
       coders?  Would the professional take responsibility for the
       work of those under his supervision?

Role of academic departments
   Presumably certification will require some academic degrees and/or
       a licensing examination and/or stiff apprenticeship requirements.
       What role will academic computer scientists play?  Will we teach
       ethics?  Will academics be looked to for guidance in such matters?

Code of ethics
   Should professionals have to obey a code of responsibility?  Who
       would set up and enforce such a thing?
   Give some examples of suitable provisions.
   What would constitute a "disbarment" offense?  Remember that such
       a sanction would mean loss of livelihood for the individual.
   Would computer professionals be held to high abstract standards
       (e.g. "quality of life", "freedom from oppression", "preservation
       of the environment") or to the pragmatics of client representation
       ("do whatever your employer wants")?  Imagine that you have been
       hired to design a credit-reporting system?  The employer wants
       to include features that you regard as oppressive, such as the
       storage of unverified rumors about a customer's credit.  Are you
       obliged to implement them, or may you withdraw from the job?
       If you think that we must always stand up for the little guy,
       don't you think that the American system requires that business
       be represented too?
    Should there be a privilege of confidentiality between a computer
       professional and his client analogous to the doctor-patient or
       attorney-client privileges?
    Guidelines for creating intelligent machines?  (Cf. the current
       controversy over recombinant DNA.)  Criminal responsibility
       if things get out of hand?  (What good would it do by that time?)

Liability
   How could claims be adjudicated fairly?  A computer ombudsman to
       protect the public from abuse via computer?  An arbitration
       panel of lawyers, computer scientists and businessmen to resolve
       disputes in which licensed professionals are involved?
   Malpractice insurance?

I hope these topics have gotten you thinking.  Before sending me a
reply, go away and think hard about these matters.  I think they are
important and that we can have considerable influence on the 
administrative process that will take place if we can present views
that are rational and carefully thought-out.

Date: 10 FEB 1979 0242-EST
From: JIS at MIT-MC (Jeffrey I. Schiller)
To: shamos at CMU-10A
CC: HEADER-PEOPLE at MIT-MC, SIPB at MIT-MC


It is my opinion that the computer science and data
processing fields do not need any psuedo professionalism. By
psuedo professionalism I am referring to professionalism
granted to computer scientist by an as yet unknown third
party (probably influenced by things not pertaining to
computer science).

I feel that adding "professionalism" to the computer science
and data processing fields will have adverse affects to both
the computer programmer and the consuming market as well.

Professionalism will not increase the productivity of a
given  programmer, but will only provide a means of
determining (I'm sure in an unreasonable way) and enforcing
a minimum standard on programmers in general. This casting
off of the low end of the spectrum isn't worth the kind of
shakeup in the field that enforced professionalism would
produce. Also to the detriment of the programmer is the
possibility of law suits resulting from legitimate and
unintentional bugs in programs.  As anyone who has written
reasonable sized programs can tell you, it is near
impossible to write and release perfect software to do
marvelous things in limited time. This is exactly what the
programmer would have to do in order not to worry about a
law suit. This fear of law suits would eventually lead to
insurance (malpractice?) and other forms of bureaucratic
lossage. Although the average programmers salary would go
up, so would his expenses (insurance) go up. It is also not
clear to me that programmers necessarily want
professionalsim if the only reward is a hight salary. Most
of the really good programmers I have met are working on
very low wages, and don't care. That is the personality of
the good programmer.

On the other side of the coin, there is the affect of
professionalism on the consumer (the consumer being defined
here as any person benefiting from a programmers efforts).
This I am sure would be negative.  Look at the American
Medical Association. This organization is a very powerful
force in establishing the cost of health care. And this cost
is not low. Could you imagine an American Programmers
Association that set standards for both programming methods
and prices. Currenly in computer science there is no
"authority" to judge what is good and what is bad. This
professionalism would surely create one. Could you image
what would of happened 20 years ago if professionalism was
introduced then and thos that controled this so far mithical
APA decided (arbitrarily) that all good programs were to be
written in assembly language.  I am not implying that the
field wouldn't advance in this environment, but that its
advancement would be slowed down by red tape and "official
acceptance".

Date: 10 Feb 1979 0052-PST
From: Mark Crispin <MRC at SU-AI>
Subject: programmer professionalism (long & flaming message)   
To:   Shamos at CMU-10A
CC:   Header-People at MIT-MC    


I must say, this proposal sounds pretty much like a loser.  The legal
implications are staggering.  Speaking from my perspective, computer
programming is an art rather than a science, requiring at least as much
skill as knowledge.  In my opinion, education in computer science can
refine or assist in the acquistion of the skill through knowledge, but can
never be a complete substitute.

Consider the environment where professional certification would be
important.  If we are talking about a commercial application, software is
often quite straightforward and requires little more than some training in
COBOL.  If professional certification requires a PhD, you won't have
professionals, simply because that kind of job does not attract PhDs.

Let's consider another common situation: that of the wizard.  He or she
knows the internals of the operating system intimately, can raise crashed
systems from the dead, etc.  This person is a wizard because s/he wants to
be, and quite often has little or no interest in persuing a PhD in
Computer Science.  The average level of education appears to be a
Bachelor's degree, sometimes with "some" grad school, but there are
examples of both extremes.

Back to the PhDs.  Is a PhD in computer science really a measure of that
person's competance as a programmer?  Not really.  A PhD is a measure of
that person's competance in computer science.  This is related to
programming and often a CS PhD is a good programmer, but one does not
imply the other.

So suppose we don't consider education as a method of judging a person as
a professional programmer.  What do we use?  [Note that we've already
offended the PhDs, by telling them their years of education is irrelevant
to how much of a professional they are in relation to a high-school
drop-out.]  How can a certification test be at all fairly administered?  I
have no doubt that I would miserably fail a certification test geared to a
person who must understand IBM architecture (PDP-10 people, recall the ACM
frobs published two years ago); but at the same time I am pretty sure that
I could design a test that would just as badly penalize a highly competant
IBM person, yet be quite fair in judging a person's competance on the
PDP-10.  I doubt that anybody is seriously considering a separate test for
every different manufacturer's architecture.

Now, about the professional programmer's association.  Do I hear rumblings
about the ACM?  What about those of us who have made a conscious decision
NOT to be ACM members?  I feel it would be an enormous affort to me to
force the ACM upon me as MY professional representation.  I have no doubt
that the ACM is an important part of other computer-oriented people's
professional lives, but I was sickened by the constant internal bickering
and the complete uselessness of the ACM publications (to me).  The only
thing of use to me that ACM had to offer were a few of the SIGs; but ACM's
heavy- handed dealing with SIGART got me digusted enough to give up
completely on them.

Let's consider what happens now.  I'm not talking about things like
computer crime (which is already illegal without that awful bill before
Congress).  I won't consider a full-time job, because in that case the
person is an employee and it's a whole different ball game from what we
usually think of as a "professional" task.  A programmer is hired as a
consultant to write a piece of software (say, for example, a memory
diagnostic).  S/he is paid half of the agreed fee when s/he delivers it,
and the other half upon completion of acceptance testing.

At that point (other than the usual non-disclosure agreements) his or her
responsibility ends.  It is the customer's responsibility to design
suitable acceptance tests, and it is assumed that quite probably a
just-delivered program will require modification before it will be
accepted.  In some cases, the program was written off-line from the
customer's system and has never even been run before.

Under those conditions, is s/he to be sued because the program does not
pass the acceptance tests the first run around?  Worse, suppose the
program develops a bug several months later.  Is it lawsuit time?  [Note
that presently the customer would hire somebody (possibly the author) to
fix it instead of suing.]  This essentially means that every programmer
could be sued for every program ever written, even if the bug isn't his or
her fault?  Have you ever dealt with this situation:
	"Your program doesn't work.  Look at this garbage."
	 [??????I'm gonna sue you?????????]
	"Hmm.  I thought I tested that.  Hey, what is this
	 piece of code in here?  I didn't write it.  This
	 just totally breaks it."
	"Oh, I put it in because I wanted to change the way
	 the GARPLY function worked...."

In conclusion, I support a preservation of the status quo rather than
some misguided attempt of making our art into a profession.  Nothing says
that artists may not have a lobby (consider the power of the musicians'
union within their own interests).

-- Mark



Date: 10 Feb 1979 0533-PST
From: Zellich at OFFICE-1
Subject: Is this correct?
To:   Header-People at MIT-MC

Please take a look at the following message.  Have I correctly interpreted
RFC733, and is the header format correct?

Thanks,
Rich

****INCLUDED "RFC733" MESSAGE FOLLOWS****

 9-Feb-79 10:05:11-PST,942;000000000001
Date: 9 Feb 1979 1003-PST
Sender: ZELLICH at OFFICE-1
Subject: RFC733 format test - Jim and John delete without reading -
From: Richard W. Zellich <ZELLICH at OFFICE-1>
To: John F. Foehner <FOEHNER at OFFICE-1>, James E. Burk <BURK at 
OFFICE-1>
Cc: Richard W. Zellich <ZELLICH at OFFICE-1>
Message-ID: < 9-Feb-79 10:02:23-PST ZELLICH at OFFICE-1>

This message is intended to test the new "RFC733" SEND command code.  
A meaningless extract of my Suspense File follows...
Rich

EXTRACT FROM SUSPENSE FILE

 8 Feb 79
   *1  Topic: Graphics specialist in-house 7-9 Feb...
   *2  Topic: Add Bcc to mail stuff & update test-bed Suspense 
   *3  Topic: Correspond with Stefferud about remote printer setups
   *4  Topic: Compose message, with Jim Burk, on running NLS FE on PDP 
   *5  Topic: Go over Budget dialog and spec's package with Jack and 
   *6  Topic: Discuss Databeam/DNLS-emulation assistance with Ben Skees



****END OF INCLUDED MESSAGE****
-------

Date: 10 Feb 1979 0549-PST
From: Zellich at OFFICE-1
Subject: Re: Are we professionals?
To:   MICHAEL SHAMOS at CMU-10A, header-people at MIT-MC,
To:   msggroup at USC-ISI
cc:   ZELLICH

In response to the message sent  8 Feb 1979 1633-EST from MICHAEL SHAMOS@CMU-10A 

The ABA subcommittee should immediately contact the ICCP (Institute
for Certification of Computer Professionals), 35 East Wacker Drive,
Chicago, Illinois 60601.

The ICCP exists for the express purpose of certifying computer "professionals",
and has the following constituent societies:
  ACM
  ACPA
  AEDS
  AIA
  CIPS
  DPMA (who originated the CDP and started the whole thing)
  IEEE
  ACDP

Two different types of examination are currently given (once a year each):
The Certificate in Data Processing (CDP) exam, which covers all areas of
data processing (a 5-part exam & you have to pass all 5 sections); and
the Certificate in Computer Programing exam (CCP).  There used to be a
Registered Business Programer exam, but it has been dropped in favor of the
CCP.  Other examinations are in the planning or development stages:
CEDPA - Certificate in Electronic Data Processing Auditing; CSA - Certificate
in Systems Analysis; and CDE - Certified Data Educator.

The ICCP program(s) and goals address many of the questions raised by
Michael Shamos' message.  In particular, there is a document titled
"Code of Ethics, Conduct and Good Practice for Holders of the Certificate 
in Data Processing".  You do not have to belong to any of the ICCP
constituent societies to qualify for any of the Certificates, and there
is no membership (only the societies') in the ICCP itself.

Richard W. Zellich, CDP
-------

Date: 10 Feb 1979 0921-PST
Sender: GEOFF at SRI-KA
Subject: Re: Is this correct?
From: the tty of Geoffrey S. Goodfellow
To: Zellich at OFFICE-1
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KA]10-Feb-79 09:21:35.GEOFF>
In-Reply-To: Your message of 10 Feb 1979 0533-PST

Who cares if it conforms to RFC733 or not?

Contrary to most peoples believed conceptions, RFC733 was NOT
"officially" adopted as a standard and/or "required" of anyone.
Most of the (small number) of people who went ahead and
implemented it and who go around barking at people who don't
conform to it seem to be a small class of users who do not really
understand the official sanctioning or management structure of
the network, and who seem to think that all programs are
supported and maintained via some undetermined pot of gold
supplied by some nameless agency.  In particular, DCA did not
promulgate the work which let up to RFC733, nor did they
officially bless its final form (to which many people have
numerous objections, including the lack of backwards
compatibility).

Hence, the currently implementations of the RFC will be left up
to those few who wish to do it on their own time or at the
expense of the one they work for, but that gives them no right to
complain to those who do not chose to implement it, or implement
it correctly.

So even if your message doesn't conform to the standard, you
aren't breaking the law.

From: dcrocker at Rand-Unix
Date: Sat, 10 Feb 79 12:33-PST
To: Zellich at OFFICE-1
cc: Header-People at MIT-MC
Subject: Re: Is this correct?
In-reply-to: Your message of 10 Feb 1979 0533-PST.

Rich -- I think that your sending a test message arouond, so that we can
see what different sites are going to put out and how they are
interpreting the standard is excellent.  

Your example looked fine except for two points, one an error and
the other merely a verbosity.

The To: filed contained a continuation line, consisting of
"OFFICE-1>".  The line must begin with a LWSP-Char (space or
horizontial tab) but did not.

Also, the message contained both a From and a Sender field, when the
Sender field was unecessary.  No Sender field is required if
the From field contains a simple host-phrase (which yours did not)
or a host-phrase followed by a machine id (which yours did).  Note,
this applies to the case, such as yours, in whihc the Sender contains
the same mailbox reference as the From.

Dave.

Date: 10 FEB 1979 1326-PST
Sender: FARBER at USC-ISI
Subject: Re: Is this correct?
From: FARBER at USC-ISI
To: GEOFF at SRI-KA
Cc: Zellich at OFFICE-1, Header-People at MIT-MC
Message-ID: <[USC-ISI]10-FEB-79 13:26:04.FARBER>
In-Reply-To: <[SRI-KA]10-Feb-79 09:21:35.GEOFF>

You know, I am sadly reminded of a person cutting his own throat
because his toe hurts.  One can argue with whether or not 733 is
correct, too elaborate or what ever, but to sit on the official
sanction platform and thus recommending that one not conform to
even a "de facto standard" ( and I thing 733 is no less a
standard than most other ArpaNet standard) is dangerous.

I might very much want to see a simpler minimal standard, but I
am very tired personally of using systems and receiving messages
that CANNOT live with each other.



Dave

Date: 10 FEB 1979 1444-PST
From: POSTEL at USC-ISIB
Subject: Official-ness of RFC 733
To:   Zellich at OFFICE-1
cc:   header-people at MIT-MC


RFC 733 is as official as any ARPANET Protocol.  It is published in the
ARPANET Protocol Handbook under DCA sponsorship.  It is the reference document
in case of disputes between message system implementors.

--jon.
-------

Date: 10 Feb 1979 1457-PST
Sender: GEOFF at SRI-KA
Subject: Re: Official-ness of RFC 733
From: the tty of Geoffrey S. Goodfellow
To: POSTEL at USC-ISIB
Cc: Zellich at OFFICE-1, header-people at MIT-MC
Message-ID: <[SRI-KA]10-Feb-79 14:57:31.GEOFF>
In-Reply-To: Your message of 10 FEB 1979 1444-PST

According to SANTOS@BBNE it isn't.  He claims so on two grounds,
one from the big message mtg.  held at BBN recently,and the 2nd
since he works directly for DCA and claims it isn't.

Date: Saturday, 10 Feb 1979 1827-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: message standards
To:   Header-people at Mit-MC
Message-ID: <10Feb79 182715 BR10@CMU-10A>

Hey guys, I have a plan.
Let's design ANOTHER standard, since this one isn't quite enough.....

Date: 10 Feb 1979 (Saturday) 1836-Est
From: NIH at NBS-10
Subject: Professionalism and Certification
To:   header-people at MIT-MC

Our own organizations, ACM, IEEE, ICCP, etc. should be the focus of our
comments, not the ABA.			. . . Glenn


Date: 10 FEB 1979 1550-PST
From: POSTEL at USC-ISIB
Subject: Re: message standards
To:   Brian K. Reid <BR10 at CMU-10A, Header-people at MIT-MC
cc:   POSTEL

In response to the message sent Saturday, 10 Feb 1979 1827-EST from Brian K. Reid <BR10@CMU-10A>


Hey, as long as were taking on new tasks, lets design a new programming 
language, the existing ones don't do everything we want, and there aren't
enough yet either.

--jon.
-------

Date: 10 Feb 1979 1550-PST
From: Zellich at OFFICE-1
Subject: Re: Is this correct?
To:   dcrocker at RAND-UNIX
cc:   Header-People at MIT-MC, ZELLICH

In response to your message sent Sat, 10 Feb 79 12:33-PST

Yeah, I understand about the Sender/From fields, but am actually
implementing a mail-sending program that calls someone elses
existing mail code to convert the file from hierarchical strucutre to
sequential and to FTP it off.  I have no control whatsoever over the
Sender field and had a choice of leaving the From field out entirely
(and thereby losing the "phrase" personalization from the NIC Ident data
base) or putting in a near-duplicate header field (same net address but
different text string due to the "phrase" and  <>'s).

The LWSP beginning a continuation line is a real problem - thanks for
pointing it out.  That's going to be a fun one to fix since it is
caused by the hierarchical-to-sequential code converting the up-to-2000-
character strings I build, and that code wants to throw away any
LWSP at the start of a line!

Thanks to all you Header-People out there who have responded so far
(Sure are a lot of you working on Saturday!)

Cheers,
Rich


As an aside, you ought to see what that "phrase" personalization
does to a message with many recipients -- it just about makes the
whole header unreadable!  You just can't win for losing...
-------

Date: 10 FEB 1979 1603-PST
From: POSTEL at USC-ISIB
Subject: Official-ness of RFC 733
To:   Geoff at SRI-KA
cc:   header-people at MIT-MC


Geoff:

1) Santos works for BBN.

2) The "big message meeting" at BBN.

   Duane Adams (ARPA program manager for message technology) called the meeting
   to try to get a plan for stabilizing the current message system situation in
   the ARPANET.  The sense of the meeting was "if a feature works at most
   sites it is in, if it causes problems at more than a few sites it is out".
   Basicly the idea is to close off development on the current type of message
   systems.  RFC 733 is the reference document, but that does not sanction the
   implementation of the "advanced features" contained there in.

--jon.
-------

Date: 10 FEB 1979 1628-PST
Sender: FARBER at USC-ISI
Subject: Re: message standards
From: FARBER at USC-ISI
To: POSTEL at USC-ISIB
Cc: Header-people at MIT-MC
Message-ID: <[USC-ISI]10-FEB-79 16:28:53.FARBER>
In-Reply-To: Your message of 10 FEB 1979 1550-PST

Ah DOD2

Sorry could not resist

Date: 10 Feb 1979 1614-PST
Sender: GEOFF at SRI-KA
Subject: Re: message standards
From: the tty of Geoffrey S. Goodfellow
To: POSTEL at USC-ISIB
Cc: Header-people at MIT-MC
Message-ID: <[SRI-KA]10-Feb-79 16:14:38.GEOFF>
In-Reply-To: Your message of 10 FEB 1979 1550-PST

Isn't that what DOD-I is all about?

Date: 10 FEB 1979 2303-PST
From: POSTEL at USC-ISIB
Subject: re: Professional Computerists
To:   header-people at MIT-MC


i suggest the situation for professional computerists should be modeled
after the situation with engineers.  There are professional engineers,
and there are a lot of people who went through engineering school and
now work for a company doing engineering with out being certified.  There
are even people doing engineering work who never went to engineering
school.

if there ever is a way to become a certified professional computerist
(e.g. the ICCP) i suspect that many people who could easily qualify,won't
bother.  Mainly because they will be working for companies that don't care.

--jon.
-------

Date: 11 Feb 1979 1441-PST
From: Zellich at OFFICE-1
Subject: re: Professional Computerists
To:   POSTEL at USC-ISIB, header-people at MIT-MC
cc:   ZELLICH

In response to the message sent 10 FEB 1979 2303-PST from POSTEL@USC-ISIB

Jon is quite correct -- this is the situation now, ans has been for
some time.  I received my CDP back in '66 or '67, and it was not a
new program then.  Most people/organizations have still never heard of
the various certificates, the certifying body, or for that matter 
most of the constituent societies.  Most ADP people, and the companies
they work for, just couldn't care less.

Nevertheless, it may be a good idea to have such a certification
system on hand.  With all the public and congressional flaming about
privacy and security, and such things as EFT coming (however slowly),
there may well be a push to bring us into an environment of legal
protection and liability.  Considering the awesome potential when we
bring together personal computers, public/private/government networks,
and EFT it is quite likely that not only business/MIS types like myself,
but even the "hackers", systems programers, analysts, and functinal-area
specialists will become subject to regulation and both criminal and
civil court action.  The poor system developers/maintainers are going
to have to be damned sure they leave to loopholes whereby anyone can,
either intentionally or otherwise, zap a system or violate anyone's
privacy.  The legal principle of the "reasonably prudent person" is
all well and good, but it's awfully easy to bring a malpractice suit.

I would certainly prefer a certification system within the ADP
community, such as the ICCP one, to anything dreamed up by the ABA,
consumer rights/action groups, or Congress.  Please note that as a
CDP holder, I have an input channel to the certifying body, without
having to belong to ANY of the constituent societies.

Rich
-------

Date: 14 FEB 1979 1521-EST
From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
Subject: Request for bibliographic information
To: HEADER-PEOPLE at MIT-MC, FARBER at USC-ISI



Date: 17 Feb 1979 1236-EST
From: Rick Gumpertz at CMU-10A
Subject: Losing headers
To:   Geoff @ SRI-KA
CC:   Header-People @ MIT-MC
Message-ID: <17Feb79 123648 RG02@CMU-10A>

Geoffrey -

Your headers (see below) seem to be particularly nasty.  In
particular, where you have SENDER, I think you should have REPLY-TO.
As it is, since RFC733 specifies that SENDER is NOT to be used for
replys, the reply address is "the tty of Geoffry S. Goodfellow" at
SRI-KA which SRI-KA rejects as an illegal address.  I suspect your
mail generator does not understand RFC733 properly.  Can you look
into it?

                Rick

- - - - Begin forwarded message - - - -
Date: 15 Feb 1979 1907-PST
Sender: GEOFF at SRI-KA
Subject: CMMP
From: the tty of Geoffrey S. Goodfellow
To: Gumpertz at CMUA
Message-ID: <[SRI-KA]15-Feb-79 19:07:00.GEOFF>

[Body deleted]
- - - - End forwarded message - - - -

Date: 20 Feb 1979 0339-PST
Sender: GEOFF at SRI-KA
Subject: Re: Losing headers
From: the tty of Geoffrey S. Goodfellow
To: rg02 at CMUA
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KA]20-Feb-79 03:39:33.GEOFF>
In-Reply-To: <17Feb79 123648 RG02@CMU-10A>
Reply-to: Geoff @ SRI-KA

Now that I have figured out how to make wonderful HERMES generate
"Reply-to:" how is this?

However, I will still have a special template just for MIT sites,
which will send the message without with "Reply-to" field just to
remind them each time they one of my messages how I feel when I
get one of their Illegaly formatted (ITS STYLE) headers in my
MAILBOX and can't parse it.  Perhaps they to, someday will fix
their mail system to do the right thing, and not violate network
protocol.

Date:  20 February 1979 23:09 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re: Losing headers
To:  Geoff at SRI-KA
cc:  rg02 at CMU-10a, Header-People at MIT-MC
In-Reply-To:  Msg of 02/20/79 06:39 from the tty of Geoffrey S. Goodfellow
Message-ID:  <790221040912.687701 at MIT-Multics>

Please, don't accuse all MIT sites of sending out illegal heaaders.
That is an ITS quirk and there are indeed other systems at MIT.

Date: 20 Feb 1979 2014-PST
Sender: GEOFF at SRI-KA
Subject: Re:  Re: Losing headers
From: the tty of Geoffrey S. Goodfellow
To: Frankston.Frankston at MIT-MULTICS
Cc: rg02 at CMU-10A, Header-People at MIT-MC
Message-ID: <[SRI-KA]20-Feb-79 20:14:35.GEOFF>
In-Reply-To:  <790221040912.687701 at MIT-Multics>
Reply-to: Geoff @ SRI-KA

Sorry, I stand corrected.  I meant to say MIT-ITS sites, and
didn't think of XX or Multics at the time.  Sorry.

Redistributed-Date:  22 February 1979 19:19 est
Redistributed-By:  Palter.PDO at MIT-Multics
Redistributed-To:  Header-People at MIT-MC
Date: 20 Feb 1979 1008-PST
Sender: rudisin at UCLA-SECURITY
Subject: MSGGROUP# 792   Response to MSGGROUP 790 re licensing
From: rudisin at UCLA-Security
To: msggroup
Redistributed-To: [ISI]<MsgGroup>Mailing.List;177:
Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP)
Redistributed-Date: 20 FEB 1979






      This message is a response to the  request  by  Shamos@cmua
for comments on the issue of licensing of computer professionals.
The very subject is nauseating to me and I am disturbed that such
a  debate can even take place, let alone that it seems reasonable
to many people in our profession.  Normally I would not waste the
time  to  reply  but  recalling the pathetic nature of the IEEE's
recent debate on the question, wherein the real issues  were  ig-
nored, I am compelled to respond.

      In a word, the very idea of governmental licensing of  com-
puter  professionals  (or  anyone else) is immoral. It is immoral
because it is nothing less than a  form  of  slavery.  This  word
seems  harsh  because  people are so used to accepting government
licensure of most other disciplines, but it is nonetheless  accu-
rate.  For what else can you call a set of laws which require you
to seek the permission of some bureaucrat before you can practice
your profession -- before you are allowed to freely use your mind
as a computer scientist? This is the fundamental issue; rejection
of  the  principle  that licensing is legitimate or moral must be
the cornerstone of the computer science community's rejection  of
the concept.

      The idea of governmental (coercive) registration is immoral
because  no government has any right at all to force me to obtain
a license to practice this profession.  If I  wish  to  offer  my
services as a computer scientist, I will put my skill and reputa-
tion on the line in the free market of  ideas  and  services,  by
entering into voluntary agreements with customers.  The intrusion
of government into this market is wrong  because  it  is  such  a
tremendous  violation  of  my  right  to interact freely and on a
voluntary basis with other people.

      Please  note  that  I  have  no objection at all to private
forms of certification; for example one of the computer societies
could  offer a credential certifying that its bearer has attained
a certain level of skill. If a given  certification  organization
gained  a reputation for being reliable in its assessment of pro-
fessionals, there would continue to be a market for its  service;
if  not, no one would care about a credential from that organiza-
tion and it would be ignored.  At any time people would  be  free
to  seek customers based on their own reputations, on the posses-
sion of certification from various places, on experience, on edu-
cation, and so on.  A totally free market in the offering of com-
puter skills allows maximum creativity and freedom and will fost-
er innovation instead of hindering it.

      Regulation of the computer community would inevitably  take
us  down  the  path of the regulation of all other industries and
groups -- to mediocrity, stagnation and loss of liberty.   It  is
inevitable  and  plainly  obvious  from  examples such as that of
licensing of physicians that the holding of a license is a shield
behind  which  the mediocre can hide while claiming that they are
as good as the best of professionals -- after all, doesn't every-
one  possess  the same license? Hasn't the government proven that
everyone with a license is of equal competence?  This  is  absurd
but  is  an  effect  of  licensing that is sure to arise.  With a










licensing apparatus in place the mediocre individuals in  a  pro-
fession  can keep out the creative people who challenge their pet
theories and procedures  or  who  "threaten"  them  with  greater
skill.   What  better way will exist for mediocre people to guard
themselves against the competition of  a  bright  young  newcomer
self  taught on his home microprocessor system than to claim that
he has not been properly licensed and is thus  a  threat  to  the
public? This may sound farfetched, and would certainly not happen
immediately, but is inevitable at  some  later  date,  especially
when  you  consider that the highly competent people in a profes-
sion are usually too busy producing and innovating to waste  time
actively  running the licensing boards.  Licensing boards inevit-
ably fall into the control of the no better than  average  member
of the profession.

      Innovation is stifled, as is also apparent in  the  medical
profession;  any  kind  of  development which runs counter to the
wisdom of the licensing board  is  vigorously  resisted  and  its
practitioners are called quacks. An example is the medical debate
over the role of nutrition in health and the holistic approach to
health.   Acceptance  does eventually come for new ideas but only
after unnatural and wasteful delays.

      The  holding  of a license also makes it far more difficult
for a consumer to be protected, because once licensed it is  very
difficult  for  an  inept practitioner to be unlicensed.  This is
again apparent from the medical profession -- members of the fra-
ternity are very reluctant to testify against each other, and the
delays in holding hearings to  investigate  alleged  incompetence
are enormous. The result is that instead of immediately being put
out of business by  market  forces,  incompetent  doctors  suffer
almost  no  penalties  because the licensing mechanism masks poor
performance from view of the customers and eliminates the associ-
ated free market penalties.

      Is the encouragement of mediocrity, the stifling of innova-
tion, and the elimination of true market forces as a test of com-
peting technologies in the interests of the community or  of  the
public  which  licensing  is erroneously intended to protect? The
answer is clearly no.

      One  of the reasons for the incredible vitality and excite-
ment of the computer sciences is the fact that there is almost no
regulation  of  the  industry,  beyond the general harassment and
regulation that all businesses must contend with from government.
The  rapid  rate  of technological change is intimately connected
with the tremendous freedom  that  computer  scientists  have  in
using  new  technologies, and which companies have in introducing
them. There is no need for any of us to ask the approval  of  the
licensing  board  to see if a new development is suitable.  There
is no need to wait until a committee studies a new technique  and
certifies  it  for  use.  We can adopt it and risk its use in the
marketplace.  One can see the contaminating effects of  licensing
and  regulation  on  our  field by looking at the intersection of
computer technology and communications, where one can plainly see
that  the  main  obstacles  to  technological  advancement in the










communication field -- including the development of  public  com-
puter  based message systems -- is the onerous hand of government
regulation.  (Note that FCC regulation of  telecommunications  is
the  functional  equivalent of the licensing of individuals under
discussion here, applied to groups of people (companies)).

      There  are  a  number of questions posed in Shamos' message
and several issues raised which are worth considering separately.
The  number  of  erroneous ideas and false alternatives raised in
the few paragraphs of the message approach the density of some of
todays memory chips, so I will address them as a class.

      First, there is the issue of the role of the  professional.
I  for  one am not here to serve humanity or some fuzzy notion of
the public good; my mind is not public property and  neither  are
the  fruits  of my effort. No one with a sense of self esteem and
integrity can accept the notion that a gang  of  bureaucrats  has
the right to tell him that he needs a license in order to use his
mind to earn a living.  I  work  for  myself,  by  entering  into
voluntary  relationships  with other people -- individuals or or-
ganizations, employers or employees.

      The main body of the message dealt with various problems of
assuring the quality of work and of protecting customers from the
effects  of  shoddy  work.   This is where the false alternatives
creep in, for the choice confronting todays user of computer ser-
vices  is  not  one  of  being  protected by government licensing
versus being at the mercy of inept or  unscrupulous  programmers.
An  assertion  such as this totally ignores the role of voluntary
agreement -- in short, it ignores the mechanism of contracts.  If
I  am  seeking  the design of a computer system there is a simple
way to guarantee that it performs satisfactorily -- deal  with  a
firm  or a person who is willing to guarantee his work to a mutu-
ally agreed upon extent.  If the system performs as specified, he
gets paid; if it does not, he fixes it at his own expense, and if
that fails the system is rejected and he loses his money.  All of
the  other  issues  raised in the message -- the credit reporting
example, the  confidentiality  issue,  codes  of  responsibility,
malpractice,  and adjudication of claims -- can all be handled by
voluntary mechanisms called contracts.

      The  notion that government licensing can magically improve
the level of technology is absurd; if a guarantee of, say, a per-
fectly performing compiler cannot be met by current technology it
certainly cannot be met because a license  is  required  to  try.
Instead,  innovation  will  dry up because no one will be able to
take the risk of developing a new compiler.  I repeat  --  issues
of  acceptable  performance,  liability for damages, and the han-
dling of disputes can be handled without the immoral and disgust-
ing use of coercion by government.

      In sum, licensing is an assault on the very foundations  of
the  most  exciting  and  fastest  growing industry today -- that
foundation being the free and untrammeled use of the mind and the
offering of products for voluntary acceptance by potential custo-
mers.  Licensing is an attack on  competence  and  an  attack  on










innovation, and it must be resisted because it is immoral.

Gerard J. Rudisin
(rudisin@ucla-security)

Date: 25 FEB 1979 0236-EST
From: MLK at MIT-MC (Michael L. Kazar)
To: HEADER-PEOPLE at MIT-MC

I am interested in hearing from people who have used either Vax/VMS
or Vax/Unix.  I am especially interested in problems people have run
into with either VMS or Unix.  Specific details on problems and features
are especially desired.  First-hand knowledge is really especially
desired!  Please send responses to Kazar@CMUA.

Date: 25 Feb 1979 2155-EST
Sender: FURST at BBN-TENEXB
Subject: Vax/Unix and VMS
From: Furst at BBN-TENEXB (Sheldon R. Furst)
To: Kazar at CMU-10A
Cc: Header-People at MIT-MC
Message-ID: <[BBN-TENEXB]25-Feb-79 21:55:27.FURST>

Well, to begin with, I presume that when you refer to VAX/Unix,
you refer to version 7 release from Bell/Western.  This is
presently running only at UC Berkeley, under a special deal with
Bell (UC is designated the Homdel test site).  It is a good guess
that this will not be available commercially for quite a while
(to my knowledge, Western still has yet to release 11/XX version
7 licenses).  For more information, contact RJF@MC or WNJ@MC.

At Lawrence Berkeley Laboratory we have one VAX with a second one
arriving in two weeks.  Both run VMS 24 hours a day, with a
critical systems maintenance contract with DEC.  We have lots of
projects using this machine, including many that really get into
the guts of the OS (spawn primitives, etc).  For more information
about this, contact Dennis Hall (Hall@BBNB).  Also, Joel Moses
and his group are doing a lot of nifty things at MIT (such as a C
compiler under VMS).  Contact JM@MIT-MC.

Lastly, what does this have to do with headers?  I think this
message would have been more appropriately sent to
Network-Liaisons (c/o Jake Feinler).

-- Sheldon

From: dcrocker at Rand-Unix
Date: Mon, 26 Feb 79 14:20-PST
To: Header-People at mit-mc
cc: Gaines at Rand-Unix
Subject: addition to Header-People mailing list



------- Forwarded Message

From: Gaines at Rand-Unix
Date: 26 Feb 1979 at 1346-PST
To: Dcrocker at Rand-Unix
Subject:Header people conference

Dave,
  How do I get on the equivelent of MSGROUP for headers?  I'm getting
interested enough in the subject that I'd like to be added.  If you
can take care of this simply by forwarding this request to the
right person, that would be good.

Stock



------- End of Forwarded Message

Date: 27 Feb 1979 1831-EST
From: Rick Gumpertz at CMU-10A
Subject: ITS headers
To:   RMS at MIT-AI
CC:   Header-People at MIT-MC
Message-ID: <27Feb79 183103 RG02@CMU-10A>

When oh when will you fix your mail programs to not let ITS headers out
over the Arpanet??  Presumably the mailing daemon could automatically spot
and convert your headers!

                Rick

- - - - Begin forwarded message - - - -
RMS@MIT-AI 02/27/79 19:56:32
To: msggroup at MIT-ML
Veiled and vague threats, such as Pine's threats that some unidentified
"real" users of our systems would force us to change our ways,
are really sinking very low.
I'd like you to identify the people who are going to do this,
and then explain what will stop us from ignoring them.
Even if such an event does come to pass, it won't prove anything
about the morality issues.  Similar events occur every day on
our streets and in our parks.
- - - - End forwarded message - - - -

Date: 27 Feb 1979 1758-PST
Sender: GEOFF at SRI-KA
Subject: Re: ITS headers
From: the tty of Geoffrey S. Goodfellow
To: rg02 at CMUA
Cc: RMS at MIT-AI, Header-People at MIT-MC
Message-ID: <[SRI-KA]27-Feb-79 17:58:25.GEOFF>
In-Reply-To: <27Feb79 183103 RG02@CMU-10A>
Reply-to: Geoff @ SRI-KA

I'v brought this very item to the attention of BUG-MAIL@MIT-AI a
few times, and gotten back replies such as "one of these days" or
even being called an asshole by Dave Moon.  Perhaps people who
call others assholes will stop being them themselves, and get
around to fixing long standing lossages that cause others grief.

Date: 27 FEB 1979 2109-EST
From: RMS at MIT-AI (Richard M. Stallman)
Subject: ITS Headers
To: HEADER-PEOPLE at MIT-AI

I don't think there is anyone here who maintains COMSAT any more.
I think therefore that you are out of luck.
Probably nobody is interested in learning how to work on
the mailer just do do something for the sake of other sites.


Date: 27 FEB 1979 2123-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: HEADER-PEOPLE at MIT-AI

I would like to apologize on behalf of anyone who called
people "assholes" just because theuy'd like not to get ITS headers.
That's a reasonable thing to want if you aren't on ITS,
and it doesn't make them assholes.  But that doesn't oblige
us to put it very high on the list of things to be done.


Date: 28 Feb 1979 2227-PST
Sender: GEOFF at SRI-KA
Subject: [MOOERS at BBN-TENEXA: Re: Replying to messages with spaces...]
From: the tty of Geoffrey S. Goodfellow
To: Header-people at MC
Message-ID: <[SRI-KA]28-Feb-79 22:27:17.GEOFF>
Reply-to: Geoff @ SRI-KA

Why HERMES cant reply to CMU messages.
	
Begin forwarded message
===========================
Mail from BBN-TENEXA rcvd at 28-Feb-79 2222-PST
Date: 28 Feb 1979 2337-EST
Sender: MOOERS at BBN-TENEXA
Subject: Re: Replying to messages with spaces inthe from field.
From: MOOERS at BBN-TENEXA
To: GEOFF at SRI-KA
Cc: MYER, MOOERS, AIRPLANES, Mooers
Message-ID: <[BBN-TENEXA]28-Feb-79 23:37:41.MOOERS>
In-Reply-To: <[SRI-KA]28-Feb-79 20:02:26.GEOFF>

Neither Hermes nor SNDMSG will accept a To: field with the form

To: Brian Reid at CMU-10A

whether or not a REPLY command is used.

Since CMU is the only host generating this type of From: field,
and since ARPA is not pushing a strict enforcement of RFC733 if
it means making disruptive changes in current systems, and since
we don't have support for this kind of change anyway, we are not
planning to do anything about it for the moment.

---Charlotte
===========================
End forwarded message
		

Date: 5 MAR 1979 2217-EST
From: RMS at MIT-AI (Richard M. Stallman)
To: header-people at MIT-MC

If I found :MAIL prompt me for a subject, I would probably be taken
aback and need half a minute to figure out what I was doing again.
To eliminate this problem I would train myself to ignore it.
The result would be that the first line of my message would
appear as the "subject".  This might not be so bad.
However, if it were going to do that, I would rather not have
it bother me about it.  I also wouldn't want the fact that the
first line of my message was thought of as the "subject" to
prevent me from rubbing out back into it in the way I otherwise could.

I still think, though, that people should change mail readers
to report the first line of the message as the subject, in summaries,
if that's what they want.  That is what ITS does.

Once in a while I have something I consider a useful subject,
but for the most part I don't have anything that feels worth supplying
and subjects in messages I receive are usually information-free.
Therefore, I think that making a mail sender bother the user for a subject
will just get in the way of getting work done.


Date: 5 MAR 1979 2025-PST
Sender: STEFFERUD at USC-ISI
Subject: RMS on why bother?
From: STEFFERUD at USC-ISI
To: RMS at MIT-AI
Cc: header-people at MIT-MC
Message-ID: <[USC-ISI] 5-MAR-79 20:25:47.STEFFERUD>
In-Reply-To: Your message of 5 MAR 1979 2217-EST

MsgGroup contributions are kept in more or less organized form
for later reference.  did you not know you are talking into a
recording device when you flame into MsgGroup?

Cheers - Stef
	
- - - - - - - - - - - - - - - - - - - -  453 chars/  3

Date: 5 MAR 1979 2218-EST
From: RMS at MIT-AI (Richard M. Stallman) - - 
To: Stefferud at USC-ISI

Now that we have CBF;MSG LOG, why is it necessary for you to
do any editing on it?  Why not just let people read it as is?
I hope it doesn't make you feel bad to be "replaced by a computer",
but it sounds like you don't think that task is much fun, anyway.
Does the transcript get printed and published?


*** TRAILER *** 
Mail from MIT-AI rcvd at 5-MAR-79 1919-PST
*** END /#  3
		

Date:  6 March 1979 05:53 est
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject:  keywords
To:  header-people at MIT-MC
Message-ID:  <790306105320.324308 at MIT-Multics>

{Hmm, flaming appears to be bacck on heade-people for the moment} I'd
like it if keywrods were supplied in a ddition to subject to make it
easier to keep trac of the multiple threads running through my mail and
to give me, the recipient the ability to add more keywords.  Alas, I do
not expect anyone here to implement it.

I have implemented it on my own mail system, unfortunately on an unneted
VM system and find it a win.

Date:  6 March 1979 09:21 est
From:  Sibert.PDO at MIT-Multics
Subject:  Re: keywords
To:  Frankston.Frankston at MIT-Multics (Bob Frankston)
cc:  header-people at MIT-MC
In-Reply-To:  Msg of 03/06/79 05:53 from Bob Frankston
Message-ID:  <790306142113.819920 at MIT-Multics>

Yup. There should be some such ability. Not right now, though.

 -- wos

Date:  6 March 1979 09:24 est
From:  Sibert.PDO at MIT-Multics (W. Olin Sibert)
Subject:  last message, from me
To:  header-people at MIT-MC
Message-ID:  <790306142448.577463 at MIT-Multics>

Please ignore it. It is a demonstration of the slightly less than
winning mail system I have implemented here.

 -- wos

Date:  6 MAR 1979 0836-PST
From: POSTEL at USC-ISIB
Subject: Subject Line
To:   Header-People at MIT-MC


Does the fact that a message does not have a subject line have any
correlation with the senders not knowing what he is saying until after
the message is sent (if then) ?

--jon.
-------

Date: Wednesday,  7 Mar 1979 0118-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: RFC733
To:   Header-People at MC
Message-ID: <07Mar79 011816 BR10@CMU-10A>

Sieg Heil!

- - - - Begin forwarded message - - - -
Date: Tuesday,  6 Mar 1979 1820-EST
From: Howard Wactlar at CMU-10A (S300HW09)
Subject: ARPA "order"
To:   RDMAIL at CMU-10A, bajzek at CMU-10A
Message-ID: <06Mar79 182009 HW09@CMU-10A>
Remailed-To: RdMail-Maintainers: (RDHACK.DST[A800RD00]) Rdmail at CMU-10A,
             Craig Everhart at CMU-10A, David Lamb at CMU-10A,
             Philip Lehman at CMU-10A, Bruce Nelson at CMU-10A,
             Brian Reid at CMU-10A, Karlton @ PARC-MAXC, Sapsford @ PARC-MAXC;
Remailed-From: RdMail at CMU-10A
Remailed-Date: Wednesday,  7 Mar 1979 0058-EST

People,
We have been officially asked by ARPA, through Duane Adams, program manager
in their IPT office, to eliminate two-name from fields in mail we transmit.
There was appropriate recognition that it was within the defined 733 spec,
but that NOBODY benefitted by our using it.  How about going back to placing
a period between first and last names instead of a space when both first and
last names are non-empty (i.e. no period if the first name is empty).
How about getting it done as soon as reasonable.  We made our point,
now lets concede the issue and give the others on the net what they can
all handle.
If you have any technical or philosophical difficulties with the change,
come talk to me (or send flaming mail if that makes you feel better).
Thanks much,
Howard

- - - - Begin forwarded message - - - -
Date: 6 MAR 1979 0703-PST
Sender: ADAMS at USC-ISI
Subject: Re: And Hermes' not handling multi-word mailbox names
From: ADAMS at USC-ISI
To: dcrocker at RAND-UNIX
Cc: Adams, Farber at SRI-KA, Wactlar at CMU-10A, Mooers at BBNA
Message-ID: <[USC-ISI] 6-MAR-79 07:03:20.ADAMS>
In-Reply-To: Your message of Sat,  3 Mar 79 15:06-PST

Dave,
Requesting a change to Hermes to handle a two-name from
field is exactly the kind of change I want to avoid
requesting maintainers of message systems to have to 
incorporate.  Here the corrective action is obvious--
those who use two-name from fields will remove them from
their message systems.  I have already asked Howard
Wactlar of CMU to remove this feature from their
system.
Duane
- - - - End forwarded message - - - -
- - - - End forwarded message - - - -

Date: Tuesday,  6 Mar 1979 1820-EST
From: Howard Wactlar at CMU-10A (S300HW09)
Subject: ARPA "order"
To:   RDMAIL at CMU-10A, bajzek at CMU-10A
Message-ID: <06Mar79 182009 HW09@CMU-10A>
Remailed-To: RdMail-Maintainers: (RDHACK.DST[A800RD00]) Rdmail at CMU-10A,
             Craig Everhart at CMU-10A, David Lamb at CMU-10A,
             Philip Lehman at CMU-10A, Bruce Nelson at CMU-10A,
             Brian Reid at CMU-10A, Karlton @ PARC-MAXC, Sapsford @ PARC-MAXC;
Remailed-From: RdMail at CMU-10A
Remailed-Date: Wednesday,  7 Mar 1979 0058-EST
Remailed-To: MsgGroup at ML, Header-People at MC
Remailed-From: RdMail at CMU-10A
Remailed-Date: Wednesday,  7 Mar 1979 0124-EST

People,
We have been officially asked by ARPA, through Duane Adams, program manager
in their IPT office, to eliminate two-name from fields in mail we transmit.
There was appropriate recognition that it was within the defined 733 spec,
but that NOBODY benefitted by our using it.  How about going back to placing
a period between first and last names instead of a space when both first and
last names are non-empty (i.e. no period if the first name is empty).
How about getting it done as soon as reasonable.  We made our point,
now lets concede the issue and give the others on the net what they can
all handle.
If you have any technical or philosophical difficulties with the change,
come talk to me (or send flaming mail if that makes you feel better).
Thanks much,
Howard

- - - - Begin forwarded message - - - -
Date: 6 MAR 1979 0703-PST
Sender: ADAMS at USC-ISI
Subject: Re: And Hermes' not handling multi-word mailbox names
From: ADAMS at USC-ISI
To: dcrocker at RAND-UNIX
Cc: Adams, Farber at SRI-KA, Wactlar at CMU-10A, Mooers at BBNA
Message-ID: <[USC-ISI] 6-MAR-79 07:03:20.ADAMS>
In-Reply-To: Your message of Sat,  3 Mar 79 15:06-PST

Dave,
Requesting a change to Hermes to handle a two-name from
field is exactly the kind of change I want to avoid
requesting maintainers of message systems to have to 
incorporate.  Here the corrective action is obvious--
those who use two-name from fields will remove them from
their message systems.  I have already asked Howard
Wactlar of CMU to remove this feature from their
system.
Duane
- - - - End forwarded message - - - -

Date:  7 Mar 1979 0218-EST
From: Richard H. Gumpertz at CMU-10A
Subject: Re: ARPA "order" and white-space in names
Sender: Rick Gumpertz at CMU-10A
To:   Howard Wactlar at CMU-10A (S300HW09)
CC:   ADAMS at USC-ISI, MSGGROUP @ MIT-ML, Header-People @ MIT-MC,
      Newcomer at CMU-10A, Reid at CMU-10A
Reply-To: Gumpertz (who has a first name AND a middle name!) at CMU-10A
Message-ID: <07Mar79 021843 RG02@CMU-10A>
In-Reply-To: <06Mar79 182009 HW09@CMU-10A>

Damn it this annoys me.  I have two names (well really three) and
there is no period after the first.  There is both a period and
white-space after my middle initial.  Although I have been compliant
(complacent?) enough to list only my last name in mail addresses for
me, I am seriously considering changing that just to be rebellious.

Any time one requests that one avoid a standard, one is in a very
questionable position.  I just can't believe that some hacker on
TENEX can't fix the problem somehow.  Perhaps by internally changing
spaces to something like # when queueing mail and then changing them
back when actually transmitting it.  (I am working under the
assumption that the problem is that queueing is via file names which
can't include blanks, or some such thing -- my best recollection of
an old explanation I once saw.)

Being depersonalized by a computer is bad enough; being stomped on
one more time by TENEX is absolutely infuriating.  Perhaps it is
appropriate that TENEX was invented by a company whose initials can
stand for BIG BAD NEIGHBOR.

I have not been this mad in some time.  What the hell do we develop
standards for, if we will be asked not to use them?

                Richard H. Gumpertz

An aside to Charlotte Mooers:  what does Calvin think of all this?

Date: Wednesday, 7 March 1979  03:21-EST
From: MTRAVERS at BBN-TENEXD (Mike Travers)
Subject: Re: ARPA "order" and white-space in names
To: Gumpertz at CMU-10A
Cc: Howard Wactlar at CMU-10A, ADAMS at USC-ISI, MSGGROUP at MIT-ML,
Cc: Header-People at MIT-MC, Newcomer at CMU-10A, Reid at CMU-10A
In-reply-to: Your message of 7-Mar-79 0218-EST

In point of fact, TENEX and TOPS20 are perfectly capable of
having spaces in file names, by quoting them in the same
manner in which lowercase chars are quoted.  Making the mail
systems such as HERMES capable of generating such files is
another matter, of course.

Also in regards to RFC733 and ARPA policy, I was told
(indirectly) that ARPA does NOT plan to make this a
bonafide, standardized standard, and they are going around
telling people not to bother upgrading their  software to
handle/generate RFC733 messages.  The mailsystem I use has
just been modified to conform to RFC733, and I find it
extremely annoying that now that I have conformed to the
standard, I get complaints from HERMES users that they can't
parse my messages, and HERMES people tell me they are not
supposed to fix it.  Does anyone know more about this
situation?

--Mike
-------

Date: 7 MAR 1979 0635-EST
From: CBF at MIT-MC (Charles Frankston)
Subject: Subject fields
To: HEADER-PEOPLE at MIT-MC

As a random aside, for subjects without message fields, the ITS Rmail
program does use the first line of the message as the subject for
a summary request.  This usually works out quite well.  It goes through
a little pain to skip over whitespace and stuff and try and get a good
first text line though.

Date: 7 MAR 1979 0643-EST
From: CBF at MIT-MC (Charles Frankston)
Subject: keywords
To: HEADER-PEOPLE at MIT-MC, Frankston.Frankston at MIT-MULTICS

Keywords are often local to the eye of the beholder.  I think perhaps
it is more useful if the reciepient chooses his own keywords to file
it under after he has read the message.

Date: 7 MAR 1979 1029-EST
From: Charles Frankston at MIT-MC
Sent-by: CBF at MIT-MC
To: Richard H. Gumpertz at CMU-10A, Howard Wactlar at CMU-10A
CC: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-ML
CC: Joe Newcomer at CMU-10A, Brian Reid at CMU-10A, ADAMS at USC-ISI

If what is being said about this "ARPA order" is true, I find it disturbing.

Firstly, RFC733 was one of the most democratically adopted standards I know
of.  I don't really care if it has been "blessed" by the Arpa bureacracy or
not.  Its design at least had widespread input and comment.  The standard
may not be universally loved, but it has been pointed out before that almost
all of the non-Tenex/Tops-20 sites have taken steps toward adhereing to it.

Now, we hear that some bureaucrat has ordered that CMU cannot do something
that RFC733 specifies as legal, presumably because his (and perhaps other)
mail reading program cannot handle them.  Also presumably, these mail reading
programs run on Tenex/Twenex, the operating system Arpa has tried so hard to
get CMU, MIT and Stanford to run as the network standard operating system.
Fine network standard operating system.  The system with the most installations
on the network, that in total most recieve the most Arpa support, cannot
find the manpower to correctly implement a widely adopted network standard.

I would like to hear Arpa's official position clarified soon.  I think it
is a very poor idea for them to simply decide that one aspect of the standard
is null and void.  That jeapordizes the whole idea of decent coherent standards
and threatens to push us back to the dark ages before RFC733 when a new mail
system implementor could first review a bunch of contradictory, incomplete
and confusing standards, and then have to take a survey of the network to
find out how many different ways it was implemented.

I should point out that the change being demanded is retrogressive.  It
takes away capabilities.  I point this out mainly to differentiate this
"order" with the request the ITS and Multics sites have been making to
support a progressive change to allow structured recipients.  (Note, the
structured recipient request was made during the drafting of RFC733 and
ignored by the committee supposedly chosen by Arpa to draft the standard.
I presume no one asked for the space restriction then, because I cannot
believe that committee would have adopted something so difficult to
implement on Tenex, but perhaps I am wrong).

In any event, I will admit the point to be minor, and CMU could probably
live without it.  In fact, the ITS rmail program never was modified to
reply them correctly either, because the change was actually somewhat
painful.  This dicussion have motivated me to rectify that.  As of today,
ITS Rmail will correctly reply to CMU headers.  The pain proved to be
about 2.5 hours worth of work.  Thanks to Dave Moon, MC will now recieve
incoming mail to addresses with imbedded spaces  (he did that in about
5 minutes I guess).  The rest of the ITS sites should do the same in a
few days.

Date:  7 Mar 1979 1048-EST
From: Rick Gumpertz at CMU-10A
Subject: new ITS RMAIL
To:   Charles Frankston at MIT-MC
CC:   Header-People @ MIT-MC
Message-ID: <07Mar79 104824 RG02@CMU-10A>
In-Reply-To: Charles Frankston's message of 7 Mar 79 10:29

By the way you didn't respond correctly -- the correct response
would have gone to Gumpertz at CMU-10A not Richard H. Gumpertz at CMU-10a.
My note had a REPLY-TO field in it.  Another little test of people's mail systems
that I was running!

                Rick
 

Date: 7 MAR 1979 1129-EST
From: EAK at MIT-MC (Earl A. Killian)
To: HEADER-PEOPLE at MIT-MC

I've been wondering in all the flurry of messages about flushing
RFC733 whether that's actually more work than fully adopting it.  For
example, did the people that asked CMU to stop sending its two word
names consider the possibility that it might be more difficult stop
what they're doing now than it would be to fix Hermes?

Btw, I'd be interested to hear from the CMU people if ARPA is going to
provide funding for them to remove their two (or more) word names from
ARPAnet headers.  If the Hermes people can use "lack of funding" as an
excuse for not implementing them, then can't CMU use the same excuse
for not de-implementing them?

Date: 7 Mar 1979 1114-PST
Sender: GEOFF at SRI-KA
Subject: ARPA "orders", white-spaces, RFC733 and HERMES.
From: the tty of Geoffrey S. Goodfellow
To: Adams at ISI
Cc: Everhart at CMUA, Lamb at CMUA, rdmail at CMUA, 
Cc: Newcomer at CMUA, MSGGROUP at ML, Header-People at MC
Message-ID: <[SRI-KA] 7-Mar-79 11:14:21.GEOFF>
Reply-to: Geoff @ SRI-KA

	
Duane;

   I would like to ask you to please reconsider your asking CMU to
eliminate the two-name field (also referred to as the "white-space")
from mail they transmit.

   Currently what CMU does is completely legal within the "THE
STANDARD" -- RFC733.  I think it is rather unjust of you to ask them
to remove the two-name field from mail they send just because HERMES
(which, by the way, I use as well) cannot parse their headers when you
try to use the REPLY command on such a message, but rather the correct
and right approach would be to have the HERMES maintainers (BBN)
modify HERMES to handle the "completely legal" headers they send.

   This brings me to the point of HERMES and RFC733 in general.
Currently, I believe that HERMES does not support RFC733 at all, and
in fact, in some ways actually violates it!  An example of this would
be if you were to REPLY to this message, HERMES would get my name NOT
from the "REPLY-TO:"  field as it should, but from the "SENDER:"
field, which, according to the standard, is explicitly prohibited.
Hence, i think it is rather important that HERMES be made 733
compatible.  If that was the case today, you wouldn't have the problem
you now have with CMU.

   One of the big problems with getting this done as I have come to
understand it is that BBN will not touch HERMES or improve it unless
you wave the almighty dollar (aka funding) in front of them.  I for
one would be curious to know just how many sites that do support
RFC733 were funded by ARPA to do so, or even more interesting would be
just how many sites that have any type of a mail system at all were
funded by ARPA to design, code, debug, implement, maintain and have a
running mail facility that allows them to communicate with users on
their host computer as well as with the rest of the network?  I would
suspect there is only one possible and that being TENEX, even though i
understand SNDMSG (first TENEX mail sending program) came about
originally just as every other mail system on the network:  Out of the
pure NEED for one user to communicate with another, and then when
hooked up to the network, the sites mail system wizard spent his own
time, or on the time of the org.  he works for making his mail system
talk to the ARPANET.

  On the subject of RFC733, simply put/asked:  JUST IS IT A STANDARD
OR NOT?  Jon Postel says it is, and he is the keeper and final word on
standard right or wrongs, that i am currently aware of.  Yet, others
have told me, and i have heard rumblings from various corners of the
net, that NO , 733 is not a standard.  Please, tell us, for once, and
for all, which it is?  I presume, at least, that you are the person
who has that say-so?

  Lastly, on the subject of HERMES, 733, et al.  If BBN is unwilling
to modify HERMES to handle CMU's two-name from field (and support
RFC773 totally, without mega dollars flowing forth) at least have BBN
make the sources for HERMES available so that gainful hackers like
myself and others who enjoy doing things out of the pure interest of
network standardization and for the sheer "fun of it" can FREELY do
so, without have to tolerate institutions that refuse to do such
things because they are not funded to.

geoff

Date: Wednesday,  7 Mar 1979 1658-EST
From: David Lamb at CMU-10A
Subject: The ARPA whitespace "order"
Sender: RdMail at CMU-10A
To:   Header-people @ mit-mc, MsgGroup @ usc-isi
CC:   Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A,
      Nelson at CMU-10A
Message-ID: <07Mar79 165838 RD00@CMU-10A>

CMU will be complying with ARPA's request to remove whitespace in
names generated by our RDMAIL program.  I hope to head off what could
turn into an acrimonious debate by explaining why we are doing so.

When CMU converted to full compatibility with RFC733, we also began
to make use of a number of the facilities that a number of other
sites hadn't implemented.  For example, we supplied an option to
include a user's login PPN as a comment, for cases where someone had
many accounts and wanted to let his friends see which hat he was
wearing this week.  Some sites didn't parse that sort of thing, so
people who wanted to communicate with such sites simply turned off
the option.

We also decided to use a person's full name as the "recipient"
portion of a local mail name.  We have many cases where people with
the same last name both have accounts.  Having the two names
separated by a space rather than a dot seemed like a nice piece of
human engineering that was allowed by the standard, at least as we
read RFC733.  Unfortunately, a lot of other sites didn't see the
standard as allowing that, and so didn't include it in their mail
systems (I am told it isn't just Hermes, so I see no good reason for
singling Hermes out.  It merely happens that Hermes users were more
vocal in their complaints).

We weren't simple ordered by ARPA to make the change.  It was
discussed with our local site manager.  CMU is the only site on the
net which generates recipients with imbedded spaces.  From the point
of view of anyone managing time or money, it makes more sense to have
one site make a change rather than many, especially if the change is
as small as this one is (I expect to take a total of about 1/2 hour
to make the change).

It bothers me to some extent that ARPA seems to be "revising" the
"standard", making "retrogressive" changes.  I sympathise with anyone
who feels like their democratically-arrived-at standard is being
changed by apparently arbitrary bureaucratic fiat.  But there is a
whole other way of looking at the situation.  From the point of view
of the ARPA people who made the request, there was a protocol problem
that was interfering with people's work, making some network
communication difficult.  Given the problem, the least expensive way
to fix it was to ask the single site to change, rather than the many.

It is certainly possible to bewail the degree to which people violate
the RFC733 standard.  On the other hand, it should be obvious from
the recurrent heated debates that RFC733 is easy to misinterpret.
It's easy to point the finger at someone and say "you are violating
paragraph 3.4.1 of the standard", but that still leaves the practical
everyday problems of finding someone with time, energy, and
willingness to do the programming to make the change.  I'm willing to
fight for conformity when the piece of the standard in question is
important to me, but parenthesised comments and blanks in names just
aren't significant enough to me to fight for.

I also can't believe it will get us anywhere to accuse Hermes sites
of laziness (or whatever).  Even if Hermes is the only system that
has trouble with CMU headers, the fact that the problem has to be
fixed on many sites means it's more work than fixing it here.  Even
if one site changes the source and passes on the change, there's
more work.  I am speaking here of this one change, which is probably
fairly easy to make at either end;  a big enough improvement in
functionality would make that kind of multisite change worthwhile.

I don't think that anyone need worry too much that ARPA might be
"sabotaging" RFC733.  The requested change is small;  it's a direct
result of the January meeting; it's one of the few RFC733-related
problems that have really been interfering with communication.

I'd rather not be included in direct replies to this note;  I see
everything that gets sent to the CMU RDMAIL account, which
includes everthing that goes to the MSGGROUP and HEADER-PEOPLE
mailing lists.

                David Alex Lamb
 

Date: Wednesday,  7 Mar 1979 1743-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: Header People, RFC733, etc.
To:   Header-people @ mit-mc, MsgGroup @ usc-isi
CC:   Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A,
      Nelson at CMU-10A
Message-ID: <07Mar79 174335 BR10@CMU-10A>
In-Reply-To: <07Mar79 165838 RD00@CMU-10A>

I am pretty bummed out at all of the time that I have wasted on this
"standard", and I suspect that Dave, Jon, and company are even more
bummed out by it all.  I think that CAHCOM had absolutely no business
soliciting help from the Arpanet community in the design of this
standard, letting hundreds of man-hours get spent fine-tuning a very
nice, reasonably consistent, and very usable standard, and then
abandoning it.

Human-readable but machine-processed ASCII headers are the wrong way
to do computer mail anyhow; perhaps the general low quality of the
current Arpanet mail systems that is resulting from our having to be
compatible with this incompetent Hermes program will ultimately end
up being a blessing, resulting in a redesign instead of an
incremental upgrade.

Brian

Date:  7 March 1979 20:23 est
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject:  message ids
To:  header-people at MIT-MC
Message-ID:  <790308012331.101307 at MIT-Multics>

It's been a long time since I've flamed about message ID's.  I've
modified my personaal mail checking program to use some herutistics to
catch duplicates and it has worked fine.  I have just received a letter
sent without a subject line from EAK at MIT-MC to header-peole and
redistributed by GEOFF at SRI-KA to MSGGRP.  It would have been nice to
have a message-id to give me a reasonable chance of detected the
duplication.

BTW, now that people have seemed to standardize on using both
header-people and msggroup, why do we have both?

Date:  7 Mar 1979 2230-EST
From: Rick Gumpertz at CMU-10A
Subject: Re: The ARPA whitespace "order"
To:   David Lamb at CMU-10A
CC:   Header-People @ MIT-MC
Message-ID: <07Mar79 223057 RG02@CMU-10A>
In-Reply-To: <07Mar79 165838 RD00@CMU-10A>

David.-

Just.for.the.record,.I.think.you.are.making.a.big.mistake.

................Rick

Date:  7 Mar 1979 2240-EST
From: Rick Gumpertz at CMU-10A
Subject: RFC733 compliance
To:   Header-People at MIT-MC
Message-ID: <07Mar79 224039 RG02@CMU-10A>

I.have.a.couple.questions.that.might.be.able.to.elicit.some.useful.information:

1).Why.can't.Hermes.be.easily.modified.to.handle.the.spaces?..What.is
...the.technical.obstacle?

2).Who.maintains.Hermes?..Is.it.multiple.persons?..Have.they.no.funding
...or.is.that.a.red-herring?

3).What.systems.besides.Hermes.have.trouble.with.white-space,.if.any?

................Rick
 

Date: 7 MAR 1979 2311-EST
From: RMS at MIT-AI (Richard M. Stallman)
Subject: Header People, RFC733, etc.
To: MsgGroup at USC-ISI, Header-people at MIT-MC
CC: Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A
CC: Nelson at CMU-10A

Using the first name as well as the last one is certainly a good idea.
It's one of Tenex's real losses that (at most sites) it ALMOST lets
you refer to a person by his last name - but maybe you have to use his
initial as well, and how can anyone predict?  Maybe his login is his
last name, or maybe it's his initial and last name.  Whereas ITS and
CMU, where the login and last name are usually or always different,
don't have available any easy way out that only almost works, so they
have special provisions that really do let you refer to a person by
last name in mail.  But that still leaves a problem of disambiguation.
Only CMU has implemented a reasonable solution to the problem.
I think that the CMU way is the only really right way to deal with it:
let a person give the last name, or both names, and win as much as
possible with whatever it gets.
What COMSAT does is, if you send a message to an ambiguous lastname
such as Frankston, send the message to all of the possibilities,
which solves things for the most part but is clearly not right.

To ask for the only winning solution to the problem to be banned
because it is ahead of the rest of the world is stifling and wrong.
And I can speak as one whose mail reader didn't (until yesterday)
understand CMU headers:  I would rather have my own system lose on
them indefinitely and hope to make it win someday (as it finally does)
than ask someone else to lose for my sake.  The Tenex people who
aren't willing to do as much for someone else's winning idea deserve
no sympathy.

The way to resolve such disputes between different systems is simple:
change whichever ones don't do things right.  Assuming you believe
that progress beyond the current perfection is possible.


Date: 7 MAR 1979 2319-EST
From: JNC at MIT-AI (J. Noel Chiappa)
Subject: Livable Computers & all that...
To: Rick Gumpertz at CMU-10A
Remailed-To: MsgGroup @ MIT-ML, Header-People @ MIT-MC
Remailed-From: Rick Gumpertz at CMU-10A
Remailed-Date:  7 Mar 1979 2321-EST

	Incredible!! We finally get a computer mail system that will
handle peoples NAMES, for God's sakes, and it gets flushed. Foo!
We DESERVE to be looked at as inhuman  etc. etc.
			Noel
PS Keep.it.up.withe.the.".".action..I.love.it!!
   

Date: Wednesday,  7 Mar 1979 2351-EST
From: David Lamb at CMU-10A
Subject: CMU mail names
Sender: RdMail at CMU-10A
To:   RMS at MIT-AI (Richard M. Stallman)
CC:   MsgGroup @ usc-isi, header-people @ mit-mc
Message-ID: <07Mar79 235139 RD00@CMU-10A>
In-Reply-To: Richard M. Stallman's message of 7 Mar 79 23:11

ARPA isn't really asking us to get rid of our first names (at least,
as I interpret the request); they merely want us to send
David Lamb at CMU-10A
as
David.Lamb at CMU-10A
which, as you might suspect, is a trivial change for us to make.  We
still have some loopholes we don't intend to change that allow
C410BR10 to appear as "Brian K. Reid" instead of "Brian.Reid", but
that comes down to a personal decision on the part of individual
people to generate headers that Hermes can't handle.  All we are
doing is making the default behaviour something that (a) Hermes can
handle (b) isn't too different from what we have now.

I do appreciate your praise of our mail names, though.  Even though
our login names are horrid, our Mail system, Finger program, and
Systat all manage to treat people as names rather than bizarre
character sequences.  There's even some hope of eventually being able
to log in via name rather than by CMU PPN, but that's a lot more work
than we can foresee in the near future.  It's all done via table
lookup in a large binary file, but even so seems to work well and
reasonably efficiently.
  

Date:  8 Mar 1979 0015-EST
From: Rick Gumpertz at CMU-10A
Subject: Redistribution
To:   GEOFF at SRI-KA
CC:   Header-People at MIT-MC, MsgGroup @ mit-ml
Message-ID: <08Mar79 001529 RG02@CMU-10A>

Geoff -

I tend to choose my destinations carefully.  In particular, I saw no
reason to distribute some of my latest mail to MsgGroup.  I am trying
to keep down the amount of junk mail.  Please refrain from
redistributing mail unless you have a good reason.

                Rick
   

Date: 8 MAR 1979 0016-EST
From: TVR at MIT-AI (Tovar)
Subject: You are not alone
To: Rick Gumpertz at CMU-10A
CC: HEADER-PEOPLE at MIT-AI


SAIL was also an early implemention of 733.  And...

-----

    Date: 7 Mar 1979 2021-PST
    From: Hans Moravec <HPM at SU-AI>
    To:   TVR at MIT-AI    

    [Text of message omitted.]

-----

As far as i know, there is currently no maintainer of SAIL's mailer.

The problem with spaces in names is of little personal concern to me
as i have problems with bureaucrats who insist that there must be a
space in a person's name.  Nonetheless, i would certainly hate to
have to send mail to John.L.Smith or Brian.K..Reid.

All i can say to HERMES users is:  "You think this is bad, just wait
until you have to cope with inter-network mail!"

							--- Tovar

P.S. In reply to Msd-id comment:  Many of the headers i've seen
lately are twice as long as the messages they contain!


Date: 7 Mar 1979 2121-PST
Sender: GEOFF at SRI-KA
Subject: Re: Redistribution
From: the tty of Geoffrey S. Goodfellow
To: rg02 at CMUA
Cc: Header-People at MIT-MC, MsgGroup at MIT-ML
Message-ID: <[SRI-KA] 7-Mar-79 21:21:30.GEOFF>
In-Reply-To: <08Mar79 001529 RG02@CMU-10A>
Reply-to: Geoff @ SRI-KA

good reason: no one on header people would beable to answer your
questions about HERMES policy issues, re:
why.cant.hermes.be.modified.to.handle.spaces.and.who.maintains.hermes.
things.for.people.not.on.header.people,like.adams.and.other.bbn.folk.

Date:  8 Mar 1979 0404-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: A plea for sanity
To: Header: ;, Header-People at MIT-MC, MsgGroup at MIT-ML

Please, let's stop sending messages to both MsgGroup and Header-People.
It is getting awfully silly getting four or five copies of the same
message.  Let's leave outrageous flaming messages with Header-People
where they belong and not assault MsgGroup with the crud.  I really
think that MsgGroup exists for other purposes than flaming.

My mailbox is growing on the average of 50 messages/day due to this
multi-forwarding.  And please, no comments about message-id's; instead
of kludging around extra message copies let's not send them in the first
place!!

I hope I'm not going to get infinite retributions about being hypocritical
by sending this message to both.  I might as well do it rather than let
somebody else forward it with HERMES and add three or four more header
lines to the nth extra copy.

-- Mark
-------

Date:  8 Mar 1979 1326-PST
From: Zellich at OFFICE-1
Subject: Re: ARPA "order"
To:   Wactlar at CMU-10A
cc:   Header-People at MIT-MC

Please clarify a point for me -- Is it only the form
  Howard Wactlar at CMU-10A
that they want changed to 
  Howard.Wactlar at CMU-10A

or do they ALSO want
  Howard Wactlar <WACTLAR at CMU-10A>
changed to
  Howard.Wactlar <WACTLAR at CMU-10A>
?
Rich
-------

Date: 8 Mar 1979 2:18 pm (Thursday)
From: Karlton at PARC-MAXC
Subject: White space in tokens
To: Header-People at MIT-MC, MsgGroup at USC-ISI
cc: Wactlar at CMU-10A, RdMail-Maintainers: (RDHACK.DST[A800RD00]) Rdmail
 at CMU-10A, Craig Everhart at CMU-10A, David Lamb at CMU-10A, Philip
 Lehman at CMU-10A, Bruce Nelson at CMU-10A, Brian Reid at CMU-10A,
 Karlton @ PARC-MAXC, Sapsford @ PARC-MAXC;

People and Flamers,

I have enjoyed the conversations over the past couple years going
through Header-People and MsgGroup and I wish once again to add
a comment.

A great deal of time and effort went into constructing RFC733. Many
hard feelings were smoothed only due to the passage of time.  The
important thing is that a useable (not the end-all, be-all) standard was
generated.  This was done under the guise that the final result would
become a recognized standard.  I was assured of this more than once.
In fact, my introduction to Header-People was because of complaints
that CMU was not in compliance with RFC561.  RFC724, a precursor
to 733, even had as a title "Proposed Official Standard for the Format
of ARPA Network Messages."  When I added 733 compatible headers
to RdMail I really thought that it had become "Official".

It is not necessary to have CMU prohibit the sending of mail that
contains white space in the delivery tokens.  The user can specify
how he/she wants the name to appear in the outgoing messages. 
(There even exists a profile switch that will cause the CMU
programmer-number to be used as the delivery token.)  Any user at
CMU that wishes to generate First.Last instead of First Last can do so
(and is not a particularly onerous task, but does involve the spending
of the time to do so).  Allow me to quote from the November 1978
version of the RdMail manual.
   If you do a lot of communicating with people at TENEX
   sites, it is suggested that you have no embedded blanks in
   your name-- use periods instead.
This was done since the then existing systems (soon to be replaced!)
could not cope with embedded spaces.

I really am at a loss as to why HERMES is not fixed to handle this spaces. 
It was undergoing development at the time that 733 came out.  It was
written with the programming technology of 1975.  I question the technical
competence of a project leader that would allow the parser to be so
inflexible that making this seemingly trivial change is a hard task. 
What has happenned to pride of craftmanship?  No one builds bug
free systems (in the technology available right now), especially those
that have to deal with user interface issues.  It has been my experience
that any program that is being used all the time grows as its users'
needs expand.  Sometimes it is overwhelmed and a new program has
to be written to take its place.

PK

p.s. RdMail-Maintainers:  I request that you do not change RdMail
so that people can no longer send out their names in the format that
they wish.  You might wish to undertake an education task at CMU,
but please do not remove that feature from a program that I still
consider (perhaps no longer rightfully) mine.  If you still think that
it is necessary to remove that feature, then I implore you to poll your
users and ask them if they are willing to do without because those
that communcate over the net are unwilling to learn how to set
their user profile.

Date: 8 Mar 1979 1958-PST
Sender: GEOFF at SRI-KA
Subject: Re: White space in tokens
From: the tty of Geoffrey S. Goodfellow
To: Karlton at PARC-MAXC
Cc: Header-People at MC, MsgGroup at ML, Everhart at CMUA, 
Cc: Lamb at CMUA, Sapsford at XEROX-PARC
Message-ID: <[SRI-KA] 8-Mar-79 19:58:18.GEOFF>
In-Reply-To: Your message of 8 Mar 1979 2:18 pm (Thursday)
Reply-to: Geoff @ SRI-KA

	
Re: "What has happenned to pride of craftsmanship?"
Apparently it ran out the same time funding did.

Date:  9 Mar 1979 0315-EST
From: Rick Gumpertz at CMU-10A
Subject: Charlotte Mooers at BBN
To:   Header-People @ MIT-MC
Message-ID: <09Mar79 031510 RG02@CMU-10A>

I got a note from Charlotte Mooers a few days ago.  She is out of town
and promises to send a considered message next week.  I am amazed she
can restrain herself, but perhaps that explains the mysterious silence from
BBN -- noone but the liason dares say anything.

                Rick
  

Date: 15 MAR 1979 2338-EST
From: KLH at MIT-MC (Ken Harrenstien)
Subject: Delivery glitch
To: HEADER-PEOPLE at MIT-MC

Due to some unknown person's mis-edit of the header-people
mailing list, 4 messages failed to be forwarded on.  I've
included the times, sources, and text lengths below so
that the originators can resend their messages, and rearranged
a few things here so that in the future such re-sends shouldn't
be necessary.

3/14 19:08:38 From PARC-MAXC TL=5320. ID=<[MIT-MC].366772>
3/15 13:56:15 From PARC-MAXC TL=560. ID=<[MIT-MC].367196>
3/15 16:50:30 From CMU-10A TL=274. ID=<[MIT-MC].367287>
3/15 17:13:35 From CMU-10A TL=255. ID=<[MIT-MC].367296>

Date: Thursday, 15 Mar 1979 1648-EST
From: Brian.K..Reid <BR10 at CMU-10A>
Subject: ARPA request for compliance (RFC)
To:   Header-People at MIT-MC
Message-ID: <15Mar79 164847 BR10@CMU-10A>
Remailed-To: header-people at mit-mc
Remailed-From: Brian.K..Reid <BR10 at CMU-10A>
Remailed-Date: Friday, 16 Mar 1979 0123-EST

CMU's mail program has now been changed to put the dots in people's names.

Date: Thursday, 15 Mar 1979 1700-EST
From: 220-54-1647 <Brian.Reid at CMU-10A> (C410BR10)
Subject: alternate name forms
To:   Header-people at mit-mc
Message-ID: <15Mar79 170041 BR10@CMU-10A>
Remailed-To: header-people at mit-mc
Remailed-From: Brian.K..Reid <BR10 at CMU-10A>
Remailed-Date: Friday, 16 Mar 1979 0124-EST

But we can always use our social security numbers.....
   

Date: 15 Mar 1979 2248-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: dots in front of my eyes
To: Header-People at MIT-MC

Does ARPA seriously intend that everybody who uses headers such as the
headers in this message should replace the dots with whitespace?  Mumble.
I hated the idea of making mail headers hairier, but now that we have
this RFC 733 let's stick to it.

By the way, there are alternatives to HERMES for Tenex and Tops-20
winners.  There is a version of MSG which groks these fancy headers
which (I believe) has been sent to Vittal a while ago for distribution
to the world.  Also, for us Tops-20 people, there is a really neat new
mail reading program called MM which is small, fast, and seems to do
everything MSG does and more.  Anyway, it does everything I want to
do with my mail file.  Stuart Cracraft at SRI (McLure@SRI-KL) is the
contact for this program.

-- Mark

Social security numbers?  Sigh.
-------

Date:  16 March 1979 02:01 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re: dots in front of my eyes
To:  Mark Crispin <Admin.MRC at SU-SCORE>
cc:  Header-People at MIT-MC
In-Reply-To:  Msg of 03/16/79 01:48 from Mark Crispin
Message-ID:  <790316070128.630443 at MIT-Multics>

Are social security numbers worse than having to realize that Stuart
Cracraft at SRI is really McLure@SRI-KL??

Date: 15 Mar 1979 2312-PST
From: Stuart McLure Cracraft <McLure at SRI-KL>
Subject: re: dots in front of your eyes
To: Frankston.Frankston at MIT-MULTICS, Admin.MRC at SU-SCORE
Cc: Header-People at MIT-MC
In-reply-to: Your message of 16-Mar-79 0201-PST

Or that Frankston.Frankston@Mit-Multics is really ... ???
-------

Date: 15 Mar 1979 11:14 pm (Thursday)
Sender: Karlton at PARC-MAXC
From: Karlton at PARC-MAXC
Subject: Disclaimer
To: Header-People at MIT-MC
Original-Date: 15 Mar 1979 10:55 am (Thursday)

Due to a misunderstanding that was brought to my attention I feel the
following is in order.

The opinions I expressed yesterday are my own and not that of any
organization.  I am an ex-member of the CMU community and am not in
daily contact with them and my thoughts should not be interpreted as
coming officially from CMU or representing the thoughts of the students
as a whole or any other CMU group.

PK

Date: 15 Mar 1979 11:13 pm (Thursday)
Sender: Karlton at PARC-MAXC
From: Karlton at PARC-MAXC
Subject: Further comments on no LWS request to CMU
To: Header-People at MIT-MC
Original-Date: 14 Mar 1979 4:01 pm (Wednesday)

I must be getting old.  I decided to wait a week and calm down before
mailing my second letter about the request to CMU to prevent having
linear white space in recipient names.

First I think you should see what the hackers at CMU proposed to do.  I
have taken the liberty to edit some comments from the following
message.

------------------------------------------------------------
Date: Thursday,  8 Mar 1979 1936-EST
From: Craig Everhart at CMU-10A
Subject: Re: White space in tokens
To:   Karlton at PARC-MAXC
Message-ID: <08Mar79 193622 CE10@CMU-10A>
In-Reply-To: Karlton's message of 8 Mar 79 14:18

[...]  Allow me to describe the planned method of handling the request.

Basically, we don't restrict RDMAIL in ANY way from its current state.
However, [...]  we're taking the following tack.  There shall be a
distinguished version of RDMAIL, which will be the first version that
will attempt to comply with the request.  When RDMAIL is invoked, and
it sees that it is incrementing the last-RDMAIL- version-used-on-this-
file number over this distinguished number, it will clear out the
user's name stored in the .MSG file.  Then, for both this kind of
cleared name, and the kind that you get because you're creating a .MSG
file, the user name will be generated as "Philip.Karlton" and stored
into the .MSG file as such.  (This will overwrite, for instance, "Mary
Shaw", "JON BENTLEY", and "Brian K.  Reid".)  When it does this, it
will tell you so, in a warning message, probably.  In any case, the
user is then perfectly free to change his/her name BACK to whatever
he/she pleases; the point here is to catch those people who have never
done the PROFILE command as well as those who do it every week.  ALIAS
and FROM will be left untouched.

[... paragraph deleted... PK].

Along with these program changes, we'll have to (once more!)  stress
that there are [...]  mail readers on the network, and that if a user
generates fancy headers (and they'll have to do this, explicitly, after
this RDMAIL comes up, [...]), then they take the responsibility for the
difficulty their correspondents will have in using the [...]  replying
systems.

[... four more paragraphs deleted ... PK]

                Craig
------------------------------------------------------------

First I would like to point out that this solution will not work.  The
trouble is that just changing the senders name to not contain LWS is
insufficient.  All the names in the recipient lists must also be
coerced to not contain LWS.  Letting a CMU header (excuse the
expression) out onto the net would be considered as ill mannered as
letting an ITS header out.  This could be done by changing the names
that contain LWS and have a destination site of CMUxxx.  (What should
be done for names with LWS that are not going to CMU?)  This will annoy
the user who types a carefully considered list of names only to have
the format changed by the program to one that is acceptable by the
outside network when the user knows that the original is acceptable to
the local mail handling program..

The following represents my best guess, and might be far from the
truth.  What happened is that some administrator came up to CMU's
operations manager at a meeting someplace and asked that CMU stop
sending out those "funny" headers that had LWS in the names.  Agreeing
to do this probably did not seem like much of an imposition since CMU
accepted "First.Last" in place of "First Last" anyway.  Not much
thought was given to what was actually being asked or to what the
implementation details would be.

The crux of the entire matter, to me at least, is whether or not RFC733
is a network standard.  If it is not a standard, then an explanation is
due to many people and an apology to those that actually produced 733.
If it is a standard, then the request to CMU to remove LWS was
completely out of order.

If 733 is to be replaced, then it should be replaced and a new standard
should be issued.  Vague wishes like "Make your program generate stuff
my program can understand."  make it impossible for the implementor.  I
have already had the misfortune of producing software to a floating
goal and found that an extremely frustrating experience for both me and
the client.  If what HERMES will parse is to become the standard for
network mail then a specification of that should be published.  Does
HERMES handle Reply-To:  fields?  Names in <>'s?  Sender:  fields?

It does not seem reasonable for CMU to go in and fix up the sender
names not to have LWS just to have someone complain that CMU is still
sending bogus headers.  If what happened is that BBN was asked to write
a program for money (which is not a dishonorable thing to do as some
have implied) and were told to just ignore the header controversy, then
they should not be surprised that tempers flare when people get told
that their work (and generating 733 was real work) was wasted and that
no one (important) was going to pay attention anyway.

PK

Date:  16 March 1979 02:30 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re: re: dots in front of your eyes
To:  Stuart McLure Cracraft <McLure at SRI-KL>
cc:  Frankston.Frankston at MIT-Multics, Admin.MRC at SU-SCORE, 
     Header-People at MIT-MC
In-Reply-To:  Msg of 03/16/79 02:12 from Stuart McLure Cracraft
Message-ID:  <790316073013.198152 at MIT-Multics>

I apologize for not knowing your middle name.  There is no strong rule for what is a good name (or alias).
Admittedly the social security number is one of the more obscure.  Same goes for phone numbers
for that matter.  At least there is a standard way of going from person name to phone number,
provided you know precisely where that person lives.  I can appreciate the middle name as an identifier.
There are a number of people who know me solely as Matthias (my middle name).  One, in fact, became confused
when he found that the two differnt people he know of, Bob Frankston and Matthias were me.


Date:  16 March 1979 02:30 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re: re: dots in front of your eyes
To:  Stuart McLure Cracraft <McLure at SRI-KL>
cc:  Frankston.Frankston at MIT-Multics, Admin.MRC at SU-SCORE, 
     Header-People at MIT-MC
In-Reply-To:  Msg of 03/16/79 02:12 from Stuart McLure Cracraft
Message-ID:  <790316073028.513056 at MIT-Multics>

damn non defaulting to fill rreply command!

Date: 15 Mar 1979 2348-PST
From: Stuart McLure Cracraft <McLure at SRI-KL>
Subject: more dotz
To: frankston.frankson at MIT-MULTICS
Cc: header-people at MIT-MC

	Mail from MIT-MULTICS rcvd at 15-Mar-79 2330-PST
	Date:  16 March 1979 02:30 est
	From:  Frankston.Frankston at MIT-Multics
	Subject:  Re: re: dots in front of your eyes
	To:  Stuart McLure Cracraft <McLure at SRI-KL>
	cc:  Frankston.Frankston at MIT-Multics, Admin.MRC at SU-SCORE, 
	     Header-People at MIT-MC
	In-Reply-To:  Msg of 03/16/79 02:12 from Stuart McLure Cracraft
	Message-ID:  <790316073013.198152 at MIT-Multics>

To me, any combination of full last, middle or first is far more
preferable than numbers. By the way, why is your mail system
propagating the Re's in the subject field? It should not
care about the upper/lower case distinction when parsing that
field. 
-------

Date:  16 March 1979 03:51 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re: more dotz
To:  Stuart McLure Cracraft <McLure at SRI-KL>
cc:  header-people at MIT-MC
In-Reply-To:  Msg of 03/16/79 02:48 from Stuart McLure Cracraft
Message-ID:  <790316085121.081379 at MIT-Multics>

1. You can send mail to bob@mit-multics.  Normally Multics cares
strongly about case.  It so happens that the network mail table has been
setup so that the entries are checked for in all upper case.  Thus if
you send mail to Frankston or frankston it would work.  But if you
include the "." the name would be converted to a Multics pathname and
must follow the strict conventions.

2. Again, case is the issue.  It does not recogize "re:" as being "Re:".
I have sent a note to the mail maintainers on this.  But actually it is
your mail system that should be consistant and capitalize "Re:".

3. I'm going to be in SF next week (and again in May and again in ??). 
Would be interested in visiting people on sites.  The official reason is
to attend IBM SHARE, but hopefully will have time this trip, or the next
trip (when I'll be at the West coast Computer Faire) to visit around.

Date: 16 Mar 1979 0324-PST
Sender: GEOFF at SRI-KA
Subject: Re:.ARPA.request.for.compliance.(RFC)
From: the.tty.of.Geoffrey.S..Goodfellow
To: BR10 at CMU-10A
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KA]16-Mar-79 03:24:33.GEOFF>
In-Reply-To: <15Mar79.164847.BR10@CMU-10A>
Reply-to: Geoff @ SRI-KA

B.L.E.T.C.H.!

Date: Friday, 16 Mar 1979 1036-EST
From: David Lamb
Subject: Re: dots in front of my eyes
Sender: RdMail at CMU-10A
To:   Mark Crispin <Admin.MRC at SU-SCORE>
CC:   Header-People at MIT-MC
Reply-To: RdMail at CMU-10A
Message-ID: <16Mar79 103654 RD00@CMU-10A>
In-Reply-To: Mark Crispin's message of 16 Mar 79 01:48

Actually, it's still quite easy to generate a non-dotted FROM field
at CMU.  You always get either a dotted REPLY-TO field, or a dotted
name in <> in the FROM field.  Of course if your name never had any
white space (like RDMAIL) you don't get any spurious dots.

The actual time spent on this little hack was about 3 hours looking
at code on my part (I'm the newest of the RDMAIL maintainers, and
wasn't familiar yet with the parts that needed to be changed), 1/2
hour looking at code on Craig Everhart's part, about 3 hours coding
and compiling (I made the mistake of trying the change in the
afternoon, when there are no cycles), and about 15 hours arguing with
people over whether we should do the change or not.  The
non-technical portions of this sort of thing take far more time than
the technical parts.

		David Alex Lamb
  

Date: Friday, 16 Mar 1979 1528-EST
From: Brian.K..Reid <BR10 at CMU-10A>
Subject: certification of computer professionals
To:   MsgGroup at USC-ISI, Header-People at MIT-MC
Message-ID: <16Mar79 152808 BR10@CMU-10A>

Now that the flaming about the certification of computer professionals
has pretty much died down (though such certification is still being
considered, of course) I offer these two news stories from today's AP
wire, with no further comment.

a023  0026  16 Mar 79
PM-Topic, Advisory,
Managing Editors:
Wire Editors:
    It all started in a tiny part of a computer program used by an
engineering firm designing nuclear reactors. It ended with the
shutdown of five nuclear power plants at a time when President Carter
is pushing oil conservation and the world oil market is in turmoil.
    The computer miscalculated some safety precautions required by law.
The power from the closed plants now will have to be replaced by
electicity generated with oil or coal. This may cost utility customers
money and throw a curve at Carter's conservation program.
    In Today's Topic: The Little Computer and the Big Problem, AP writer
Evans Witt traces this glitch in the system, from the obscure
computer to its possible effect on the nation's energy problems.
    The story, illustrated by Laserphoto NY7, is upcoming next.
    The AP
    
ap-ny-03-16 0328EST
***************

a024  0044  16 Mar 79
PM-Topic-Glitch, Bjt,950
TODAY'S TOPIC: The . yyter and the Big Problem
Laserphoto NY7
By EVANS WITT
Associated Press Writer
    WASHINGTON (AP) - Something just didn't add up.
    And the result is: five nuclear power plants are shut down; millions
of Americans may pay higher utility bills; and a sizable blow may
have been struck to President Carter's efforts to reduce the use of
imported oil and to control inflation.
    The immediate source of all this is part of the federal bureaucracy
- the Nuclear Regulatory Commission which ordered the shutdowns.
    But in one sense, the ultimate culprit was ''Shock II,'' a tiny part
of a computer program used by a private firm to design the power
plants' reactors.
    Shock II was wrong and that means parts of the five reactors might
not survive a massive earthquake. Shock II was the weak link that
could have allowed the chain to snap.
    In between Shock II and the shutdowns were a public utility, a
private engineering firm and the NRC staff. It was really the
judgments of the dozens of scientists and engineers, not elected or
appointed officials, that led to the shutdowns.
    Perhaps as a result, the decision's impact on the nation's energy
situation was not even considered until the very last moment - when
the commission itself was faced with the final decision.
    And at that point, the NRC said, it had no choice. It said the law
was clear: serious questions about the reactors had been raised and
the reactors had to be turned off until answers were found.
    The specific questions are arcane engineering issues, but the
explanation is straightfoward: Will some of the systems designed to
protect the reactor survive an earthquake - or will they fail, and
possibly allow radioactive death to spew into the air?
    The regulations say the reactors must be able to withstand a quake
equal to the strongest ever recorded in their area. The regulations
don't allow any consideration of the likelihood of a major quake. All
four states where the reactors are located - New York, Pennsylvania,
Maine and Virginia - have had minor quakes in this decade and
damaging quakes at least once in this century.
    The only way to test them - short of having a massive earthquake -
is to test a model of the reactor. The ''model'' is actually a set of
mathematical formulas in a computer that reflect how the reactor and
its parts will behave in a quake.
    The model used for the five reactors came from Stone and Webster,
the large Boston engineering and architectural firm that designed the
plants. The Stone and Webster model indicated how strong and well
supported pipes had to be and how strong valves had to be.
    The problem apparently cropped up after Stone and Webster suggested
within the last few months more pipe supports in the secondary
cooling system of the reactor at Shippingport, Pa., operated by
Duquesne Light Co. in Pittsburgh.
    But why were the supports needed? ''This was not clear to us,
looking at the calculations done by the models,'' said Gilbert W.
Moore, Duquesne's general superintendent of power stations.
    So Dusquesne - and Stone and Webster - sent the computer models
through their paces again, having them calculate and recalculate what
would happen to the pipes in an earthquake.
    ''We came out with some numbers which were not in the range we would
like,'' Moore said.
    That made the problem clear - the model now said the pipes might
break in an earthquake. The previous analysis indicated an adequate
safety margin in the pipes, and Stone and Webster's explanation was:
''One subroutine may not give uniformly conservative results.''
    The problem was in a ''subroutine,'' a small part of the computer
model, called ''Shock II,'' said Victor Stello, director of NRC's
division of reactor operations.
    ''The facts were that the computer code they were using was in
error,'' said Stello. ''Some of the computer runs were showing things
are okay. In some cases, the piping systems were not okay.
    ''We didn't know the magnitude of the error or how many plants might
be affected,'' he said.
    It was on March 1 that Duquesne told the NRC of the problem by
telephone and asked for a meeting to discuss it. The same day, Energy
Secretary James R. Schlesinger was telling Congress that unleaded gas
might cost $1 a gallon within a year and service stations might be
ordered shut down on Sundays because of oil shortages.
    The meeting took place on Thursday, March 8, in Washington with NRC
staff, Stone and Webster engineers and Duquesne Light people on hand.
    Through the weekend, Stello said, engineers from NRC, Duquesne and
Stone and Webster worked at the private firm's Boston office,
analyzing the severity of the problem.
    ''By the middle of Sunday (March 10) we begin to get a pretty good
idea of what it meant for the systems,'' Stello said. ''Monday, we got
the latest information from our people at the Stone and Webster
offices. It became clear that there would be a number of the safety
systems that would have stresses in excess of allowable limits. The
magnitude of the excess was considerable.''
    Tuesday, members of the NRC were briefed by their staff of engineers
and scientists. They asked for an analysis of the economic impact of
the decision, and then ordered the plants closed within 48 hours.
    And the five reactors shut down: Duquesne Light Co.'s Beaver Valley
plant at Shippingport, Pa.; Maine Yankee in Wiscasset, Maine; the
Power Authority of New York's James Fitzpatrick plant at Scriba, N.Y.;
and two Virginia and Electric Power Co. reactors at Surry, Va.
    It may take months to finish the analysis of the potential problems
and even longer to make changes to take care of the situation.
    Until the reactors start generating again, the utilities will have
to turn to plants using oil or coal. This may cost more, and that cost
may be borne by the millions of utility customers.
    To replace the power from these nuclear plants could require 100,000
barrels of oil a day or more. And this at a time when President
Carter has promised to cut U.S. oil consumption by 5 percent - about 1
million barrels a day - and when the world's oil markets are in
turmoil because of recent upheavals in Iran.
    
ap-ny-03-16 0346EST
***************

 

Date: 16 Mar 1979 1534-EST
Sender: NMA at BBN-TENEXA
Subject: Re:  Re: more dotz
From: NMA at BBN-TENEXA
To: Frankston.Frankston at MIT-MULTICS
Cc: McLure at SRI-KL, header-people at MIT-MC, stef at SRI-KA
Message-ID: <[BBN-TENEXA]16-Mar-79 15:34:30.NMA>
In-Reply-To:  <790316085121.081379 at MIT-Multics>

YOU CASE SENSITIVITY FOLKS NEED A REORIENTATION TO THE WORLD.

IT IS THE REAL TRUTH THAT IF YOU WANT TO GET A MESSAGE ACROSS TO
A RECEIVER, IT IS YOUR RESPONSIBILITY TO PACKAGE IT SO HE CAN
CAPTURE THE MEANING.

OR IF YOU WANT PEOPLE TO COMMUNICATE WITH YOU, THEN YOU MUST MAKE
IT EASY AND CONVENIENT FOR THEM TO SO SO.

ANY OTHER ATTITUDE INHIBITS THE FLOW OF INFORMATION.  SEEMS TO ME
THAT WE ARE AFTER A MAXIMIZATION OF POTENTIAL CONNECTIVITY AND
POTENTIAL MOBILITY OF INFORMATION IN OUR BUDDING ELECTRONIC
DEVICE CONTINUUM.

THINGS LIKE CASE SENISTIVE MAIL RECEIVERS ARE CLEARLY COUNTER TO
THE GOAL.  OR CASE SENSITIVE FIELD NAME PARSING!  OR ALL THESE
OTHER PERSONAL STYLES THAT EACH OF YOU ARE BECOMING SO
EMOTIONALLY ATTACHED TO.  PERSONALY, I TAKE AFFRONT TO THOSE WHO
TELL ME THAT WHAT I WANT IN MY RECEIVED MAIL IS OF NO CONCERN TO
ME.  B.L.E.C.H!

BEST - STEF

Date:  16 March 1979 19:16 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re:  Re: more dotz
To:  NMA at BBN-TENEXA
cc:  Frankston.Frankston at MIT-Multics, McLure at SRI-KL, 
     header-people at MIT-MC, stef at SRI-KA
In-Reply-To:  Msg of 03/16/79 15:34 from NMA

Plesae don't shout.  Things are noisy enough here as is.

Yeah, Multics does accept mail to recipient names in the network table
even when shouted or in a mixture of shouted letters and unshouted ones.
However, internally it is very nice to be able to take advantage fo the
beauty of the full upper and lower case alphabets.

Date: 16 Mar 1979 1737-PST
Sender: STEF at SRI-KA
Subject: Re:  Re:  Re: more dotz
From: STEF at SRI-KA
To: Frankston.Frankston at MIT-MULTICS
Cc: header-people at MIT-MC
Message-ID: <[SRI-KA]16-Mar-79 17:37:47.STEF>
In-Reply-To: Your message of  16 March 1979 19:16 est

WHO IS SHOUTING?  JUST CAUSE I'M STUCK WITH THIS UPPERCASE YOU SAY I'M
SHOUTING.  GEEZ!

AND I SAID NOTHING ABOUT WITHHOLDING BEAUTY FROM THOSE WHO LOVE LOWER
CASE.  ALL YOU NEED DO IS DISPLAY IT THAT WAY FOR YOUR SELF.

JUST DON'T MAKE ME LEARN TO ESCAPE THIS BEASTLY TERMINAL SO I CAN SEND
YOU MAIL.  OR SO YOU CAN MAKE SENSE OUT OF IT (INCLUDING YOUR
PERSNICKETY PARSER THAT IS CASCADING THOSE "Re:"  THINGS IN THE SUBJECT
FIELDS.)

CHEERS - STEF

Date:  16 March 1979 20:45 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re:  Re:  Re: more dotz
To:  STEF at SRI-KA
cc:  Frankston.Frankston at MIT-Multics, header-people at MIT-MC
In-Reply-To:  Msg of 03/16/79 20:37 from STEF

1. Bug in parser is being fixed (I think may be fixed by now).

2. The beauty is not necessarily in theparticular graphics chose, but
rather in the variety and the expression possible iwth two  cases rather
than one.

3. We do accomdate cripple dterminals and system for receiving mail.  We
are, however, unable to read the mind of the sender and determine the
original form of the letter before being smashed into the LOUD version. 
Sorry, it is a religous feeling here that computers need not shout and
need not be congenitally defective.  While we can deal with tose that
are, we must also pity them.

Date: 16 Mar 1979 1757-PST
Sender: STEF at SRI-KA
Subject: Re:  Re:  Re:  Re: more dotz
From: STEF at SRI-KA
To: Frankston.Frankston at MIT-MULTICS
Cc: header-people at MIT-MC
Message-ID: <[SRI-KA]16-Mar-79 17:57:50.STEF>
In-Reply-To: Your message of  16 March 1979 20:45 est

chuckle chuckle - the subject bug is in hermes, which has apparently
assumed that no one would put an extra space in front of an "re:"

Best - Stef

Date: Saturday, 17 Mar 1979 0007-EST
From: Brian(space)Reid
Subject: embedded spaces
Sender: BR10 at CMU-10A
To:   Header-People at MIT-MC
Reply-To: Brian.K..Reid <BR10 at CMU-10A>
Message-ID: <17Mar79 000730 BR10@CMU-10A>

This seems to work too, and to my utter amazement, our RdMail can parse it
correctly!

Date: 16 Mar 1979 2131-PST
Sender: GEOFF at SRI-KA
Subject: Re: embedded spaces
From: the tty of Geoffrey S. Goodfellow
To: BR10 at CMU-10A
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KA]16-Mar-79 21:31:34.GEOFF>
In-Reply-To: <17Mar79 000730 BR10@CMU-10A>
Reply-to: Geoff @ SRI-KA

So can HERMES (as this message demonstrates)!  However, all, N.B.
that the reason why HERMES can parse it is because of SENDER.
Currently the way HERMES handles msgs is that if it can't parse
from it goes looking for SENDER (an RFC733 violation indeed), so if
you removed SENDER from your msg, HERMES would luze as before.
This meaning also of course that HERMES knows NOTHING about REPLY-TO.
 

Via: Rand-Unix
To:       Msggroup@mit-mc, Header-People@mit-mc
Subject:  Dawning of a New Age?
From:     Dcrocker at UDEE
Reply-to: Dcrocker at Rand-Unix
Date:     Sun, 18 Mar 79 16:19-EST

Please to note the From field of this message.  As of a couple of
days ago, we are finally able to send messages onto the ArpaNet,
from the University of Delaware.  We use dial-up access to a Mail
Relay host (currently Rand-Unix).  We should shortly have
automated pickup of mail, also.

The current hack is to have return mail go to our accounts on
Rand.  The longer-term solution will remove this and have it go
"directly" back to Delaware.

You might be interested to know that we use 300 baud, which gives
us an effective bandwidth of about a kilobyte per minute.  As
atrocious as that sounds, it obviously is somewhat useful.  Only
requirement is that the user not be expected to sit and watch it,
so of course we have a background process do the dial-up and
transfer.

Dave.

Date:  2 Apr 1979 0843-PST
From: POSTEL at USC-ISIE
Subject: RFC on new message system available
To:   header-people at MIT-MC
cc:   postel


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

         Title:   Internet Message Protocol
         Author:  Jon Postel
         Pages:   62

            pathname: <NETINFO>RFC753.TXT

      This is very much a request for comments, so please send me your
      suggestions for improving the proposed message system and improving
      the document.

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

      --jon.

-------

Via: <UDEE to Rand-Unix use UDEE%POBox>
To:       Header-People@MIT-MC
cc:       Feinler@SRI-KL,, Farber@SRI-KA,, Szurko@UDEE
Subject:  Short term solution to an Internet addressing problem?
From:     Dcrocker at UDEE
Reply-to: Dcrocker at Rand-Unix
Date:     Thu, 5 Apr 79 15:21-EST

    We have encountered an  interesting  addressing  problem,  in
sending  mail from the University of Delaware out to the Arpanet.
You may notice that this message contains a "Reply-To"  field  in
which the return address specifies a host on the Arpanet, whereas
the From field specifies one that is not.  This is a hack of some
utility  --  providing your message system can deal with Reply-To
as it is supposed to -- but limits the solution (?) of the  "host
on  another  network" referencing problem to the sender's address
only.  Any addresses having the same problem but occurring in the
"To" or "cc" fields are left hanging.

    I believe that there exists a tolerable, complete,  "correct"
solution  but  it  requires a substantial conceptual change and I
will be suggesting it later.

    A hack -- of the hackiest type -- seems  reasonable  for  the
VERY  short term, contingent upon the ability of existing systems
to tolerate it.  To wit:  extend the official Arpanet Host  Names
list  to  include the University of Delaware and have it have the
same host number address as Rand-Unix.  The potential problem  is
with  the  existing rule that a given address officially has only
two strings associated, one the official name  and  the  other  a
nickname.   Our  suggestion  is  to up that to at least three and

Via: <UDEE to Rand-Unix use UDEE%POBox>
To:       Header-People@MIT-MC
cc:       Feinler@SRI-KL,, Farber@SRI-KA,, Szurko@UDEE
Subject:  Short term solution to an Internet addressing problem?
From:     Dcrocker at UDEE
Reply-to: Dcrocker at Rand-Unix
Date:     Thu, 5 Apr 79 15:21-EST

    We have encountered an  interesting  addressing  problem,  in
sending  mail from the University of Delaware out to the Arpanet.
You may notice that this message contains a "Reply-To"  field  in
which the return address specifies a host on the Arpanet, whereas
the From field specifies one that is not.  This is a hack of some
utility  --  providing your message system can deal with Reply-To
as it is supposed to -- but limits the solution (?) of the  "host
on  another  network" referencing problem to the sender's address
only.  Any addresses having the same problem but occurring in the
"To" or "cc" fields are left hanging.

    I believe that there exists a tolerable, complete,  "correct"
solution  but  it  requires a substantial conceptual change and I
will be suggesting it later.

    A hack -- of the hackiest type -- seems  reasonable  for  the
VERY  short term, contingent upon the ability of existing systems
to tolerate it.  To wit:  extend the official Arpanet Host  Names
list  to  include the University of Delaware and have it have the
same host number address as Rand-Unix.  The potential problem  is
with  the  existing rule that a given address officially has only
two strings associated, one the official name  and  the  other  a
nickname.   Our  suggestion  is  to up that to at least three and

Via: <UDEE to Rand-Unix use UDEE%POBox>
To:       Header-People@MIT-MC
cc:       Feinler@SRI-KL,, Farber@SRI-KA,, Szurko@UDEE
Subject:  Short term solution to an Internet addressing problem?
From:     Dcrocker at UDEE
Reply-to: Dcrocker at Rand-Unix
Date:     Thu, 5 Apr 79 15:21-EST

    We have encountered an  interesting  addressing  problem,  in
sending  mail from the University of Delaware out to the Arpanet.
You may notice that this message contains a "Reply-To"  field  in
which the return address specifies a host on the Arpanet, whereas
the From field specifies one that is not.  This is a hack of some
utility  --  providing your message system can deal with Reply-To
as it is supposed to -- but limits the solution (?) of the  "host
on  another  network" referencing problem to the sender's address
only.  Any addresses having the same problem but occurring in the
"To" or "cc" fields are left hanging.

    I believe that there exists a tolerable, complete,  "correct"
solution  but  it  requires a substantial conceptual change and I
will be suggesting it later.

    A hack -- of the hackiest type -- seems  reasonable  for  the
VERY  short term, contingent upon the ability of existing systems
to tolerate it.  To wit:  extend the official Arpanet Host  Names
list  to  include the University of Delaware and have it have the
same host number address as Rand-Unix.  The potential problem  is
with  the  existing rule that a given address officially has only
two strings associated, one the official name  and  the  other  a
nickname.   Our  suggestion  is  to up that to at least three and
preferably four.

    Some implementations may depend on that maximum of two and  I
need  information  from you as to whether any of your systems, or
systems that you know about, rely on that  limit.   I  know,  for
example,  that  the  Rand-Unix  host  list,  derived from the one
maintained by Geoff, can handle an arbitrary number of aliases.

    Please let me know of any problems.

    Thanks.

        Dave Crocker

Date: Thursday,  5 Apr 1979 1739-EST
From: Craig.Everhart at CMU-10A
Subject: Re: Short term solution to an Internet addressing problem?
Sender: RdMail at CMU-10A
To:   Header-People at MIT-MC
Message-ID: <05Apr79 173949 RD00@CMU-10A>
In-Reply-To: Dcrocker's message of 5 Apr 79 15:21

I happen to know that CMU's copy of the Arpanet host table only has room for
a single nickname for any given host.  I had wondered about the official
status of the multiple nicknames to be found in {SRI-KL}<NETINFO>HOSTS.TXT.

So much for the direct answer to your question.  I hope you know your outgoing
mail had its header fields in an un-recommended order, with the Date: field
coming last rather than first, and so forth.

		Craig Everhart
 

From: dcrocker at Rand-Unix
Date: Thu,  5 Apr 79 15:18-PST
To: Craig.Everhart at CMU-10A
cc: Header-People at MIT-MC
Subject: Re: Short term solution to an Internet addressing problem?
In-reply-to: Your message of Thursday,  5 Apr 1979 1739-EST.
             <05Apr79 173949 RD00@CMU-10A>

1. with respect to the aliasing, many thanks for the info, tho I would
of course have preferred a different response.  Sigh.

2. with respect to header ordering, this erroneous belief of yours
seems to be quite common.  The apparent ordering requirement for
headers, in the standard, is due to the nature of the specification
tool and a NOTE at the beginning of section III.C, "General Syntax
of Messages" disclaims the requirement, instead relegating it to
a recommendation.  I approve of the recommendation but the
current software make following it somewhat difficult whereas
sticking it on the beginning is easy.  Does it really cause your
software problems?

dave.

Date:  5 April 1979 18:36 est
From:  Palter.PDO at MIT-Multics (Gary M. Palter)
Subject:  Re: Short term solution to an Internet addressing problem?
To:  Dcrocker at Rand-UNIX
cc:  Header-People at MIT-MC, Feinler at SRI-KL, 
     Farber at SRI-KA, Szurko at Rand-UNIX
In-Reply-To:  Msg of 04/05/79 16:44 from Dcrocker

    We can add an arbitrary number of abbreviations for a host on
Multics.  However, if we did add UDEE as an abbreviation of Rand-Unix,
ithe Multics mail system will put Rand-UNIX (the official name) into the
header or the message, thus loosing some information.

    I will check intowhether the Multics version of the host table can
have two separate hosts with the same address.  (Even if this is
possible, I expect that it will not help the situation any.)

    Whatever, I will put UDEE into the Multics host table (MIT only;
someone else will have to get RADC and CISL upated.)

Date: Thursday,  5 Apr 1979 1836-EST
From: Craig.Everhart at CMU-10A
Subject: Re: Short term solution to an Internet addressing problem?
To:   dcrocker at Rand-Unix
CC:   Header-People at MIT-MC
Message-ID: <05Apr79 183605 CE10@CMU-10A>
In-Reply-To: dcrocker's message of 5 Apr 79 18:18

As you'll note, I only referred to the order of header fields as a
recommendation, not as a requirement, in my message.  The particular order
of fields makes no difference to my mail reader (RDMAIL).  I just figured
that you, having been so intimately involved with RFC733, should not remain
unaware of the glitch in the header to the mail you composed.  Of course,
since the recommended order was only a recommendation, answers involving
the amount of programming time involved are that much more believable.

		Craig

Date: Thursday,  5 Apr 1979 1901-EST
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: Short term solution to an Internet addressing problem?
To:   Dcrocker at Rand-Unix
CC:   Header-People @ MIT-MC
Message-ID: <05Apr79 190142 RG02@CMU-10A>
In-Reply-To: Dcrocker's message of 5 Apr 79 15:21

Why not "DCrocker at UDEE at Rand-Unix", with Rand-Unix informed of the
meaning of pseudo-user "DCrocker at UDEE"?

		Rick
 

Date:     5 April 1979 2108-est
From:     Bob Frankston              <Frankston at MIT-Multics>
Subject:  Prelogin help for Multics
To:       Pogran.CompNet at MIT-Multics
Cc:       Consultant.IPC at MIT-Multics
Cc:       header-people at MIT-MC

It would be nice if the online consultant facility were available from a
prelogin command.  The system should check to see if an online
consultant is available.  If so, the text for the help command syould
say something like

 For more help, type "olc" followed by a message for the online
          consultant,

When the consutlant is not available a mail command could be available
for the user to leave questions.  This latter faiclity can be used to
get informationabout user registration sent to the user via uUS mail or
net mail depending on what is apporpriate.


Date:     5 April 1979 2138-est
From:     Bob Frankston              <Frankston at MIT-Multics>
Subject:  Re: Short term solution to an Internet addressing problem?
To:       Rick.Gumpertz at CMU-10A
Cc:       DCrocker at Rand-unix, header-people at MIT-MC

While I agree that pathnames should be usable for addressing people on
the network, such as DCrocker at UDEE at Rand-Unix.  The problem is
representing the  return address apropriately.  When at UDEE, the reply
field is simply "DCrocker at UDEE".  I notice that Dave's message
contained an attempt at a via field.  It is that field, in conjunction
with the reply field that is used to construct the reply pathname.
Since most hosts do not handle the via  constructs (in fact, none do
currently) a gateway site such as Rand-Unix scould append its own name
to the reply- field.  Thus the header would start as:

 Reply-to: DCrocker at UDEE

and become either

 Via:      Rand-Unix
 Reply-to: DCrocker at UDEE

or, if we just want to make changes at the gateway host,

 Reply-to: DCrocker at UDEE at Rand-Unix

My full blown proposal also contains the suggestion for the repcipient:
field used in allowing any user on any host to act as a gatewey, but I
will not repeat that here.

On additional compatability point.  Most hosts do not deal with the
multiple "at" problem at present (nor even the embedded space problem!!!)
so that if we are dealng with interim solutions that do not require
modifying old hosts, we can allow the word "via" to be a synonym for
"at" such that the reply vield becomes

 Reply-to: DCrocker via UDEE at Rand_Unix.

{To keep hermes happy, Reply-to: DCrocker.via.UDEE at Rand_Unix.}

Date: Thursday,  5 Apr 1979 2218-EST
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: Short term solution to an Internet addressing problem?
To:   Bob Frankston <Frankston at MIT-Multics>
CC:   DCrocker at Rand-unix, header-people at MIT-MC
Message-ID: <05Apr79 221830 RG02@CMU-10A>
In-Reply-To: Bob Frankston's message of 5 Apr 79 21:38

1) Why add new fields?  Seems to me that the gateway function should
feel free to modify any machine-addresses (in FROM/TO/REPLY-TO/etc)
as they go through the gateway (either the UDEE half or the Rand-Unix
half -- it doesn't matter which) in each direction.  Note that such
addresses can be found thanx to RFC733 if that standard hasn't gone
up in wishful smoke.

2) For the hosts that can't hack double @, VIA is a poor replacement
because it requires delimiting spaces.  We all know about spaces and
Big-Bad-Neighbor.  Maybe to be consistent you could use .VIA. (sigh)
or, if UDEE names have no dots, more simply UserName.UDEE at RAND-Unix

		Rick Gumpertz
  

Sender: dcrocker at Rand-Unix
Date: Thu,  5 Apr 79 20:38-PST
To: Header-People at MIT-MC
Subject: internet addressing, addendum
From: Dave Crocker <DCrocker at Rand-Unix>

I appreciate the interest shown by the activity spike.  However, you
are trying to solve a different problem than the one I have.  For
the moment, the existing Reply-To contents are entirely adequate
(tho, yes, I realize it obviously invovles the very worst sort
of hackery to make it work).  And, with respect to the Reply-To
field, the nesting you suggest is what will happen, in some
form, tho that cannot happen until a modified Rand FTP server,
at least, is installed.  Since Rand is a production facility,
such major system changes take a long time.  Got to make sure
the change is safe.

Howsomever, there is a very different problem that only got
hinted at in the flurry of notes and that is addresses in
the To and cc fields that reference UDEE.  I have a very strong
aversion to mucking with the existing text of a message and,
unfortunately, those fields are part of the TEXT of the message,
tho software uses it too.  Ergo, my preference, my very strong
preference, is to add fields.  Also, I might add, that is
many time easier to do.  Something on the order of the Via
field (but not exactly that and certainly not exactly what
we are now generating) is what I have in mind and is what I
obliquely referenced in my note earlier today.  For the moment,
I am, once again, looking for the minimum effort, probably
hackiest (re)solution available and extending the hostname
table seem(s/ed) the likeliest candidate.

Note that we are NOT concerned with preserving the string "UDEE"
on reply mail.  Having the string be "Rand-Unix" is just fine.
As I said, we are using a hack solution.  Turns out is works
because we have accounts on Rand.

So, people, since at least one site relies on the limit of two
strings, we won't be able to try to make the addition official.
however, those who keep private lists, with arbitrary lists
of aliases, PLEASE ADD "UDEE" and "UDel-EE" and aliases for
Rand-Unix.  (You listening Geoff??)

Many thanks.

Dave.

Date: Friday,  6 Apr 1979 0000-EST
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: internet addressing, addendum
To:   Dave Crocker <DCrocker at Rand-Unix>
CC:   Header-People at MIT-MC
Message-ID: <06Apr79 000042 RG02@CMU-10A>
In-Reply-To: Dave Crocker's message of 5 Apr 79 23:38

The header, in my opinion, is NOT part of the text.  You should be manipualting it.
adding a VIA field is a crock because it doesn't say which addresses are qualified
by the VIA.

		Rick
   

Date:     6 April 1979 0216-est
From:     Bob Frankston              <Frankston at MIT-Multics>
Subject:  internet addressing, addendum
To:       DCrocker at Rand-Unix
Cc:       header-people at MIT-MC

In response to Rick Gumpertz' comment on "via".  It applies to
all address in the letter since it means they are all relative to the
given gateway.



Date: 5 Apr 1979 2329-PST
Sender: GEOFF at SRI-KA
Subject: Re:  Re: Short term solution to an Internet addressing problem?
From: the tty of Geoffrey S. Goodfellow
To: Frankston at MIT-MULTICS
Cc: Rick.Gumpertz at CMU-10A, DCrocker at RAND-UNIX, 
Cc: header-people at MIT-MC
Message-ID: <[SRI-KA] 5-Apr-79 23:29:40.GEOFF>
In-Reply-To: Your message of     5 April 1979 2138-est
Reply-to: Geoff @ SRI-KA

However, sadly enough, HERMES does not know about the REPLY-TO:
field, however if you put "SENDER: DCrocker.via.UDEE at
RAND-UNIX) in there winnage would occur with HERMES.

Date: 5 Apr 1979 2334-PST
Sender: GEOFF at SRI-KA
Subject: Re: internet addressing, addendum
From: the tty of Geoffrey S. Goodfellow
To: DCrocker at RAND-UNIX
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KA] 5-Apr-79 23:34:15.GEOFF>
In-Reply-To: Your message of Thu,  5 Apr 79 20:38-PST
Reply-to: Geoff @ SRI-KA

Yes, I'm listening, and will add UDEE and UDEL-EE into my table
for the next update.

Date:  6 Apr 1979 0026-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: Re: internet addressing, addendum
To:   GEOFF at SRI-KA, DCrocker at RAND-UNIX
cc:   Header-People at MIT-MC, FEINLER

In response to the message sent 5 Apr 1979 2334-PST from the tty of Geoffrey S. Goodfellow

Haven't had time to read all this stuff flying by, but do feel that
we (either Geoff or I or anyone else) should not put in a nickname
of that sort without the approval of RAND.  It is clearly not a nickname
or alias for RAND-UNIX.  On the other hand, if they don't mind, I don't
mind as a temporary stop-gap.

Jake
-------

Date:  6 Apr 1979 0103-PST
From: Scott at SRI-KL (Scott J. Kramer)
Subject: Re:  Prelogin help for Multics
To: Frankston at MIT-MULTICS, Pogran.CompNet at MIT-MULTICS
Cc: Consultant.IPC at MIT-MULTICS, header-people at MIT-MC
In-reply-to: Your message of 5-Apr-79 1808-PST

I think that the "ocl" command could page the appropriate party (as :luser does
on ITS) but in the event there was no one available to help you it would then
automatically invoke the mail-type program wherein you could supply the
neccessary information for having your inquiry answered. This mail message
could be sent to the appropriate party according to a limited subject field,
ie. the program would specify a list of subject options related (hopefully)
to your inquiry. So maybe this solution can be considered in the already
infinite list of alternatives to a difficult problem.

   Scott Kramer
-------

Date:     6 April 1979 0407-est
From:     Bob Frankston              <Frankston at MIT-Multics>
Subject:  Re:  Prelogin help for Multics
To:       Scott at SRI-KL 
Cc:       Consultant.IPC at MIT-Multics
Cc:       header-people at MIT-MC

1. The command is olc for online consultant.  The standard version already
looks in a table for the currently assigned consultant, if any.

2. The people acting as consultants are paid staff people who are
usually doing other work at the time so I don't think that IPC would be
happy about making this facility too freely available.  It would only be
intended for short questions on how to proceed further,  maybe with a
very tight resource limit, or a limit onthe # of messages.

3. The problem with mail is determining how to reply to a random user
coming in from anywhere in the world.  The current help command does
give a phone number to call if there are problems.

4. Inany case this faiclity will not serve the purpose of helping user A
get in touch with user B.  The olc probalby has never heard of the
person your are interested in communicating with.  Multics has hundreds
of registerd users, many of which are students in classes.  The
registration process is totally distirbuted, except that there is a
central registry of usre names to prevent conflicts.  Most of these
people have never heard of each other.  To take this to an extreme,
imagine the phone system operating by allowing you to call a random
person in a distant city to hel you get in touch with a friend.  The
intention of the "help" command that currently exists is to provide a
means whereby one can ask questions about technical problems with
logging in, including obtaining an account

4. it would be useful if the current help message were extended, atleast
for network users, to give the phone number and mailbox name of the
netowrk liason.


Date:  6 Apr 1979 0128-PST
From: Scott at SRI-KL (Scott J. Kramer)
Subject: Re:  Re:  Prelogin help for Multics
To: Frankston at MIT-MULTICS
Cc: Consultant.IPC at MIT-MULTICS, header-people at MIT-MC
In-reply-to: Your message of 6-Apr-79 0107-PST

Thanks for making that clearer Bob, I am not a Multics user. Anyways, my
suggestion could be applied to other network sites; have an extended LUSER
command. I think that in many cases if a random suddenly found himself
being queried by the mail-type program his question would lose importance.
Of course in situations like RMS's with UTAH, the program should prove
sufficient assuming that the server has allowed itself to be queried.
-------

Date: Friday,  6 April 1979 1108-EST
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: internet addressing, addendum
To:   Bob Frankston <Frankston at MIT-Multics>
CC:   header-people at MIT-MC
Message-ID: <06Apr79 110852 RG02@CMU-10A>
In-Reply-To: Bob Frankston's message of 6 Apr 79 02:16

If VIA applies to all adresses, is there an ordering of VIAs for messages that travel
through two different GATEWAYs??  I still prefere munging each address to be a complete
entity by itself.

		Rick
   

Date: 6 APR 1979 1408-EST
From: KLH at MIT-MC (Ken Harrenstien)
Subject: Un(registered-mail-receipt)
To: HEADER-PEOPLE at MIT-MC, (BUG MAIL) at MIT-MC
To: (BUG CRTSTY) at MIT-MC, MsgGroup at MIT-ML

	It just struck me that despite general managerial dislike of
the idea, I could have recently benefited from the feature (if it
existed) of being able to tell the sender of a message whether the
recipient has read it.  My Header-people, MsgGroup, ITS, etc mail is
all vectored to KLH@MIT-AI, and for the past 3 weeks I've been so
crunched against the wall with local Deafnet hacking that I didn't read
any of it.  Hope silence hasn't been interpreted as indifference; there
are certainly places where I ought to comment.
	Am catching up now (with 200-300 msgs), but just for the
record, if there is something urgent (change to mailing list, fatal
bugs in mail, etc) you may have better luck using KLH@SRI-KL.

--Ken

Date:     6 April 1979 1801-est
From:     Bob Frankston              <Frankston at MIT-Multics>
Subject:  Re: internet addressing, addendum
To:       Rick.Gumpertz at CMU-10A
Cc:       header-people at MIT-MC
          
I agree that the via ordering is a problem and that all fields should
probably be munged.  The issue of ordered header fields is an important
one in some contexts.  I don't qutie know the best to handle it, maybe
"via(1)" etc.  My motivation of putting the via field at the beginning
was to allow a host ftp server to put the name of the host from where
the message came to be put in the "via" field and  put the recipient
name in at the same time.  The use I suggested to Crocker was actually
slightly different since it was meant to be appended by the gateway host
as opposed to the receiving host.

Date:  6 APR 1979 1730-PST
From: POSTEL at USC-ISIB
Subject: re: short term solution to an internet addressing problem
To:   DCrocker at RAND-UNIX
cc:   Header-People at MIT-MC


Dave:

i guess i don't see what you are trying to do. as far as i can tell the
VIA: line is just noise to every body except your gateway at rand.  i
hope you don't expect my mail reading/sending program to copy it into an
answer i generate from one of your messages.  and even tho rfc 733 says
all those nice things about the use of the REPLY-TO line, Duane Adams has
asked that we try to avoid making necessary the use of features not already
generally implemented.

several people (Rick in particular) have made the point about matching the
information in one line with that in another.  the point boils down to:
each address must be complete and self contained.

the hack that will work in the short term is for all users on the Delaware
host to have external names of the form joe-UDEE@RAND-UNIX.  The rest of us
will think that joe-UDEE is some mail box at rand  and rand can put all mail
for any user name that ends "-UDEE" in the same file for later transmission
to Delaware, and if you want at Deleware to fix the local names on the way
in and out so you see the string "-UDEE@RAND-UNIX" as "UDEE" thats your
business.

--jon.
-------

Date:  6 April 1979 20:54 est
From:  Frankston.Frankston at MIT-Multics
Subject:  Re: short term solution to an internet addressing problem
To:  POSTEL at USC-ISIb
cc:  DCrocker at Rand-UNIX, Header-People at MIT-MC
In-Reply-To:  Msg of 04/06/79 20:30 from POSTEL

Why not use ".via." instead of "-" in "Jones.via.UDEE".  As I've pointed
out, this provides compatability for existing sites, but has the
advantage of a glimpse ot future capabilities.

PS: I haven't read your proposal for internetting yet, so this may be
addressing issues you've already solved.

Date:  6 APR 1979 1813-PST
From: POSTEL at USC-ISIB
Subject: Re:  Re: short term solution to an internet addressing problem
To:   Frankston.Frankston at MIT-MULTICS
cc:   DCrocker at RAND-UNIX, Header-People at MIT-MC, POSTEL

In response to your message sent  6 April 1979 20:54 est


Fine with me. the syntax within what i see as a single user name is
up to the site that invents the names.  if we are going to have several
of these "out-of-net" hosts it would be nice to be consistent about it.
your suggestion is helpful in that it tries to let the user see what is 
really going on, but it is not quite right since the message is really
to/from UDEE and via RAND.  how about "Jones.at.UDEE at RAND"
(no, i thought not).

--jon.
-------

Date:  6 APR 1979 1822-PST
From: POSTEL at USC-ISIB
Subject: re: short term solution to an internet addressing problem
To:   header-people at MIT-MC

   1    6 Apr  FARBER at SRI-KA      re: short term solution to an 
                                     internet addressing problem
   2    6 APR  To:  FARBER at SRI-KA re: short term solution to an 
                                     internet addressing problem


1 -- ************************
Mail from SRI-KA rcvd at 6-APR-79 1814-PST
Date: 6 Apr 1979 1805-PST
Sender: FARBER at SRI-KA
Subject: re: short term solution to an internet addressing problem
From: FARBER at SRI-KA
To: POSTEL at USC-ISIB
Message-ID: <[SRI-KA] 6-Apr-79 18:05:50.FARBER>
In-Reply-To: Your message of  6 APR 1979 1730-PST

Jon,

The  basis  problem  we are in is that the hack solution we would
like is one that is acceptable in the short term to parts of DOD.
MMDF  is being developed in part for real use by the DOD.  We are
searching for some solution that is acceptable  to  them  and  is
also within Adams view of message system development.

Certainly the additional pseudo-host route would work in part and
was suggested with the hope that it would involve no work.

I personnally thinnk the route you proposed  will  not  work  for
several  reasons  (none  technical).   (that is unless you let me
replace the - with an @ (chuckle).

Dave


2 -- ************************
Mail from USC-ISIB rcvd at 6-APR-79 1820-PST
Date:  6 APR 1979 1819-PST
From: POSTEL
Subject: re: short term solution to an internet addressing problem
To:   FARBER at SRI-KA
cc:   POSTEL

In response to your message sent 6 Apr 1979 1805-PST


Dave:

well let's get those non-technical constraints out in the open!  if we are
going to have an online design session with random participants (and
that is what's happening) then it is only fair that you state the 
whole problem.

--jon.
-------
-------

Date:  6 Apr 1979 1918-PST
From: POSTEL at USC-ISIE
Subject: New RFC Available
To:   header-people at MIT-MC


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

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

            pathname: <NETINFO>RFC754.TXT

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

      --jon.

-------

Date:     6 April 1979 2228-est
From:     Bob Frankston              <Frankston at MIT-Multics>
Subject:  Re:  Re: short term solution to an internet addressing problem
To:       POSTEL at USC-ISIB
Cc:       header-people at MIT-MC

.at. is fine with me.  The only reason for .via. was my evolution from
suggesting  " via " which was supposed to be transparent to existing
mailers except for damn Hermes which objected to spaces.  If we put the
"." there then we might as well use .at.,  actually I'd prefer some
character other than "." which would not be in conflict with RFC733
listing of innocuous characters so one would not have to quote it, but
which is not in common use so that, for example ?at? could generally be
used for parsing by participating hosts.

Date: Saturday,  7 April 1979 1129-EST
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: short term solution to an internet addressing problem
To:   Hedaer-People @ MIT-MC
Message-ID: <07Apr79 112924 RG02@CMU-10A>
In-Reply-To: Frankston.Frankston's message of 6 Apr 79 20:54

1) I like .at. as suggested by Postel rather than "-".

2) via was invented as a crock to get around non-implementtion of multiple
   AT conjunctions.  Therefore .via. is a double crock when .AT. will do just fine.

		Rick
 

Date: 9 April 1979 00:19-EST
From: Charles Frankston <CBF at MIT-MC>
Subject: ITS headers
To: HEADER-PEOPLE at MIT-MC, MsgGroup at MIT-ML
cc: BUG-BABYL at MIT-MC

I have changed the ITS Rmail reply command to force an RFC733 header in
any reply to a header that is not in ITS format.  This is based on the
assumption that anyone who sends out a network header probably should be
replied to with a network header.  Hopefully, this should eliminate many
unwanted ITS headers.  This change is conditional upon my not receiving
too many complaints from the user community.  Somehow, I don't expect to.

I am suggesting that the maintainers of the other mail reading program do
the same.  The theory behind the change is that most people simply use
the reply command somewhat blindly.  In fact, I have noticed this is ture much
more of the non-ITS particpaints, probably because they use such primitive
mail systems that do not allow them to have an editor easily available to
fix up their replies (take that Stef).  Nonetheless, since I happen to
know the maintainers of Babyl are easily sickened by excessive flaming,
if anyone replies to this message, please do NOT blindly copy the
CC:(bug babyl) line.  Thank you.

Date: 10 APR 1979 1111-PST
From: POSTEL at USC-ISIB
Subject: re: short term solution to an internet addressing problem
To:   DCrocker at RAND-UNIX, Farber at SRI-KA
cc:   Header-People at MIT-MC


Daves:

as i understand things now, you want a host (RAND-Unix) to be able to act as
a forwarder for some other host (or hosts) which are not otherwise connected
to the ARPANET without there being an implication that the users for which
forwarding is done are associated with the organization that owns the 
forwarding hosts.  For example, there may be people at Delaware that don't
want their names associated with RAND.

So ok, think up a pseudonym for RAND (say GATEWAY-3/7) that does not contain
the string "RAND", then give the users at Delaware external names of the form
"Joe.of.UDEE@GATEWAY-3/7"  which get used whenever we want Joe to be in a
From, Sender, To, or CC field (or any other place a mailbox appears).  Internal
to Delaware it is possible substitute the string "UDEE" for the string
".of.UDEE@GATEWAY-3/7" so that the Delaware users are not bothered by it.

Most of the hosts on the network will let one get away with this by entering
"GATEWAY-3/7" as a nickname for RAND-Unix, but a few will insist on only
using Official names in the actual messages sent. In this case the mechanism
still works, but the user at Delaware appears to be in some way associated with
RAND.  One could get around this by having the gateway code in RAND-Unix 
translate "RAND-Unix" to "GATEWAY-3/7" for those messages going to Delaware.

By the way there is no intention that the ".of." be recognized as being special
by any mail processing program except that at RAND (or other gateway), to most
mail processing programs it is just part of the user name.

--jon.
-------

Date: 11 April 1979 09:10-EST
From: Mike McMahon <MMCM at MIT-AI>
Sender: MMcM at CADR5 at MIT-AI
Subject: RsFC 753/4 flamage
To: Header-People at MIT-MC

It seems to me that RFC753 fails to address some of the fundamental
problems with the current ARPANET mail protocol.  Since it proposes to
fundamentally change the method of message sending away from the
outdated FTP MAIL command, now is definitely the time to figure out
better how the rest of it should work in the multiple network
environment it envisions (and which RFC754 shows to already be forming)
as well. 

  I cannot imagine that anyone has a mail system anyplace that is well
  enough designed that he/she will be able to adopt the internet scheme
  by simply changing the network sending routines and leaving the rest
  of the program intact.  To get this going will require a large amount
  of programmer investment, in most cases a major overhaul or rewrite of
  the mailer; this would be much better invested toward getting
  something closer to what we believe to be right.

  The main problem with just about every mail program is HEADERS: spending
  all your time parsing them into your internal format and generating them
  back again in response.  The extensible, data-typed, structured system
  proposed for the Message itself just begs to be used for headers.  Why
  stick with RFC733?  We all just implement a subset of it based on what
  other people send us and how responsive we are to our users.  It isnt
  even left-to-right parsable (simplest example is "<", which has to get
  implemented in a sequential parser as "forget what you might have
  thought was going on", which ought not to be a valid parsing operation).

    I confess i am thoroughly confused as to whether or not PROPLIST is
    typed.  The description of a Mailbox and the other instances of IA:
    seem to imply that it is, in that they are integers.  However, the
    examples dont expand PROPLIST values into TEXT="Meeting Thrusday"
    and so on.

    Also i dont understand why one would need a size field for the value
    if it were typed.  Obviously it needs to be typed to allow LISTs for
    structured recipients.  Also it is not clear to me if the PROPLIST
    indicators are supposed to be unique or not, in the case of a
    continuation line TO: field, is each line a TO value, or is the
    value a string with CRLF and LWSP in it?

  I think we are mostly agreed that typing and immediately deleting all
  your mail is obsolete.  The mail reader grovels over the message
  (parsing those damn headers), when it comes in from the net, or when
  it loads new mail, or when you want to reply to the message.  So
  what's the point in having almost human readable headers in the message
  itself.  A sufficiently well thought out structure for them should be
  able to guarantee that the "default" action at the other end shows
  "what you wanted" him/her to see.

On a minor point, if my understanding of what "urgent" messages are in
TCP, i.e. that they bypass normal flow-control mechanisms, it seems that
this is entirely the wrong protocol level at which to be handling alarum
messages.  It seems it is much better done with multiple connections
where necessary.

Final thought: suppose i wanted to have multiple fonts in this message,
as in the editor/mail-program i sent it with, if you also had a terminal
that could display them, that would be another use for this structure.


Date: Wednesday, 18 April 1979  12:06-EST
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: Header-People at MIT-MC
Subject: MSG finally fixed!

Date: 18 Apr 1979 1024-EST
From: DUPUIS at BBN-TENEXE
Subject: New Version of MSG

A new version of MSG is up in <SUBSYS> as MSG.EXE. Old version is in
<SUBSYS> as OLDMSG.EXE, it will stay in <SUBSYS> for one week and then 
be deleted.

The only change in this new release of MSG is that it understands the
new ARPANET mail standard formats for messages.  This means that you
will not be able to Answer messages from sites like MIT and CMU that
generate addresses in that format.

Please send all reports of problems or comments to MSG at BBNA.

-------

Date: 18 April 1979 14:10-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject: Please ignore this
To: HEADER-PEOPLE at MIT-MC

Testing.

Date:     6 April 1979 1801-est
From:     Bob Frankston              <Frankston at MIT-Multics>
Subject:  Re: internet addressing, addendum
To:       Rick.Gumpertz at CMU-10A
Cc:       header-people at MIT-MC
          
I agree that the via ordering is a problem and that all fields should
probably be munged.  The issue of ordered header fields is an important
one in some contexts.  I don't qutie know the best to handle it, maybe
"via(1)" etc.  My motivation of putting the via field at the beginning
was to allow a host ftp server to put the name of the host from where
the message came to be put in the "via" field and  put the recipient
name in at the same time.  The use I suggested to Crocker was actually
slightly different since it was meant to be appended by the gateway host
as opposed to the receiving host.

Date: 11 April 1979 09:10-EST
From: Mike McMahon <MMCM at MIT-AI>
Sender: MMcM at CADR5 at MIT-AI
Subject: RsFC 753/4 flamage
To: Header-People at MIT-MC

It seems to me that RFC753 fails to address some of the fundamental
problems with the current ARPANET mail protocol.  Since it proposes to
fundamentally change the method of message sending away from the
outdated FTP MAIL command, now is definitely the time to figure out
better how the rest of it should work in the multiple network
environment it envisions (and which RFC754 shows to already be forming)
as well. 

  I cannot imagine that anyone has a mail system anyplace that is well
  enough designed that he/she will be able to adopt the internet scheme
  by simply changing the network sending routines and leaving the rest
  of the program intact.  To get this going will require a large amount
  of programmer investment, in most cases a major overhaul or rewrite of
  the mailer; this would be much better invested toward getting
  something closer to what we believe to be right.

  The main problem with just about every mail program is HEADERS: spending
  all your time parsing them into your internal format and generating them
  back again in response.  The extensible, data-typed, structured system
  proposed for the Message itself just begs to be used for headers.  Why
  stick with RFC733?  We all just implement a subset of it based on what
  other people send us and how responsive we are to our users.  It isnt
  even left-to-right parsable (simplest example is "<", which has to get
  implemented in a sequential parser as "forget what you might have
  thought was going on", which ought not to be a valid parsing operation).

    I confess i am thoroughly confused as to whether or not PROPLIST is
    typed.  The description of a Mailbox and the other instances of IA:
    seem to imply that it is, in that they are integers.  However, the
    examples dont expand PROPLIST values into TEXT="Meeting Thrusday"
    and so on.

    Also i dont understand why one would need a size field for the value
    if it were typed.  Obviously it needs to be typed to allow LISTs for
    structured recipients.  Also it is not clear to me if the PROPLIST
    indicators are supposed to be unique or not, in the case of a
    continuation line TO: field, is each line a TO value, or is the
    value a string with CRLF and LWSP in it?

  I think we are mostly agreed that typing and immediately deleting all
  your mail is obsolete.  The mail reader grovels over the message
  (parsing those damn headers), when it comes in from the net, or when
  it loads new mail, or when you want to reply to the message.  So
  what's the point in having almost human readable headers in the message
  itself.  A sufficiently well thought out structure for them should be
  able to guarantee that the "default" action at the other end shows
  "what you wanted" him/her to see.

On a minor point, if my understanding of what "urgent" messages are in
TCP, i.e. that they bypass normal flow-control mechanisms, it seems that
this is entirely the wrong protocol level at which to be handling alarum
messages.  It seems it is much better done with multiple connections
where necessary.

Final thought: suppose i wanted to have multiple fonts in this message,
as in the editor/mail-program i sent it with, if you also had a terminal
that could display them, that would be another use for this structure.

Date: Wednesday, 18 April 1979  12:06-EST
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: Header-People at MIT-MC
Subject: MSG finally fixed!

Date: 18 Apr 1979 1024-EST
From: DUPUIS at BBN-TENEXE
Subject: New Version of MSG

A new version of MSG is up in <SUBSYS> as MSG.EXE. Old version is in
<SUBSYS> as OLDMSG.EXE, it will stay in <SUBSYS> for one week and then 
be deleted.

The only change in this new release of MSG is that it understands the
new ARPANET mail standard formats for messages.  This means that you
will not be able to Answer messages from sites like MIT and CMU that
generate addresses in that format.

Please send all reports of problems or comments to MSG at BBNA.

-------

Date: 18 APR 1979 1756-EST
From: EAK at MIT-MC (Earl A. Killian)
Subject:  MSG finally fixed!
To: McLure at SRI-KL
CC: HEADER-PEOPLE at MIT-MC

    Date: 18 Apr 1979 1417-PST
    From: Stuart McLure Cracraft <McLure at SRI-KL>
    To:   EKILLIAN at BBN-TENEXE, Header-People
    Re:   MSG finally fixed!

    And of course the sources will remain carefully guarded and jealously
    hidden away so that things can not be done at a faster pace to MSG
    than has been the case in the past with incredibly slow bug fixes and
    complaints about 'not having the funding to do them'.

So, what else is new?  I'm just happy that another reason for
abandoning RFC733 is going away.

Date:  19 April 1979 03:10 est
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject:  Nonstandard header
To:  header-people at MIT-MC
Message-ID:  <790419081042.634416 at MIT-Multics>

Apparently ITS has regurgitated a letter of mine from APril 6th with a
nonstandard header.  I apologize to all of those incovneienced and
assume that the mail maintainers have also seen your complaints and will
attempted to deal with the problem.  I presume it to be a transient bug
in the send_mail program on Multics.  It has either gone away or shows
up only in unusual circumstances.

Date: 23 April 1979 11:26-EST
From: Ken Harrenstien <KLH at MIT-AI>
Subject: MSG finally fixed?
To: Dupuis at BBN-TENEXE
cc: Header-People at MIT-MC


Pardon me, but is this paragraph really what you wanted to say?
It seems self-contradictory...

    "The only change in this new release of MSG is that it understands the
    new ARPANET mail standard formats for messages.  This means that you
    will not be able to Answer messages from sites like MIT and CMU that
    generate addresses in that format."

????


Date: 23 APR 1979 1141-EST
From: JNC at MIT-AI (J. Noel Chiappa)
Subject: MSG and your health...
To: header-people at MIT-MC


	One of these days, when the FDA investigates Chinese restaurants,
they will decide that use of MSG is hazardous to your health....
			Noel


Date: 23 APR 1979 1358-EST
From: EAK at MIT-MC (Earl A. Killian)
Subject:  MSG finally fixed?
To: KLH at MIT-MC
CC: HEADER-PEOPLE at MIT-MC, Dupuis at BBN-TENEXE

The message should have read "you will now be able to Answer" instead of
"you will not be able to Answer".

Date:  8 May 1979 17:49 edt
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject:  Visitation II
To:  header-people at MIT-MC
Message-ID:  <790508214904.117308 at MIT-Multics>

For those interested, if any, I'll be in SF Thursday (5/10) through
Monday (5/14) for the West Coast Computer Faire.  I'll be at the Best
Western Hotel SF Civic Center Motor Inn.  415-621-2826.

I'll also try to bring a terminal to read my mail.

