Date: 3 July 1979 19:19-EDT
From: Ken Harrenstien <KLH at MIT-AI>
Subject: Internet addressing format?
To: Header-People at MIT-MC

I just learned that apparently the internet working group intends
to use the format "<net>-<user>@<host>" for internet addressing.
I vaguely recall reading something about this earlier but forget exactly
where.  I've also been extremely preoccupied with getting "Deafnet"
on the air, so might have missed some exchanges.  Does anyone
know much about this?
  My first reaction to this idea was quite simple: "Ugh!".  I can
imagine some reasons why it might be desirable for some people, but
can also imagine other reasons why it would be undesirable for others.
Hmmm.  Re-considering, perhaps a better word is "Blorg".  I would
appreciate any attempts to mollify my viewpoint or support same.

--Ken


Date:  3 JUL 1979 1650-PDT
From: POSTEL at USC-ISIB
Subject: re: internet address format
To:   Header-People at MIT-MC


Ken:

i think you got a hold of the some confusing data.  the true facts are 
closer to the following (which you probably won't like either):

1) as a temporary hack, the existing network mail software should be able to
handle user addresses of the form "USER@NET-HOST", where NET-HOST is a name 
that translates to a 32 bit internet host number (8 bits of net, 24 bits of
host, see RFC755 for assigned net numbers).

2) it is recommended that in the long term user interface software for programs
that deal with the internet use the form "!NET!HOST" for network and host 
names.  If such an argument is to be further qualified by a user name or
a program name the obvious extension is "!NET!HOST!USER" or 
"!NET!HOST!PROGRAM".

If Header People want to learn more about "the internet" try snarfing copies
of the Internet Experiment Notes (IENs).  They are like RFCs but cover the
internet development.  Recent notes are online at the NIC, and most all of them
are stashed in the Datacomputer. At the NIC they are in <NETINFO>IEN-xx.TXT
files and at the Datacomputer they are in IEN-xx.TXT files after one uses DFTP
to get to the DC and attaches to "COMMON>IEN".

--jon.
-------

Date: 3 Jul 1979 1648-PDT
Sender: GEOFF at SRI-KA
Subject: Re: Internet addressing format?
From: the tty of Geoffrey S. Goodfellow
To: KLH at MIT-AI
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KA] 3-Jul-79 16:48:36.GEOFF>
In-Reply-To: Your message of 3 July 1979 19:19-EDT
Reply-to: Geoff @ SRI-KA

If that is the case, how would be send a message to
header-people@mc?  Wouldn't it then be translated into "user
people" at the "mc host" on the "header network"?

Date:  4 July 1979 01:42 edt
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject:  foo at bar at frob at zork
To:  header-people at MIT-MC
Message-ID:  <790704054256.435786 at MIT-Multics>

1. There ain't no such thing as an interim implemenation.  Once the
internet format for address is established that is it!!!  Especially if
it is ever implemented by Hermes!!

2. How do I address my Apple computer connected to my Prime computer
that periodically dials into Multics to exchange mail with the
University of Delaware via the Arpanet?  I doubt that my Prime's dialup
connection will get a net number, especially with a precious 256 nets
allowed in this universe.  Neither will my Apple, TRS-80, PET, Atari etc
be worth assigning a universal host number out of the limited
16,000,000 numbers available.  I would like to send mail to
  Bob at Apple-1 at SAI_Rime at MIT-Multics via ARPANET
 (via and at are interchangable, just changed for readability)

I am not being fanciful, all the machines in the above example exist and
will communicate!  At least if the protocols allow for it!

3. I will try to get around to reading the accumulate memos on
internetworking and apologize if the issues are dealt with adequately in
the memos, but I am skeptical in light of the immediate problems that
crop up in attempting to apply the proposed form to existing
configuarations of systems.

4 A last comment.  The discussions of internetworking concentrate on
communications between host pieces of iron.  The communication is really
between logical entities -- processes in common terminology which don't
have as static a configuartion as the current Arpanetwork.

Date:  4 Jul 1979 0613-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: inter-network addressing
To: Header-People at MIT-MC

It is moderately reassuring that we won't see NET-USER@HOST.  I am
not, however, convinced that USER@NET-HOST is a good idea, nor am I
in love with the exclamation mark format.  Why are these design
decisions being made without consulting the general community, or
even those who are doing multi-network research presently?  For whose
benefit are these decisions?  I have the impression that this is all
to support the old Tenex host table and software, instead of trying
to break new ground.

Please let's not hear people complaining about "Tenex taking over the
world" - on my Tops-20 system I started a redesign and rewrite of the
network software along the lines of the Stanford/MIT host table
described in an RFC earlier this year.  It isn't the function of a
particular operating system, but rather of trying to maintain ancient
software into eternity.  Are we talking about mail systems throughout
the network when we mention "existing network programs", or are we
talking about SNDMSG?

The way I am implementing my multiple-network support is to have the
host table know about every host on every network (a lie if ever there
was one!).  A host has a unique name throughout the universe, although
it may have many nicknames (also unique of course).  The software which
decides the data path through which a message should be delivered has
various built in parameters about the desirability of various paths,
including their cost, functionality, reliability, and access authorization.
Through some hair which hasn't been completely thought out yet (so far I'm
only worrying about three networks at a time), it decides on the best path
and tries to use it.

The initial implementation I am starting on uses a contention method.  As
a simple example, let's talk about mail from SU-SCORE to SU-LOTS.  Both
sites implement Dialnet, as does SU-AI, which is on the Arpanet along with
SU-SCORE.  There are therefore two processes who contend for the right to
send the message; the Dialnet process at SU-SCORE, and the Arpanet process
to SU-AI who will pass it on to SU-AI's Dialnet process to SU-LOTS.  The
SU-SCORE Dialnet process would try to grab the message first, as it knows
it can do the best job in delivering the message.  But suppose the SU-SCORE
Dialnet port is in use by another process.  The SU-SCORE Arpanet process
would then try to send it to SU-AI, who could either accept it or say
"my port is busy too, maybe you want to hold on to it".

The idea makes more sense as the number of paths increases.  You can
reasonably assign priority values for a certain process to handle traffic
to a certain ultimate destination.  The contention would be "first grab
first get", with the additional parameter that a process whose priority
is n can only try to grab traffic older than m, etc.  There are other
considerations which hair it up a bit - is this traffic authorized to use
the Arpanet?  Is this traffic going to pay the phone bill? etc...

Under this scheme, I don't use a specific network at all!  Just USER@HOST.
My smart mega-buck computer is supposed to figure out how to get the
message there.  I don't say this way solves all things, but it's interesting
to think about.

Mark
-------

Date:  4 July 1979 11:42 edt
From:  Frankston.Frankston at MIT-Multics
Subject:  Re: inter-network addressing
To:  Mark Crispin <Admin.MRC at SU-SCORE>
cc:  Header-People at MIT-MC
In-Reply-To:  Msg of 07/04/79 09:13 from Mark Crispin

Mark, I agree that it is nice to have systems which take care of details
of getting mail from point A to point B.  But.

I do not like systems that are restrictive about points A and B.

Does your scheme allow any alternative to using the central and
centrally administered tables for sending mail?  If I want to send mail
to a destination via a third host C, which your tables know about, but
with a final desintation of B, of which your host is not aware? Can I
say "send mail to B via C"?  or does it require intevention by the
system admnistrater.

Also, is your scheme susceptable to the NxN problem where all hosts must
Know about all other hosts -- soon to be a 100000 of them (not counting
telephones)?


My basic dislike of any scheme for which I must go through a central
registration process is that I will be personally penalized since I will
rapidly fall into the class of users make disproportional use of the
unusal cases requiring intervention by the admInistrators and secondly I
do not want to be in a position where others judge the appropriateness
of my requests--something inevitable ina  beauracracy.

Date:  5 Jul 1979 0018-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: inter-network addressing
To: Frankston.Frankston at MIT-MULTICS
Cc: Header-People at MIT-MC

At the present time the design has not been committed to stone.  I
don't see the administrative problems.  Maybe it's because it has been
a long time since I have had to deal with THAT oppressive a bureaucracy.
I just don't feel that in the normal case the user should have to be
bothered with routing considerations.  As I said I don't claim that this
is the ultimate right thing, but rather what seems to be the right thing
for our immediate need.  We have seven -10 systems at Stanford - two
Tenexs, one WAITS, Three Tops-20s, and a new machine which may be Tenex
or Tops-20.  We have several -11's and other machines, including the
IBM 3330 (or 3033 or whatever they call the thing.  It's the one
that replaces a 370).  We have Arpanet, Dialnet, Ethernet, DECnet, and
innumerable little private hookups; and we want these people to all talk
with each other (well, maybe not the IBM machine and DECnet - they're a
different world at Stanford).

From a wizard's point of view, there will have to be a method to force
explicit specification of routing, else it would be difficult to
debug the communications protocols, etc.  I do want to spare the user
this nonsense whenever possible.

The right thing for host information seems to be to have some sort of
central service whose sole functin in life is to know how is connected
to who.  Possibly in the implementation in the sky this thing would also
figure out the routing.  It still needs a lot of thought and the ideas
are bound to change a lot before it is finally implemented.

Mark

PS Forgive the typos.  I am in a hotel in San Francisco at Westercon using
this primitive TInoisy terminal.  Sigh.
-------

Date:  5 Jul 1979 0905-PDT
From: Feinler at SRI-KL (Jake Feinler)
Subject: Re: inter-network addressing
To:   Admin.MRC at SU-SCORE, Header-People at MIT-MC
cc:   FEINLER

In response to the message sent   4 Jul 1979 0613-PDT from Admin.MRC@SU-SCORE

Mark,

I believe there is a flaw in your statement that each host has a
unique name in the universe.  This is not necessarily true.
There may be many occasions where two or more hosts can have the same
name on different networks.  What should be universally unique is the
host address.  That is, no message sent to a given address
should be delivered in several places due to conflicting addresses.

Jake
-------

Date:  5 Jul 1979 1824-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: inter-network addressing
To: Feinler at SRI-KL
Cc: Header-People at MIT-MC

Jake,

I think you have missed my point.  I don't claim that my scheme is an
end-all.  Obviously if the powers that be are intent upon allowing a
chaos of names to occur, then the world will be stuck with numbers
(aka "network addresses" of ever increasing magnitute).  I don't see
why this has to be that way.  I don't think the way I proposed if the
ultimate right thing - far from it!  But I think it is a closer step
in the right direction.  I don't think that explicit routing instructions
are desirable, nor do I feel they are necessary.

I was presenting as an example a very local scheme - unifying the
communications networks used at Stanford (for the most part anyway).
Perhaps MIT will do this with their Chaosnet - I believe the "SUPDUP"
display TELNET there uses contention to get to the other host.  I may
be wrong (MIT hackers please correct!) but as I understand it it first
tries Chaosnet and then Arpanet.  I think that a similar thing can be
done with daemon processes, although on a more advanced level.

I believe that host names can be kept unique and should while they
still are (for the most part anyway).  I hope they are.

Mark

PS Excuse typos - still using the TInoisy.
-------

Date: 5 JUL 1979 2151-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Supdup, multi-networking, MRC's contention
To: HEADER-PEOPLE at MIT-MC

The contention Mark might have been thinking of is in the Chaosnet
routing algorithm (at the NCP level), not in any existing higher-level
protocol.  Also it's not the same as what he describes.

The ITS supdup program does not use contention.  It knows how to use
two networks (Arpanet and Chaosnet), and chooses the (statically)
faster of the two, unless it is constrained to use a particular network
by the site it's running on, the site it's trying to get to, or a
specification by the user.  It does not take into account one network
being down or unusually-heavily loaded.  Nor does it take into account
the case of the site it's on and the site it's trying to get to not
being on some single network.

The supdup program (and others) on the Lisp machine knows it's always
on the Chaosnet, and knows that on that network it can find a gateway
to the Arpanet, which it uses if you connect to a host which is not
attached to the Chaosnet.

None of this is sophisticated enough to qualify as a model for general
internetwork use.  Nor have we dealt with internetwork host naming at
the "mail" level; we are waiting for some group such as the internet
group to come up with a viable proposal (although this hope certainly
seems vain at this point.) 

Date:  5 JUL 1979 2050-PDT
From: POSTEL at USC-ISIB
Subject: re: foo at bar at frob at zork
To:   Header-People at MIT-MC


Bob Frankston:

i agree.

1) interim things do have a way of turning permanent. so we need to avoid
being in an interim state for very long.  RFC753 (aka IEN85) is a first
draft attempt to guess at what the future should be.  Please send me any
further comments you may have.

2) the number of things to act as sources and sinks for packets and or
messages is going to be huge, and no central authority will know about
them all. any naming scheme will have to be hierarchical, but the 
interconnection of these things will not follow any hierarchy, so the
kind of address as "address as route" will have to be allowed.  This type
of address is called "source routing" in some of the literature.

3) the internet group is focusing on experiments in the networks that
arpa controls or has strong influence over.  It turns out that this is
a small number so it is hard to press a case for super generality in the
face of the need to get some experiments working.

4) process are the ultimate sources and sinks of the data,  all this
stuff we build (layers of protocol) amount to an interprocess communication
system.

--jon.
-------

Date:     6 July 1979 2334-edt
From:     Bob Frankston              <Frankston at MIT-Multics>
Subject:  inter-network addressing
To:       Admin.MRC at SU-SCORE
Cc:       header-people at mit-mc

I agree that automatic routing is nice and necessary.
I a am just afraid of its being the only choice.


Date: Sat, 7 Jul 79 15:13-EDT
From: Dave Crocker <Dcrocker @ UDel-EE>
Reply-to: Dave at Rand-Unix
Subject: Use of "Udel-EE" as hostname
To: Header-People at Mit-Mc
cc: Farber at UDel-EE
Message-ID: <79187.54810.3701 @ UDel-EE>

We would like to stop using the Reply-To mechanism for telling
respondants what address to really reply-to, given that UDel-EE
isn't a host on the net, but we first need to check if all the
major (and as many minor as possible) hosts have us aliased
with Rand-Unix.

Any of you out there NOT have us in your tables (UDel-EE as
decimal host number 199)?

Thanks.  Dave.

Date:  7 Aug 1979 1544-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: strange headers
To: Header-People at MIT-MC

Look at this header!  It blew the mind of my mail reader
                ---------------
Mail from CMU-10A rcvd at 7-Aug-79 1206-PDT
Date: Tuesday,  7 August 1979 1502-EDT
From: Ivor Durham
Subject: RFC 441
Sender: TF00 at CMU-10A (F100TF00)
To:   Feinler @ SRI-KL
CC:   Admin.MRC @ SU-SCORE
Reply-To: The Finger at CMU-10A (The Finger <TF00 at CMU-10A> (F100TF00))
Message-ID: <07Aug79 150213 TF00@CMU-10A>
-------

Date: Tuesday,  7 August 1979 1857-EDT
From: Brian.Reid at CMU-10A
Subject: Re: strange headers
To:   Mark Crispin <Admin.MRC at SU-SCORE>
CC:   Header-People at MIT-MC
Message-ID: <07Aug79 185715 BR10@CMU-10A>
In-Reply-To: Mark Crispin's message of 7 Aug 79 17:44-EST

Bizzarre but legal.  That header must have escaped while we were testing
Rdmail.

Date: 3 SEP 1979 2117-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Forwarded message from Lauren Weinstein
To: HEADER-PEOPLE at MIT-MC

Date: 3 Sep 1979 1231-PDT (Monday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: mailing lists
To: BUG-FTP at AI

I am not sure who this message should be directed to, so I am sending it here
in the hope (you) will forward it to the correct entity.  One of the biggest
problems I've seen with mailing lists around the net (especially the
automatic repeater type) is the message traffic generated by people wanting
on/off the lists.  We see continual messages concerning "please don't send
to the list, send to FOO for such matters", but it never really does any
good -- for an obvious reason:  people don't remember the maintainers
generally, and new people only know about the list and have nowhere else
to go.  I have a suggestion concerning this problem.  

How about setting up a universal alias for the maintainer of a mailing
list that is related to the mailing list name?  That is, the info-terms
list might be maintainted by: "info-terms-maint" or whatever.  This
suffix or whatever would be widely advertised (like through MSGGROUP,
etc.) and would eventually be generally expected and known.  I would
even suspect that at many sites it would not be particularly hard
to implement (though getting it set up for the currently existing
mailing lists at ITS sites would be a one-time pain of course).

What do you think?  I'd appreciate comments and forwarding of this message
to interested parties -- I think this is a problem whose time has come.

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


Date:  4 September 1979 1647-EDT
From: David Lamb
Subject: case distinctions in mail destinations
Sender: RdMail at CMU-10A
To:   header-people at mit-mc
Reply-To: RdMail at CMU-10A
Message-ID: <04Sep79 164735 RD00@CMU-10A>

I have recently been told that some mailers out there consider mail
names to be different if they have different case (e.g., Lamb and LAMB
would be different names).  This note is to (a) ask you folks to
verify whether this is true and (b) suggest that this sort of distinction
is a bad idea.

This came up in the context of RDMAIL's duplicate-removal code.  Suppose
I receive mail of the following form

To: Lamb at CMU-10A
From: Person at Site1
CC: PERSON2 at Site1, PERSON at Site1

By default, when I reply to this I send CC's to everyone in the original
CC field, giving

From: Lamb at CMU-10A
To: Person at Site1
CC: PERSON2 at Site1, PERSON at Site1

A few weeks ago RDMAIL was modified to send only one copy of the mail to
PERSON at Site1 (it leaves the CC field alone, unlike some mailers that
would have eliminated the occurrence of PERSON there).  However, some people
claimed that I wasn't allowed to do this, because Person and PERSON could be
different.  The harder problem is, unless we are willing to record properties
of all mailers on all sites, the fact that some random site on the net
insists that PERSON and Person are different means that two sites which
case-fold all names are stuck with getting duplicates, even though their
own mailers can handle the situation.

On the strength of the complaint, we took case-folding out except for mail
to other CMU hosts.  I would like to put it back in.  How many of you out
there would be grossly inconvenienced by this?

			David Alex Lamb

Date: Tuesday,  4 September 1979 1717-EDT
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: case distinctions in mail destinations
To:   David.Lamb at CMU-10A
CC:   header-people at mit-mc
Message-ID: <04Sep79 171749 RG02@CMU-10A>
In-Reply-To: <04Sep79 164735 RD00@CMU-10A>

another question to append to David's question: if the names can
be considered equivalent, then which name should be retained?

		Rick Gumpertz

Date: 04 Sep 1979 1443-PDT
From: Mark Crispin <MRC at SU-AI>
To:   Header-People at MIT-MC    

My feeling is that PERSON and Person should be considered identical, and it
is a bug in any operating system which insists that PERSON and Person are
different.  I believe that even Multics' mail server was fixed to figure out
that PERSON meant Person and did the right thing.



Date: Tuesday,  4 September 1979 1839-EDT
From: Brian.Reid at CMU-10A
Subject: Re: case distinctions in mail destinations
To:   RdMail at CMU-10A
CC:   header-people at mit-mc
Message-ID: <04Sep79 183946 BR10@CMU-10A>
In-Reply-To: <04Sep79 164735 RD00@CMU-10A>

"a" and "A" are the same letter, and anybody who thinks otherwise it 
completely wedged.

Date: 4 September 1979 19:07-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  case distinctions in mail destinations
To: Brian.Reid at CMU-10A
cc: HEADER-PEOPLE at MIT-MC, RdMail at CMU-10A

    Date: Tuesday,  4 September 1979 1839-EDT
    From: Brian.Reid at CMU-10A
    To:   RdMail at CMU-10A
    cc:   header-people
    Re:   case distinctions in mail destinations

    "a" and "A" are the same letter, and anybody who thinks otherwise it 
    completely wedged.

Anyone who makes such sweeping generalizations is completely wedged.

Date: 4 September 1979 22:39-EDT
From: Ken Harrenstien <KLH at MIT-AI>
Subject: case distinctions in mail destinations
To: RdMail at CMU-10A, header-people at MIT-MC

As with so many other topics, this one was likewise beaten
into the dust back in the early days of Header-people.
If you have a copy of the archives, search on appropriate
keywords like case-independence...
 My views haven't changed since.  It's not surprising that
the expected problems have manifested themselves.


Date: 4 Sep 1979 8:58 pm (Tuesday)
From: Karlton at PARC-MAXC
Subject: Re: case distinctions in mail destinations
In-reply-to: <04Sep79 164735 RD00@CMU-10A>
To: RdMail at CMU-10A
cc: header-people at mit-mc, David.Lamb at CMU-10A

David,

Some mailers out there consider the names different.  That should be
enough for you to make sure that names don't get thrown away if that
raises the possiblity that some mail might be lost.  You can, however,
take advantage of the special knowledge that CMU does case folding for
delivery, and remove duplicates (except for case) to CMU sites.

It is not a very serious thing to send duplicates to a user at a remote site
because the names are spelled differently.  The mail delivery program (or
even the reader) might be able to figure out that it can chuck the
duplicates and the recipient will never notice.  If not, the user will not
be very inconvenienced.  The "right" thing will usually happen (i.e.
no differenly capitilized names will be in the same mailing); but, when
it doesn't, it is best to error on the side of not losing anything.

PK


Date: 4 SEP 1979 2113-PDT
Sender: POSTEL at USC-ISIB
Subject: Re: case distinctions in mail destinations
From: POSTEL at USC-ISIB
To: Karlton at PARC-MAXC, RdMail at CMU-10A
Cc: header-people at MIT-MC, David.Lamb at CMU-10A
Message-ID: <[USC-ISIB]4-SEP-79 21:13:24-PDT.POSTEL>

In response to the message sent 4 Sep 1979 8:58 pm (Tuesday) from Karlton@PARC-MAXC

the mail program i use has the novel feature of asking the user! every
once in a while i am asked if PERSON is the same as Person and it
almost (what a word) always is.

--jon.
-------

Date: Wednesday,  5 September 1979 0057-EDT
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: case distinctions in mail destinations
To:   David.Lamb at CMU-10A
CC:   header-people at mit-mc
Message-ID: <05Sep79 005750 RG02@CMU-10A>
In-Reply-To: <04Sep79 164735 RD00@CMU-10A>

David -

The more I think about it, you wil rarely get two names capitalized differently
from foreign hosts in the kind of situation you are considering.  Therfore
I suggest that you just ignore the problem (i.e. err on the side of conserving
the names as if different).  As someone said, the consequences are not great at
all if a duplicate arrives.

		Rick

Date:  4 Sep 1979 2137-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: case in names
To: Header-People at MIT-MC

I suspect most of the problem comes about when replying to a message
originating at a TENEX or Tops-20 site.  A user might have a cute form
of his/her account name in the header, but the real account name is
all upper case.  For example, my account name is really "ADMIN.MRC",
but I put "Admin.MRC" in my headers because I think it looks better.
I think a couple of the TENEX/Tops-20 mail systems (not MM, which is
what is in use here) reflect the user's desire to have CC's of all
his/her messages as a flag and not as an address list.  Therefore,
when the mail system generates the header it puts in the CC list the
account name, and not the user's cute form.  Since TENEX/Tops-20
don't care about case, it makes sense to be case independant.

How about these questions:

	What mailers out there consider PERSON and Person different?
	What systems actually have a PERSON and a Person as different
	 users?

I know, for example, that Multics has PERSON and Person as different
entities, but I have been told that in real life they don't allow such
conflicts to happen and that the netmail server is smart enough to do
the appropriate mapping.

No PDP-10 operating system has such a thing as Person as a different
account name from PERSON.  It IS theoretically possible on TENEX and
Tops-20, but using it is so difficult as to be impractical (how would
you like having to type control-V before every lower case character in
your account ID?).

The mail system in use at SCORE, MM, in fact does treat PERSON as
Person and will continue to do so.  I will resist that ever being
changed.  Case-invisibility is one of the most important human
engineering features of all PDP-10 operating systems, and one of the
easiest to export elsewhere.
-------

Date:  9 September 1979 14:07 edt
From:  Frankston.Frankston at MIT-Multics (Bob Frankston)
Subject:  name ~=name
To:  header-people at MIT-MC
Message-ID:  <790909180703.231030 at MIT-Multics>

As pointed out this is an old topic.  To restate my position briefly.

1. Since the recipient, using message-id's can eliminate duplication
that should be sufficient.  (Prvoided people finally begin to send
message ids again).

2. If the mailer can decide that "RMF at mit-mc" and "bob at
mit-multics" are both me as well as my other accept such an
implementation.  Those are the reasons I get duplicates.  Actually the
main reason for dupilcation is for things like a letter to info-micro
with a cc to info-terms or something like that.  Offhand I don't
remember having to deal with Frankston vs FRANKSTON in headers, though
that may have occured.  The point is that why bother Implementating a
program to deal with a trivial case when there is a chance of lossage. 
For example, JTAble.Foo and JTable.Foo on Mit Multics.  If ther eis a
network table entry then only one would get in as JTABLE (case not
mattering).  But if you want to send mail using a stndard  Multics
name.project hen cse does, and _s_h_o_u_l_d matter since your are then using
Multics internal conventions.  As we extend mail to other networks there
will be other internal conventions to deal with and you better not go
mucking around with headers that you don't know the rules for!

Date:  5 Oct 1979 1739-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: SAIL filenames for distribution lists
To: Bug-MAIL at SU-AI
cc: Header-People at MIT-MC

The Tops-20 and Tenex MAILER daemon cannot parse SU-AI
filename addresses like:
	"@FAC.DIS[1,DPB]" at SU-AI
because this gets translated as a queued request to
"@FAC.DIS[1,DPB]"@SU-AI and the first @ confuses it.  While
MM handles this alright MAILER is too dumb to, and it's up
to MAILER to deliver the message.

While I could make MAILER a little bit smarter with some
work, it seems to me it would be better if you fix your mail
system to send filespec addresses in some other way, or to
make more estensive use of pseudo-people.  "Better" here
means for the benefit of other sites on the network.  You
can argue that this is legal RFC733 syntax and all that, but
I doubt that the world is going to change to fix this
bug, especially when only one host generates this format of
address and the program which has trouble with it runs on
many hosts.

You cannot hope for everybody to change their versions of
Tops-20/Tenex MAILER.  I am told that other mail systems
have problems with this kind of address too and that the
overhead of parsing it correctly is too expensive to warrant
fixing it.

Unlike Tops-20 and Tenex, the SU-AI mail system DOES have
pseudo-people, so I don't see any logical reason for not
using it.  I doubt anybody would use file mailing here if we
had pseudo-people, which is why I'd rather work on
implementing that instead of parsing @'s in site addresses.
-------

Date: 27 Oct 1979 1919-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: spaces around at-signs
To: Header-People at MIT-MC

Is an address of the form "csl.dra @ su-score" legal?  MM gets upset
by this, thinking the address is local user "csl.dra " which does not
exist (note that space is a valid although unlikely character in an
account name on TENEX and TOPS-20).  MM's understanding of the world
is that "csl.dra at su-score" or "csl.dra@su-score" mean "csl.dra".
It's the @ with whitespace that confuses it.

The mailer which sent this address was CMU-10A's.

If the form is legal, I would like to campaign for its removal.  If
we must have whitespace in an address let's use "at" instead of "@".
-------

Date: 27 October 1979 2258-EDT
From: David Lamb
Subject: Re: spaces around at-signs
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: <27Oct79 225834 RD00@CMU-10A>
In-Reply-To: Mark Crispin's message of 27 Oct 79 21:19-EST

RFC733.TXT includes at least one example of spaces around at signs.
Also, the BNF indicates that "@" is used in the same context as "at"
(n.b. not " at ").  It does say that the whitespace around the "@"
should be removed if passing the host name through a gateway that
doesn't conform to the standard.  I conclude that the spaces are
allowed by the standard.  However, I am willing to consider trying to
compress out the spaces in RDMAIL if the change turns out to not be
too difficult.  (No promises as to when).

				David Alex Lamb

Date: 28 Oct 79 14:42-EST (Sun)
From: Dcrocker at UDel-EE
Reply-to: Dcrocker at Rand-Unix
Subject: Re: spaces around at-signs
To: Mark Crispin <Admin.MRC at Su-Score>
cc: header-people at Mit-Mc
Message-ID: <79300.52943.9080 @ UDel-EE>
In-Reply-To: Your message of 27 Oct 1979 1919-PDT

"csl.dra @ su-score" is completely legal, syntactically; and I find it
hard to believe that you want arbitrary linear white space to be
illegal between lexical units.  The state of the art hasn't been that
baroque for several decades, Mark.  Sounds like MM needs the fixing.

Dave.

P.S. to David Lamb:  I would strongly recommend NOT changing RDMAIL,
on this score (probably a pun, there).  

P.P.S.  Perhaps it would be useful if I cite some of the relevant
portions of RFC733, on this matter; it is clearly-enough worded
that it is difficult to miss.  Sectiofn III.B.3.a is titled
"White space".  (page 10 of the original document and page 350 in
the protocol handbook):  "...multiple linear white space telnet
ascii characters... are treated as single spaces and may freely
surround any symbol."  and "wherever a member of the list of
<delimiter>s is allowed, lwsp-chars may also occur before and/or
after it."  Both quotation appear in the original as all-upper
case and the second quotation is in its own paragraph.

D/

Date: 28 Oct 1979 1410-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: spaces around at-signs
To: DCrocker at RAND-UNIX
cc: RdMail at CMU-10A, Header-People at MIT-MC

Dave -

I repressed a very strong desire to lash out at your message.
Really.  I don't think that anybody can expect a mail system
to implement all of RFC 733.  The network wonder-system, HERMES,
not only doesn't implement all of 733 but in fact violates it
in several places.  MM tries to handle a reasonable subset, and
in fact, it does.  "foo @ bar" just ain't encountered all that
often.  MM would certainly never generate an address that looks
like that, and it would be very hard for it to accept it on
typein or a distribution list.  TOPS-20's built-in command
parser just wasn't set up for that sort of thing and it is in
fact pretty remarkable that it can parse a network address at
all.  [Please - no nasty comments about how "baroque" this is
or I will be glad to oblige you with several thousand words of
flamage about the ways Unix loses.]

If this was a major hardship upon a large number of network
users to change their mail systems, that would be one thing.
However, in this instant it did not seem that way.  MM (and
its DEC-distributed variant MS) does run on more systems than
the CMU mailer.  The maintainers of the CMU mailer graciously
agreed to change their mail system.  The thing is, we have
sent mail to CMU before without a problem so obviously this
is not CMU's standard format address but rather what comes out
in some set of circumstances.

It seems to be that the right philsophy is that if something
unusual from one site breaks a mail reader at some number of
other sites, then it's up to the site generating the offending
format message to change their mail system to not do the
offending thing, even if it IS part of the standard.  Most
people seemed to be concerned about communication first and
cuteness (or revenge against somebody trying to limit the
standard) last.

By the way, Dave, is your mail system still generating the
space in the blank line after the header?  I could imagine
somebody with your attitude on punishing those who don't
implement the standard having a mail system that bounces
such a blatant violation back to the sender with a CC to
header-people, msggroup, the CIA, the FBI, the KCIA, the
KGB, Senator Proxmire,...  The possibilities are endless!

-- Mark
-------

Date: 28 Oct 1979 1416-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: [Mailer Daemon <Operator at SU-SCORE>: Undeliverable mail]
To: Header-People at MIT-MC
cc: DCrocker at RAND-UNIX

Here's what happened to me when I tried to reply to Dave Crocker.
Seems like somebody's FTP server is returning the wrong error code!
                ---------------
Date: 28 Oct 1979 1413-PST
From: Mailer Daemon <Operator at SU-SCORE>
Subject: Undeliverable mail
To:   ADMIN.MRC

Mail for DCrocker at RAND-UNIX not deliverable because:
 Mail trouble, please try again later

------
                ---------------
-------

Date: Sunday, 28 October 1979 1741-EST
From: Brian.Reid at CMU-10A
Subject: RFC733
To:   Mark Crispin <Admin.MRC at SU-SCORE>
CC:   DCrocker at RAND-UNIX, RdMail at CMU-10A, Header-People at MIT-MC
Message-ID: <28Oct79 174101 BR10@CMU-10A>
In-Reply-To: Mark Crispin's message of 28 Oct 79 17:10-EST

Since I played only an advisory role in its development, I feel free to
mention that CMU's rdmail (really Philip Karlton's rdmail), as far as I
know, implements all of RFC733, and can read any header that
corresponds to that standard and a lot that don't.  On the other hand,
it was still being developed while RFC733 was being finalized, so it had
a much better opportunity to be adapted to the full standard.

Brian


Date: Sunday, 28 October 1979 1823-EST
From: Brian.Reid at CMU-10A
Subject: Re: [Mailer Daemon <Operator at SU-SCORE>: Undeliverable mail]
To:   Mark Crispin <Admin.MRC at SU-SCORE>
CC:   Header-People at MIT-MC, DCrocker at RAND-UNIX
Message-ID: <28Oct79 182329 BR10@CMU-10A>
In-Reply-To: Mark Crispin's message of 28 Oct 79 17:16-EST

Actually, everybody's FTP server returns the wrong error codes.
It's just one of those facts of life, like dirty air and dog droppings.

Date: 28 Oct 79 21:34-EST (Sun)
From: Dcrocker at UDel-EE
Reply-to: Dcrocker at Rand-Unix
Subject: Re: spaces around at-signs
To: Mark Crispin <Admin.MRC at Su-Score>
cc: RdMail at Cmu-10a, Header-People at Mit-Mc
Message-ID: <79300.77644.1541 @ UDel-EE>
In-Reply-To: Your message of 28 Oct 1979 1410-PST

I did not advocate everyone's being required to implement all of
733.  I DID note the deficiency of a parser that can't handled
something like white space around lexical units.  Citing 733 was
by way of making clear that a) it is legal in 733, and b) it is
clearly explained.

More to the point, you may not currently be encountering " @ "
very often, but it is simply too trivial to generate for it to be
reasonable to prohibit it.  Some of our messages go out that way.

Do not assume that because I use a Unix I am in love with all of]
it and hopelessly biased against Twenex.

The Unix mail-sending program that puts a space in the "blank"
line separating headers from the body is not mine and never was.
It was imported to Rand (from Berkeley?).  Greep hacked on that
program alot.  He's indicated that he even once fixed the bug,
but somehow it migrated back.  To reiterate, the program in
question (sndmsg) is not part of the older Rand MS system or the
newer MH one.

Dave.

Date: 29 OCT 1979 0246-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: " @ "
To: HEADER-PEOPLE at MIT-MC

Please cease to fill my mailbox with unnecessary flaming.  It was
a bug and it took MMcM 30 seconds to fix it, once he was informed
of its existence.

Date: Friday,  2 November 1979 1742-EST
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: "Your" [in-reply-to field]
To:   JMCHUGH at USC-ECL
CC:   Header-People @ MIT-MC
Message-ID: <02Nov79 174212 RG02@CMU-10A>
In-Reply-To: JMCHUGH's message of 2 Nov 79 16:44-EST

Well, it should be Rick Gumpertz' with no "s" after the apostrophe, but
other than that you got the gist of what I was saying.  Still, when a
reply goes to other than the author I think it is important that the
terms "you" and "your" not be used.

		Rick

P.S. CMU RDMAIL will append just ' without an S!!!

Date: Saturday,  3 November 1979 1255-EST
From: Philip L. Lehman <Philip.Lehman at CMU-10A> (C410PL30)
Subject: Re: "Your" [in-reply-to field]
To:   Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
CC:   JMCHUGH at USC-ECL, Header-People @ MIT-MC
Message-ID: <03Nov79 125524 PL30@CMU-10A>
In-Reply-To: <02Nov79 174212 RG02@CMU-10A>

Actually, Rick, I disagree.  It SHOULD be "Rick Gumpertz's" WITH an
apostrophe.  The very first rule in Strunk and White (The Elements
of Style(*)) is:

       "1.  Form the possessive singular of nouns by adding 's.
	   "Follow this rule whatever the final consonant.  Thus write,
		Charles's friend
		Burns's poems
		the witch's malice

	   "Exceptions are the possessives of ancient proper names [ending]
	in -es and -is, the possessive Jesus', and such forms as for
	conscience' sake, for righteousness' sake."

Alas, writing and usage today are dictated mostly by personal whim,
and anything goes.

I actually think the "'s" code should be removed from RDMAIL, since it's
unlikely that Jesus will LOGIN in the near future.

				Philip

(*) Published by MacMillan. A small paperback, now in its third edition,
and well worth the price -- whatever it is.  I believe it's still an
incredible bargain at $1.95!

Date: 5 November 1979 03:48-EST
From: Mike McMahon <MMCM at MIT-MC>
Subject: Re: "Your" [in-reply-to field]
To: Philip.Lehman at CMU-10A
cc: HEADER-PEOPLE at MIT-MC

    "1.  Form the possessive singular of nouns by adding 's.
Ah, but there is no assurance that the field being replied to is singular, e.g.
From: The Smiths <SMITH@SITE>

Date:  5 Nov 1979 14:50:24 EST
From: Dan Franklin<dan at BBN-UNIX>
Subject: Re: in-reply-to field
To: Philip.Lehman at cmu-10A
Cc: header-people at mit-mc

However, the rule for nouns and proper nouns is not necessarily the same as the
rule for proper names - a case which the Chicago Style Manual ('A Manual of
Style', The University of Chicago Press), distinguishes:

(p. 78)
    117. Form the possessive of a proper name ending in s or another sibilant,
    if monosyllabic, by addinng an apostrophe and s; if of more than one syllable
    (except names ending in -ce), by adding an apostrophe only (see sections 176
    and 177 for other rules ...):

    Burns's poems	Jesus' birth	    Berlioz' compositions
    Marx's theories	Moses' law	    Demosthenes' orations
    Sophocles' stories	conscience' sake    Horace's odes

			Exceptions

    But in the case of a proper name ending in a silent sibilant the possessive
    is formed by the addition of the apostrophe and s, whether the word is
    monosyllabic or not:

	Charlevoix's discoveries	Des Moines' population

This rule would produce Gumpertz' because Gumpertz is polysyllabic.
(The 'other rules' mentioned above describe the rules for nouns and agree with
Strunk and White.) On the other hand, the 'Manual of Style' appears to be trying
to rationalize what are essentially historical differences, judging from
'A Dictionary of Modern English Usage', by H. W. Fowler:

(p. 466, under 'possessive puzzles')

	I. Septimus's, Achilles'. It was formerly customary, when a word ended
    in -s, to write its possessive with an apostrophe but no additional s, e.g.
    Mars' hill, Venus' bath, Achilles' thews. In verse, and in poetic or
    reverential contexts, this custom is retained ... But elsewhere we now
    usually add the s and the syllable -- always when the word is monosyllabic,
    and preferably when it is longer, Charles's Wain, St. James's Street,
    Jones's children, the Rev. Septimus's surplice, Pythagoras's doctrines.

So the real question is whether the In-Reply-To: field is 'poetic or
reverential' or not. If so, Rick is right.

Date:  5 Nov 1979 14:50:24 EST
From: Dan Franklin<dan at BBN-UNIX>
Subject: Re: in-reply-to field
To: Philip.Lehman at cmu-10A
Cc: header-people at mit-mc

However, the rule for nouns and proper nouns is not necessarily the same as the
rule for proper names - a case which the Chicago Style Manual ('A Manual of
Style', The University of Chicago Press), distinguishes:

(p. 78)
    117. Form the possessive of a proper name ending in s or another sibilant,
    if monosyllabic, by adding an apostrophe and s; if of more than one syllable
    (except names ending in -ce), by adding an apostrophe only (see sections 176
    and 177 for other rules ...):

    Burns's poems	Jesus' birth	    Berlioz' compositions
    Marx's theories	Moses' law	    Demosthenes' orations
    Sophocles' stories	conscience' sake    Horace's odes

			Exceptions

    But in the case of a proper name ending in a silent sibilant the possessive
    is formed by the addition of the apostrophe and s, whether the word is
    monosyllabic or not:

	Charlevoix's discoveries	Des Moines' population

This rule would produce Gumpertz' because Gumpertz is polysyllabic.
(The 'other rules' mentioned above describe the rules for nouns and agree with
Strunk and White.) On the other hand, the 'Manual of Style' appears to be trying
to rationalize what are essentially historical differences, judging from
'A Dictionary of Modern English Usage', by H. W. Fowler:

(p. 466, under 'possessive puzzles')

	I. Septimus's, Achilles'. It was formerly customary, when a word ended
    in -s, to write its possessive with an apostrophe but no additional s, e.g.
    Mars' hill, Venus' bath, Achilles' thews. In verse, and in poetic or
    reverential contexts, this custom is retained ... But elsewhere we now
    usually add the s and the syllable -- always when the word is monosyllabic,
    and preferably when it is longer, Charles's Wain, St. James's Street,
    Jones's children, the Rev. Septimus's surplice, Pythagoras's doctrines.

So the real question is whether the In-Reply-To: field is 'poetic or
reverential' or not. If so, Rick is right.

Date:  5 Nov 1979 1336-PST
From: Zellich at OFFICE-1
Subject: Re: in-reply-to field
To:   Header-People at MIT-MC

In reply to the message from Dan Franklin<dan at BBN-UNIX>, 5 Nov 1979 14:50:24 EST

The excerpted treatises on style are all very interesting, but why
not just do it as above?  i.e. " the message from" xxx instead of
xxx "'s message"

Rich
-------

RMS@MIT-AI 11/05/79 16:36:39 Re: "CORRECT" POSSESSIVES.
To: HEADER-PEOPLE at MIT-MC
SINCE IT IS CLEAR THAT ONLY AN AI PROGRAM CAN FORM THE
POSSESSIVE "CORRECTLY", HOW ABOUT DROPPING THE SUBJECT?


Date:  5 Nov 1979 17:010:37 EST
From: Dan Franklin<dan at BBN-UNIX>
Subject: Re: in-reply-to field
To: Zellich at OFFICE-1
Cc:   Header-People at MIT-MC

That would be too easy. My message was intended mainly to saturate
people's capacity for this kind of discussion. I think I've succeeded.

Date:  9 November 1979 2023-EST (Friday)
From: Brian.Reid at CMU-10A
Subject: the best-laid plans...
To:   Header-People at MIT-MC
Message-ID: <09Nov79 202310 BR10@CMU-10A>

CMU Computer Science now has two people named John Nestor, spelled exactly
the same way.  So even our Firstname-Lastname scheme falls apart here.
Ironically, the "escape" mechanism that our account administrator used
to install the second account ("John JNestor") will lead to enormous amounts
of confusion.  Sigh.

Date:  9 NOV 1979 2118-PST
From: NMAX at USC-ECL
Subject: Re: the best-laid plans...
To:   Brian.Reid at CMU-10A, Header-People at MIT-MC
cc:   NMAX

In response to the message sent   9 November 1979 2023-EST (Friday) from Brian.Reid@CMU-10A

Chuckle - As the inventor of those BR10 person codes at CMU 15 years 
ago, and an observer of the long standing discussion about the need
for personalized (=humane) mailbox names, I have been quietly waiting
for this collision with reality that must obtain as our community
grows.  Have you thought of measuring their respective heights
and assigning a lower case mailbox name to the shorter member of the 
pair?  Chuckle, Chuckle (This from the dummy who sent a personal
reply to the whole msggroup list!)

Good luck - Stef
-------

Date: 10 November 1979 0210-EST (Saturday)
From: Brian.Reid at CMU-10A
Subject: Re: the best-laid plans...
To:   NMAX at USC-ECL
CC:   Brian.Reid at CMU-10A, Header-People at MIT-MC
Message-ID: <10Nov79 021007 BR10@CMU-10A>
In-Reply-To: NMAX' message of 10 Nov 79 00:18-EST

Believe it or not, we actually include the height of mail users in
our database (tho not the online version), and they are within a 
quarter of an inch (our resolution) of one another in height.
Before you get a chance to ask: the reason we include height is
for the assignment of physical mailboxes, so that tall people don't
have to stoop to see if they have mail, and short people don't
need to stand on a chair.  We try to assign a mailbox at eye level.


JBROWN@MIT-ML 11/11/79 03:12:15
To: header-people at MIT-MC
please remove me from the list

Date: 21 Nov 1979 1712-PST
From: Geoff at SRI-KA (Geoff Goodfellow)
Subject: Change in SRI-KA mail format.
To:   System
cc:   Cower, Header-People at MC

The format of the SRI-KA netmail header line has been changed to be
"Mail-from:" instead of "Mail from" to placate some people who think
that is should be considered part of the message header.
As a default, for HERMES users, you will not see this line printed out
anymore.  For those that desire it, you'll need to EDIT User-fields within
HERMES and then DECLARE Mail-From: in addition to adding it to your
various printing templates.

Perhaps more 10/20X sites will catch on and do likewise.
-------

Date: 22 Nov 1979 0745-EST
From: Michael Travers <MT at MIT-XX>
Subject: Re: Change in SRI-KA mail format.
To: Geoff at SRI-KA
cc: Cower at SRI-KA, Header-People at MIT-MC
In-Reply-To: Your message of 21-Nov-79 2012-EST

MIT-XX netmail header lines have also been changed to start with
"Mail-from:".
-------

Date: 22 Nov 1979 0841-PST
Sender: GEOFF at SRI-KA
Subject: Re: Change in SRI-KA mail format.
From: the tty of Geoffrey S. Goodfellow
To: MT at MIT-XX
Cc: Cower at SRI-KL, Header-People at MIT-MC
Message-ID: <[SRI-KA]22-Nov-79 08:41:04.GEOFF>
In-Reply-To: Your message of 22 Nov 1979 0745-EST
Reply-to: Geoff @ SRI-KA

SRI-KL, PARC-MAXC & PARC-MAXC2 also have joined in addition to XX
and KA.

Date: 15 Jan 1980 2212-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: implementation note to mailsystem implementors
To: MsgGroup at MIT-ML
cc: Header-People at MIT-MC

This note is addressed to anybody likely to implement or work on
a program which will send FTP mail.  It is well-known that for
Multics sites you must send USER NETML followed by PASS NETML
(and that NETML must be all upper case).  What isn't as
well-known is that the Multics FTP server sends TELNET protocol
commands; in particular, you are likely to encounter IAC GA in
your data stream.  If your user program is unprepared to handle
this, you are likely to get into trouble (he says from sad
experience).

In the strictest sense, Multics is not violating protocol either
by requiring NETML login or by sending the TELNET protocol
commands.  Both are explicitly allowed by the published protocol.
However, standard usage has been that no TELNET protocol commands
are used, although one or two other sites have used old TELNET
protocol to implement the ABOR feature.

The moral is: to be as robust as possible don't use TELNET
protocol or require NETML login, but be prepared to accept TELNET
protocol or to be told to use NETML at any time from any host.

-- Mark --

PS My apologies to those who received this message twice, or to
those of you who already knew all this.  I didn't know about the
TELNET protocol part (neither did the author of the mailer daemon
I am using); had I known before this several hours of my time and
quite possibly a system reload might have been prevented.
-------

20-JAN-80 11:14:06,1691
Net mail from site CCA rcvd at 20-JAN-80 11:14:05
Date: 20 JAN 1980 1114-EST
From: JZS at CCA (Joanne Z. Sattley)
Subject: Scheduled termination of Datacomputer Service
To:   Datacomputer Users:

I have been requested by ARPA to distribute the enclosed message.

***** begin enclosure

To All Datacomputer Users:

The TBM-based Datacomputer has become too expensive to operate.
We are faced with a combination of increasing maintenance costs
and a funding deficit which was created when a major user community's
need for the service ended.  The Ampex TBM hardware is obsolete,
and no compatible follow-on product is planned.  Therefore, with
much regret, we have decided that Datacomputer service on the ARPANET
must be terminated.

We want to make the transition off the Datacomputer as painless
as possible for existing users.  On the other hand, we want
to phase out the service as quickly as possible to avoid
needless expense.

Our plan is to stop accepting any additional files for storage,
effective immediately.  The Datacomputer will continue to operate
for retrieval only during the transition period.  We would like
users to retrieve their private files by March 15, 1980.  DFTP
public files will be saved automatically by the CCA staff.

We apologize for any problems which this decision causes you.
If there is something specific we can do to ease the transition,
we will do our best to help.  Send a message to JZS@CCA if you
have questions or need assistance.

Bill Carlson
Program Manager
DARPA/IPTO

***** end enclosure

It has been a genuine pleasure working with all of you.

For the Datacomputer Staff,

	-- Joanne
-------
   

Date: 1 February 1980 17:56-EST
From: Richard M. Stallman <RMS at MIT-AI>
Subject: headers
To: RMS at MIT-AI, KLH at MIT-AI, Rick.Gumpertz at CMU-10A,
    MOON at MIT-MC
cc: Header-People at MIT-MC

Logically speaking, "(BUG @)"@MIT-AI ought to suppress the meaning of
the parentheses and refer to a user named "(BUG @)", just as "Rick
Gumpertz"@CMU would suppress the meaning of the space and refer to a
user named "Rick Gumpertz".


Date:  1 February 1980 1707-EST (Friday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: headers
To:   MOON @ MIT-MC, RMS @ MIT-AI, KLH @ MIT-AI
CC:   Header-People @ MIT-MC
Message-ID: <01Feb80 170749 RG02@CMU-10A>

Any chance of getting you guys to put the parenthesized lists (such as
in the TO field below) in quotes as they go out on the ARPANET?

		Rick

- - - - Begin forwarded message - - - -
Date: 1 FEB 1980 0315-EST
From: HENRY at MIT-AI (Henry Lieberman)
Subject:  suggestion for feature
To: (BUG @) at MIT-AI

	...
- - - - End forwarded message - - - -

Date: 1 FEB 1980 1959-EST
From: MOON at MIT-MC (David A. Moon)
Subject: headers
To: Rick.Gumpertz at CMU-10A
CC: HEADER-PEOPLE at MIT-MC

    Date:  1 February 1980 1707-EST (Friday)
    From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
    Subject: headers
    To:   MOON @ MIT-MC, RMS @ MIT-AI, KLH @ MIT-AI
    CC:   Header-People @ MIT-MC
    Message-ID: <01Feb80 170749 RG02@CMU-10A>
    
    Any chance of getting you guys to put the parenthesized lists (such as
    in the TO field below) in quotes as they go out on the ARPANET?
    
    		Rick
    
    - - - - Begin forwarded message - - - -
    Date: 1 FEB 1980 0315-EST
    From: HENRY at MIT-AI (Henry Lieberman)
    Subject:  suggestion for feature
    To: (BUG @) at MIT-AI
    
    	...
    - - - - End forwarded message - - - -
To be brief, no.  If you want to know the reasons, review the Header-People minutes.

Date: 2 Feb 80 09:37-EST (Sat)
From: Dcrocker at UDel-EE
Reply-to: Dcrocker at Rand-Unix
Subject: Re: headers
To: David A. Moon <MOON at Mit-Mc>
cc: Rick.Gumpertz at Cmu-10a, HEADER-PEOPLE at Mit-Mc
Message-ID: <8032.34664.7180 @ UDel-EE>
In-Reply-To: Your message of 1 FEB 1980 1959-EST

    As I recall, the primary reason you guys aren't putting the
quotation marks around such strings is that you think they are ugly.

    Nonetheless, what you are -- technically -- sending is an address
comprising a comment and a host reference, with no mailbox specified.
Therefore, it is NOT a valid RFC733 address.

    With respect to "... suppress[ing] the meaning of the parentheses
and refer[ing] to a user named '(BUG @)', that interpretation applies
only to the (network) environment where the quoted string is passed,
uninterpreted.  When you guys get the string, you should remove the
quotation marks and parse the string as you normally would.

    For example, "Rick Gumpertz" is NOT the name of a CMU mailbox.
The string is parsed and mapped into something that IS.

Dave.

P.S.  Given the long history on the topic, your refusal to make the
      change comes as no great surprise.  It's been clear to me for a
      few years now that the only way these things get "enforced",
      given the absence of more centralized authority (which is fine
      with me) is through classic free-market mechanisms.  The rest of
      us will have to pointedly refuse to compensate for your failure
      and not ever send mail to these improperly specified addresses.
      To the extent that that imposes a burden on you, you will feel
      pressure to change.  In the current context, of course, a
      mediating factor is the extent to which Arpa IPTO people remain
      unaffected.

Date: 2 Feb 80 09:37-EST (Sat)
From: Dcrocker at UDel-EE
Reply-to: Dcrocker at Rand-Unix
Subject: Re: headers
To: David A. Moon <MOON at Mit-Mc>
cc: Rick.Gumpertz at Cmu-10a, HEADER-PEOPLE at Mit-Mc
Message-ID: <8032.34664.7180 @ UDel-EE>
In-Reply-To: Your message of 1 FEB 1980 1959-EST

    As I recall, the primary reason you guys aren't putting the
quotation marks around such strings is that you think they are ugly.

    Nonetheless, what you are -- technically -- sending is an address
comprising a comment and a host reference, with no mailbox specified.
Therefore, it is NOT a valid RFC733 address.

    With respect to "... suppress[ing] the meaning of the parentheses
and refer[ing] to a user named '(BUG @)', that interpretation applies
only to the (network) environment where the quoted string is passed,
uninterpreted.  When you guys get the string, you should remove the
quotation marks and parse the string as you normally would.

    For example, "Rick Gumpertz" is NOT the name of a CMU mailbox.
The string is parsed and mapped into something that IS.

Dave.

P.S.  Given the long history on the topic, your refusal to make the
      change comes as no great surprise.  It's been clear to me for a
      few years now that the only way these things get "enforced",
      given the absence of more centralized authority (which is fine
      with me) is through classic free-market mechanisms.  The rest of
      us will have to pointedly refuse to compensate for your failure
      and not ever send mail to these improperly specified addresses.
      To the extent that that imposes a burden on you, you will feel
      pressure to change.  In the current context, of course, a
      mediating factor is the extent to which Arpa IPTO people remain
      unaffected.

Date:  2 Feb 1980 1126-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Re: headers (into the fray!)
To: Dcrocker at RAND-UNIX, MOON at MIT-MC
cc: Rick.Gumpertz at CMU-10A, HEADER-PEOPLE at MIT-MC
In-Reply-To: Your message of 2-Feb-80 0637-PST

Dave -

I would like to point out that MM handles MIT-style structured
addresses, so at least TOPS-20 users who need to reply to such
messages can always use MM.  The code in MM that handles this
case as opposed to a comment is quite simple - three PDP-10
machine instructions!

I seem to remember that the MIT people repeatedly attempted to
get this format included in the standard.  I distinctly remember
HEADER-PEOPLE messages on the topic, but I don't remember the
motivation for it not being included.  Why WASN'T it included in
the standard?  I don't remember ever seeing a reason for it not
being included, except perhaps that the authors of the standard
thought "they are ugly".  (Speaking of ugliness, Dave, could you
have the maintainer of the mailsystem you use remove that silly
mixed-case host name output feature from your message headers?  I
think "Cmu-10a" and "Mit-Mc" and "Su-Score" are ugly!)

I consider this kind of structured addresses to be a useful
facility, providing a definite funtionality.  In fact, I wish to
implement this facility for other purposes on my system.  You
really don't want to have it quoted, because you want to be able
to specify an address to be interpreted without any parsing.
Consider the case of an address that by golly actually has
parenthesis in it!  What do you do once quotes have been usurped
for structured addresses?  Double quote it (duh...)?  The last
thing you want to do is apply structured address parsing to it!

By the way, don't I remember something about using curly braces
for structured addresses?  What happened to that idea?  Did it go
away because some terminals can't input those characters?

-- Mark --
-------

Date: 2 Feb 80 16:05-EST (Sat)
From: Dcrocker at UDel-EE
Reply-to: Dcrocker at Rand-Unix
Subject: Re: headers (into the fray!)
To: Mark Crispin <Admin.MRC at Su-Score>
cc: Header-People at Mit-Mc
Message-ID: <8032.57925.6671 @ UDel-EE>
In-Reply-To: Your message of 2 Feb 1980 1126-PST

    It is unfortunate that the memory seems to be worst for the people
who were most vociferous during the original discussion.

    1.  I don't care how easy it is to take care of a particular
special case (in this case, MIT's address structuring).  The issue is
to avoid forcing the rest of us from dealing with them.  That is the
purpose of a standard.

    1.a.  Why not include their special case into the standard, so
that it is no longer a special case?  Well, where do you stop?  One
issue is whether they are prevented from encoding their special case
(albeit with a degree of awkwardness they would quite reasonably
rather avoid) and the answer, for this case, is no.  That was
explained when the standard was being specified.

    2.  The reason we didn't include their convention in the
specification had nothing to do with our thinking it ugly.  My
comment, earlier today, was that I recalled MIT as thinking it ugly to
use the quotation marks -- and I agree with their aesthetic opinion,
but not their recommended solution.  Their would be absolutely no
semantic power added to the standard.  As I recall, there was a
possibility that the extended-typing feature (":" type ":" rest-of-
address) would be helpful, by that wasn't pursued.

    2.a.  Simple aesthetics are not the primary reason for the mixed-
case hostnames we use.  All upper case is more difficult to read than
all- lower or reasonably-mixed.  All-lower is not used strictly for
aesthetic reasons.  We do not use "correctly" mixed because we use one
of the more complete unofficial Arpanet host name tables, maintained
by Geoff Goodfellow, and he refuses to keep it in proper mixed case.
Hence, we have to perform some heuristics.

    2.b.  The question of case-mixing being ugly does not prevent you
from correctly processing mail (addresses) from us.  The failure of
MIT to put quotations around their mailbox fields DOES.

    3.  I think structured address are useful, too.

    3.1    "... You really don't want to have it quoted, because you
           want to be able to specify an address to be interpreted
           without any parsing.  Consider the case of an address that
           by golly actually has parenthesis in it!  What do you do
           once quotes have been usurped for structured addresses?
           Double quote it (duh...)?  The last thing you want to do is
           apply structured address parsing to it!"

    I had some difficulty with the english in this paragraph and to
the extent that I got past that, I'm not sure I understand what you
are saying.  My first suspicion is that you don't understand parsing,
in this sort of situation; this was an impression I had about a number
of people during the original discussion.  In fact, at the outset of
the specification effort, I didn't either.  If you DO understand
parsing, then you either haven't read the specification properly or
are entirely out to lunch.  All of this is being offered without
intending to transmit a put-down, but of course, that IS the way it
reads.  The problem is that I don't know how else to formulate a
response.

    3.b.  As I said a couple of years ago, some of you simply have not
made a reasonable effort to understand the specification.  Unless and
until you do, these sorts of discussions can't possibly be productive.
(That puts this note into the realm of frustration release.)

Happy weekend.

Dave.

JNC@MIT-AI 02/02/80 17:34:02 Re: Cm'on, you guys...
To: header-people at MIT-MC
	Please stop filling my mailbox. I seem to recall having
heard all this before.
			Noel


Date: 2 Feb 1980 1452-PST
Sender: GEOFF at SRI-KA
Subject: Re: headers (into the fray!)
From: the tty of Geoffrey S. Goodfellow
To: Dcrocker at UDEL-EE
Cc: Admin.MRC at SU-SCORE, Header-People at MIT-MC
Message-ID: <[SRI-KA] 2-Feb-80 14:52:10.GEOFF>
In-Reply-To: <8032.57925.6671 @ UDel-EE>
Fcc: <GEOFF>SAVED.MESSAGES;1
Reply-to: Geoff @ SRI-KA

As I believe I have told you on at least two distinct occasions
(NTC '77 in LA, and the recent 6th Data Comm.  Conf.  in
Monterey), years ago I tried to put mixed case into my hostable
for select hosts (such as the TYMSHARE-TIP becoming the
Tymshare-TIP, etc.), but found out that TENEX and TOPS20 monitors
and programs ceased to function, because they were not written
with this option in mind, so of course, i have rightly (and will
continue) refuse to put mixed case in my table (until someone
goes around the fixes all software concerned, everywhere --
hence: it isn't likely to happen).

While the subject is in the fray, I'd like to add to MRC's
support that i think your random mix-caseification(?)  is
unsightly and ugly.  I think that mixed case host name issue is
so frivolous anyway, that if my name wasn't explicitly mentioned
wrt to the hostable you use, i wouldn't have bothered with
replying.

Having cleared my name,

Geoff
 

Date: 2 FEB 1980 1834-EST
From: RMS at MIT-AI (Richard M. Stallman)
Subject: How to have constructive discussion
To: HEADER-PEOPLE at MIT-AI, dcrocker at RAND-UNIX

Whenever we say that "(BUG @)" ought to suppress the meaning of a
parentheses, you say that we haven't understood the standard.  It is
unthinkable that there can be any other basis for deciding what
something should mean, so we must be basing our statements on an
appeal to the standard, which implies that we are confused, careless
or stupid.  The fact is, those opinions are based on other things.
Even if you don't agree with us in this (I assume you don't) you must
start by recognizing the fact that there are other considerations
which we regard as as important as what the standard says, or more
important.

For example, when I say that "(BUG @)" ought to suppress the meaning
of the parentheses, my conclusion is based not on anything the header
standard has to say, but on the general concept of string quoting and
what it means in every other system that has it, including Lisp, PL1,
SNOBOL, and many other situations in our mail system.  To me that is a
more powerful authority than the header standard, and if the standard
disagrees, the standard is simply wrong, as if it had said that 3+3=7.
Even if you don't agree, if you want to try to change my mind you must
appeal to the authorities that I respect rather than to the ones you
respect.

So you will have to stop regarding it as unthinkable to question the
standard, or you will not ever LET yourself understand us fully.  And
you must stop insisting on making your opinion (that the standard is
the ultimate criterion of right and wrong) part of the grounds for the
discussion or we can't have a discussion.  You might also stop talking
about our "failure" to adhere to the standard.  In the same tone a
Russian might bemoan my failure to support their bid to rule the
world.  It's not that we failed; we're against it.

And stop talking about how everyone should be pointedly nasty to us,
because that is resorting to force.  Once again, it's taken for
granted that you are right and the only question is how to force us
into line.  However, a threat of force is not a rationally valid
argument that you are right, and it automatically terminates
constructive discussion.


Date: 3 FEB 1980 0440-EST
From: TVR at MIT-MC (Tovar)
Subject: This fray (and others)
To: HEADER-PEOPLE at MIT-MC

Comments like:

   "To be brief, no.  If you want to know the reasons, review the Header-People minutes."


   "P.S.  Given the long history on the topic, your refusal to make the
          change comes as no great surprise.  It's been clear to me for a
          few years now that the only way these things get "enforced"
          given the absence of more centralized authority (which is fine
          with me) is through classic free-market mechanisms.  The rest of
          us will have to pointedly refuse to compensate for your failure
          and not ever send mail to these improperly specified addresses.
          To the extent that that imposes a burden on you, you will feel
          pressure to change.  In the current context, of course, a
          mediating factor is the extent to which Arpa IPTO people remain
          unaffected."

largely tend to make discussions more emotional than intelligent.  How about
increasing the amount of information and decreasing the number of "us" and
"them" comments?

I don't have a real good memory about what actually came out of this fray
the last time it came up.  What i do remember was that there wasn't much of
a concensus on this issues.  Agreement is what makes standards really work.
And that's agreement by alot of the people.  And that probably means change
from time to time, as people and their needs change.  

NBS has a standard for connecting mainframes to peripherals, which i will
call an IBM channel.  That's was decided by a "majority".  But do you want
to have to put one on a PDP-10, as the U.S. Govt might want to insist (and
who pays for most of the stuff on this net)?

							--- Tovar

P.S.  I hope no one takes this personally.

Date: 3 February 1980  02:48-PST (Sunday)
From: Frank J. Wancho <WANCHO at SRI-KA>
To: Header-People@AI
Subject: A Digression on RFCs

People,

Let me digress/divert this discussion for a moment as I have missed
something somewhere along the way and maybe those of us who are
relatively new on the net have as well:

It says somewhere that RFC means Request For Comment(s).  Can anyone
submit an "RFC"?  Where/when in the process does an RFC become a
"standard"?  How is that designated?  When is an RFC just that, a
request for comments, with, perhaps, an eye toward working the
responses into a "standard"?  Was it ever that?  Are RFCs taken as
"standards" by their mere "publication", whether on the net and/or in
the protocol handbook, or are they merely "proposed standards" which
some may adopt and others can freely choose to ignore?

I think you have the general idea of what I am looking for in the way
of a reply.  Then with that out of the way, can someone tell us just
what the history and current status of RFC 733 really is, briefly?

--Frank


Date: 3 FEB 1980 0631-EST
From: TVR at MIT-MC (Tovar)
Subject: "(BUG @)"
To: HEADER-PEOPLE at MIT-MC

Now that i've refreshed my memory by looking at the document and the comments,
it is quite obvious that several people (not excluding myself) are confused.

At any rate, my interpetation of "(BUG @)" [quotes included] is essentially
an atom with funny characters in it.  I would treat it as a legal address
(according to 733).  If i were printing it for a human, it would appear as
(BUG @).  If i put it in a header where a mailbox was needed (To, From, CC,
reply-to, etc.), i would have to look at the thing to see if it needed quoting.
I could not be use it as it stands, as (BUG @)@MIT-MC would reduce to @MIT-MC
due to parentheses and i would be tempted to quote the thing solely on the
basis of the @ as some stupid programmer might trip over it.  In any case,
i can check the string against:

	specials    =  "(" / ")" / "<" / ">" / "@"  ; To use in a word,
		    /  "," / ";" / ":" / "\" / <">  ;  word must be a
			                            ;  quoted-string.

If i found any, i would quote the whole thing, remembering the transformation
within the string of  " -> \"  and  \ -> \\  .  (Can someone tell me if \
followed by CR really puts a CR in a string??!)  If my system used \ as a
letter, i might consider using <"..."@losing-site> to make things look
nicer in front at least.

Now, what i don't like about this scheme is the question of inter-networking.
I would hate to see "\"Mike O'Hare\"@Acme-Local"@Somenet-Gateway because net A
hates ' and net B doesn't know what to do with multiple @'s.  Or how about
just "\"foo\\\\bar\"" because non-standard machine on net B likes a \ in names.
I know we've discussed this before, probably in the structured name fight.  I
don't recall any distinct conclusion on how to handle these sorts of problems.

Also, aren't sites like UDEL-EE somewhat of a band-aid?

								--- Tovar

P.S.  If you're going to use heuristics to go from upper to mixed cases,
please improve them.  You will probably need a (large) list of exceptions
to your rules.  I think such techniques may work fairly well with English
names, but a large number of site names are acronyms and such sites may be
sensitive to typography.

Date:  3 February 1980 1107-EST
From: David Lamb
Subject: Header fray (pragmatics)
Sender: RdMail at CMU-10A
To:   Header-People at MIT-MC
Reply-To: RdMail at CMU-10A
Message-ID: <03Feb80 110730 RD00@CMU-10A>

1) Now that the DataComputer has gone/is going away, isn't it a
   little pointless to refer to the HeaderPeople minutes?  Or are
   they being archived somewhere else?

2) There are a number of theological positions one can take regarding
   a standard (or suggestion for a standard).  I suggest that neither
   the "you must use it because it's the standard" and the "it
   doesn't do what I want so I'll ignore it" approach is particularly
   useful. I realise I am being unfair to both sides, but I tire of
   this particular debate.

3) My own point of view is that ease of communication is the key
   factor.  If it is a pain in the ass for me to try to send mail to
   (BUG @)@MIT-AI, then I probably won't send mail there.  If I have
   to send mail there, I'll get real upset and start complaining.
   Since there is no particularly good reason why anyone at MIT
   should pay any attention to me, they will ignore my complaints.
   So (BUG @) and I will stop communicating with each other.  I don't
   think this will cause the world to end.

4) I hope it is obvious that the above was a paradigm rather than a
   specific instance.  Few people outside MIT really have to care
   about MIT's structured addresses.  Lets reserve our energies for
   problems that really do affect most of us.

Date:  3 Feb 1980 (Sunday) 1135-EDT
From: DREIFU at WHARTON (Henry Dreifus)
Subject: Jumping in...
To:   header-people at MIT-MC

J
U
M
P... Now that was easy. The problems in designing any standard is
	quite tough. Moreover getting some slob to program it in once
	agreed to, it even harder.

	True the TBM is going away, and I will forsee that people will
	have to get a mag tape out FAST or we will see all the disks
	on the ARPAnet filled to capacity with mail messages. 

	For standards, what is wrong "SPECIFICALLY" with that recent
	RFC (783?) or whatever it is, someone refresh my bubble memory.

	More importantly other issues, like large scale mailings have
	to be delt with. Is anyone out there in CRTSTY land willing to
	bring up the point of a Mail COMPUTER? CCA already has something
	similar --> COMET. Has anyone talked to the CCA people, who
	do have heads on their shoulders, and EVEN good ideas...

	Jumping out ... for now


Date: 3 FEB 1980 1319-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Locations of minutes
To: HEADER-PEOPLE at MIT-MC

Header-People messages are filed on a series of files with first
name HEADER and second name MINS, MINS01, MINS02, etc. on the
directory KSC; on the MIT-MC machine.  The ones more than three
years old have been reaped, but could easily be retrieved if anyone
wanted to see them.  As far as I know the Header-People messages
were never archived on the Datacomputer.

Date:  4 February 1980 1525-EST (Monday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: ITS parenthesized headers (BUG @)
To:   Richard M. Stallman <RMS at MIT-AI>
CC:   Header-People at MIT-MC
Message-ID: <04Feb80 152518 RG02@CMU-10A>
In-Reply-To: Richard M. Stallman's message of 1 Feb 80 17:56-EST

It seems to me that there are some things that people just aren't
seeing.  The first is that the interpretation of names by an addressed
host need not match that by other, non-addressed hosts.  RFC733 covers,
in general, how names should be interpreted by the non-addressed hosts
(i.e. ones whose name does not follow the "@" or "at").  Each site may
choose how to interpret addresses specific to that host.

For convenience, the 733 syntax was chosen so that the concepts
employed by MOST hosts could be represented in a straightforward (and
pretty?)  manner.  In many cases internal address formation rules can
be mapped directly into network-wide address formation rules.  For
instance, typical names are easily represented.  Punctuation of 733
addresses was chosen to avoid conflict with many of the already used
internal rules.  However, ITS parenthesized type addresses were NOT
provided for.  I will not comment here on the wisdom of that decision.
For parenthesised ITS names, the catch-all called quoting MUST be used
(or the parens mapped to braces or something).  It may be a nuisance to
the ITS people; it may be ugly; nevertheless that is how it is.

Of course it is a pain for some sites to map internal representations
into external representations.  Those that have it easy can say that
anything in quotes will be treated as a literal; those that have it
harder must do something else.  Since ITS must use quotes to get
parenthesized lists through without being treated as comments, they
cannot blindly assume that quotes mean to use the entire string as an
uninterpreted literal.  If they need such functionality (I am not sure
why a mailbox would NEED to contain quoted parens), then they must
invent ANOTHER syntax which can be imbedded inside the quotes.  Given
their LISP-like syntax, the use of ' would seem obvious, but far be it
from me to dictate what they should use.  Surely some ITS hacker can
come up with some reasonable syntax that is works with RFC 733.

Another thing to keep in mind is that the general rule that has been in
effect for some time is that changes which ease communication should be
made at the site which will require the least changing of multiple
programs.  Under this rule, CMU went to generating names with "."s in
them instead of spaces -- they are treated identically internally but
make things easier for those sites which aren't prepared for spaces in
names.

In a similar vein, I request that ITS do something to bring their names
into conformance with 733.  The most obvious thing is to put quotes
around their structured names WHEN SENT TO OTHER ARPANET HOSTS.  They
can of course be stripped off for internal use if they really think
that worthwhile.  They can turn their characters upside-down or even
map into the character set used by John Elliott to publish the first
book published in the new world -- the bible translated into the
Massasoit Indian language.  (That would surely follow the tradition of
rebelliousness that seems dominant in the Boston area.)  I don't care
what they do internally, but please give me something reasonable to
reply to externally.

		Rick

Date:  4 February 1980 1535-EST (Monday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: headers (into the fray!)
To:   Dcrocker at Rand-Unix
CC:   Header-People at Mit-Mc
Message-ID: <04Feb80 153500 RG02@CMU-10A>
In-Reply-To: <8032.57925.6671 @ UDel-EE>

Maybe the solution, though ugly, is "(" BUG "@" ")" @ MIT-MC?

		Rick

KLH@MIT-AI 02/04/80 21:43:07 Re: !!STOP!! for a minute.
To: header-people at MIT-MC
Wait.  People are assuming that MIT wants recipients of the
form (BUG FOO) to be legal.  We do not; we have known since the beginning
of time that parentheses were targeted by the RFC-generators for
"comments".  We accepted this in the belief that a viable alternative
would be provided, and in fact suggested more than one such
alternative that would be acceptable to us.  None was incorporated.

Please get off the non-issue of how to pass parentheses around.

A discussion of WHY the MIT sites continue to use parens should
wait until one of us can dig up the original messages and proposals
for re-transmittal; then we can proceed from there.  This is easier
than reaching the same point via re-hashings and thrashings.
Perhaps when this is done we will find that perspectives have changed.

--Ken


Date:  5 February 1980 1525-EST (Tuesday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: !!STOP!! for a minute.
To:   KLH @ MIT-AI
CC:   Header-People @ MIT-MC
Message-ID: <05Feb80 152510 RG02@CMU-10A>
In-Reply-To: KLH's message of 4 Feb 80 21:43-EST

Let me back off a bit.  I originally requested the quotes around "(BUG @)" so
that I could easily ANSWER/CC to that address.  If I manually type the quoted
string all works well (remember that the FTP that supports mail delivery never
sees the quotes).  It seemed (and still seems) like a trivial change for MIT to
put the parenthesized addresses in quotes so that I would not have to manually
retype such addresses but could use nice facilities for automatic copying of
addresses.  Besides, it would allow me to see the address when RDMAIL prints it
(currently it parses it into "<null> at MIT-AI" or whatever and so prints that
it is from <null>, unless I explicitly ask for the WHOLE header).

Rather than get into a long discussion of what is right or wrong, why can't the
ITS people just implement the expedient, kludge or not, of adding the quotes?
Alternatively, translate parens to braces as they go out over the net (in
structured addresses anyway).  This would be no worse than CMU translating
spaces to dots.  Of course either can go away if something better (like
official structured address syntax) comes along.  For the moment, however, a
legal address like "(BUG @)" at MIT-AI seems far superior to an illegal one
like <null> at MIT-AI with a comment thrown in.

		Rick

Date: 6 FEB 1980 1353-EST
From: MOON at MIT-MC (David A. Moon)
Subject: More flaming about structured recipients
To: Rick.Gumpertz at CMU-10A
CC: HEADER-PEOPLE at MIT-MC

Here is why MIT does not put quotes around structured recipients.

That would make it parse wrong in our own mail reading programs,
where quotes have their normal meaning of causing special characters
inside them not be special.  Obviously it is more important for
structured recipients to parse correctly locally than to parse correctly
at foreign sites, since very few of them ever get to foreign sites.

In fact, the only person I have ever heard complain about this problem
is you, because you are a maintainer of the "@" program.  The few other
structured recipients at "foreign" sites (e.g. MIT-XX) have evidently
just fixed their mail readers to parse that syntax in an ad hoc way.

Well, why don't we write it one way when sending to a local host and
another way when sending to a foreign host?  That sounds superficially
like a good idea, but unfortunately it cannot work, because headers are
not reformatted when mail is forwarded from one host to another, so there
is no way to know at the time when a header is generated what hosts
and programs are going to see it in the future.

Well, why don't we use some other characters instead of parentheses,
like curly brackets?  In fact, that is what we want to do.  When RFC733
was being written we asked many times for such a feature to be put
into the standard, but the authors of RFC733 were never interested
in putting it in nor in understanding what it was for.  So, in the
absence of any standard we stick to what we have always done, which
at least works adequately.

Date:  6 February 1980 1738-EST (Wednesday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: More flaming about structured recipients
To:   MOON at MIT-MC (David A. Moon)
CC:   HEADER-PEOPLE at MIT-MC
Message-ID: <06Feb80 173855 RG02@CMU-10A>
In-Reply-To: David A. Moon's message of 6 Feb 80 13:53-EST

733 does allow braces in addresses without restriction, as best I recall.
Why not just go ahead and use them, even if noone else knows their "structured"
meaning??

		Rick

Date: 6 Feb 1980 8:13 pm (Wednesday)
From: AHenderson at PARC-MAXC
Subject: Structured objects in messages.
To: MOON at MIT-MC (David A. Moon)
cc: HEADER-PEOPLE at MIT-MC

David:

As an author of RFC733, let me comment that the speculation in your recent
message about us is false. We actually considered the support of structured
objects fairly hard. In the end, for various reasons which were good at the time,
we decided not to support them.

I am now of the opinion that we made a mistake in deciding not to put in some
explicit recognition of the need for structured portions of messages. I feel this for
two reasons:
	1. (pragmatic reason; 20/20 hindsight) We would not have had the
	   recurring discussions which we now have on the subject. One of our
	   goals in designing the RFC was to get something everybody could
	   agree upon so that we could get on with life; these discussions
	   indicate that the time may now have come for us to make this
	   addition to allow us to do just that.
	2. (technical reason) I think it is important that any standard in a
	   research environment should have some means of escape; a way of
	   extending the standard into territory which is not under discussion
	   at the time of creation of the standard (the time of the
	   decision-making). I see the structured objects which have been the
	   subject of the recurrent discussion as serving that end.

I discussed this with Richard Stallman long ago, but we were thinking then only
of addresses. Now, I would advocate adding a more general escape mechanism.

How about:

	1. add (p7/8) a 5-th type of lexical symbol:
		{anything} - structured object
	   add (p9) appropriate info to the formal definitions of the
	   lexical structure:
		specials (include "{" / "}")
		structured-object (analogous to comment).
	2. add (p16) to the production for <word>:
		word = atom/ quoted-string/ structured-object

One you have an escape mechanism, I think an important next step is to reach
agreement about the shape that the "anything" can take. My feeling in this
regard is that all we need, and all we ought to establish at this level is a
convention by which a composer of a structured-object can communicate to his
audience an indication of the "language" being used within that
structured-object. Then we provide for different subcultures co-existing without
trouble.

How about:
	1. The first <word> within the brackets indicates the language.
		{<language-indicator> <expression-in-the-language>}
	   (A language is composed of a collection of objects and a format
	   for representing those objects: a semantics and a syntax.)
	2. Establish a registry for language-indicators
	   (with the NIC, Jon Postel, ?).

Thus, for example, register the "language" of the addresses which MIT uses to
such advantage as, say, MIT-Address. Then they would use the form
	{MIT-Address <S-expression>}
in their messages.

Note that this permits even the language-indicator to be a structured-object; thus
we can escape even a level deeper. (Always leave yourself a way out.)

Some of us could even register and explore the use of "self-describing languages"
(ultimately a contradiction in terms, but you know what I mean; eg. PCPB8, or
the new internet mail format).

What think you?

Austin

PS: I have not consulted the other authors of RFC733. They may be able to
remind me if there are good reasons (pragmatic and technical) for not changing
the standard.




Date:  7 February 1980 1105-EST (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: Structured objects in messages.
To:   AHenderson at PARC-MAXC
CC:   HEADER-PEOPLE at MIT-MC
Message-ID: <07Feb80 110507 RG02@CMU-10A>
In-Reply-To: AHenderson's message of 6 Feb 80 20:13-EST

Austin -

Your proposal sounds good to me, but I would suggest using another
language identifier like ITS-Structured-Address or such so as not to
indicate that other MIT sites like Multics go along with such.

Another point:  Should there be any provision for comments within
structured addresses?  If so, would parens be totally reserved for
comments?  Reserved in certain contexts?  The S-expression could always
be worded in terms of nested braces or such.  If parens are absolutely
needed, they could be quoted with \ I guess.  Maybe something else is
appropriate, but comments would sometimes seem useful.

		Rick

Date: 7 Feb 1980 10:41 am (Thursday)
From: AHenderson at PARC-MAXC
Subject: Re: Structured objects in messages.
To: Richard H.Gumpertz <Rick.Gumpertz at CMU-10A>
cc: HEADER-PEOPLE at MIT-MC

Rick:

Sure, pick any language-indicator you (read: the registrar) like.

I think it wise not to have to do lexical analysis within {}. For one reason we
then have recursive calls to the lexical analyzer. But secondly, and this seems
more important, we are free of concerns over quoting, a much-to-be-sought-after
situation if current discussion is indicative of people's real feelings on this
matter.

Austin


Date:  7 February 1980 2100-EST (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: ITS-STructured-Address
To:   RMS at MIT-AI (Richard M. Stallman)
CC:   Header-People @ MIT-MC, AHenderson at PARC-MAXC
Message-ID: <07Feb80 210011 RG02@CMU-10A>
In-Reply-To: Richard M. Stallman's message of 7 Feb 80 17:45-EST

RMS -

I agree, BUG and FILE and @FILE would make for nice registered names
(maybe with the perturbations made below).  Perhaps the syntax should
be changed, however, so that the language identifier need not be a
single word.  In particular, how about:
	{<language-identifier> : <brace-balanced-phrase>}
Note that the colon allows multi-word language identifers. I am not
sure colon is the best character choice, but it seems reasonable.

Examples of names that might possibly be useful are:
	{RFC-733 Address: Rick Gumpertz @ CMU-10a} @ MIT-AI
	{Site-specific address: Farber @ UDel-EE via Dialup Kludge} @ Rand-Unix
	{Site-specific address: Farber @ UDel-EE via OxCart} @ Rand-Unix
	{Site-specific address: Redell @ SDD} @ PARC-MAXC
	{Person (interpreted by some human): Harry Bovik} @ CMU-10A
	{Job Title: ARPANET Liason} @ MIT-Multics
	{Traditional Address: Richard H. Gumpertz, 47 Orchard Ave., West Newton, MA  02165} @ WU-Mailgram
	{Traditional Address: Margaret Thatcher, 10 Downing Street, London, England} @ USPS-Gateway
	{Log File: >udd>Multics>Hacker>foo} @ MIT-Multics
	{Distribution list File: SNAME; FNAM1 FNAM2} @ MIT-AI
	{Bug report: @} @ MIT-AI
	{Address Maintainer: Header-People} @ MIT-MC
	{Address Maintainer: {Bug Report: @}} @ MIT-MC
	{{MIT-ITS Extension: <extension-name>}: <extension-garbage>}
A perverse example, which I am not absolutely sure I have right, might be:
	{RFC-733 Address: {Address Maintainer: {Bug Report: @}} @ MIT-AI} @ CMU-10A

Note that "RFC-733 address" is just an explicit form for the default
addressing and so may not be really necessary.  I would allow comments
to the left of the colon (the leftmost one anyway).  To the right of
the colon would be language dependent -- the only requirement would be
that it have balanced braces so someone who doesn't know the syntax can
just scan to the closing brace.  \{ and \} would be available for
languages which need unbalanced braces -- they would not be counted
when scanning for the closing brace.  For the names mentioned above,
comments would probably be allowed in the right sides of only "RFC-733
Address" and "Address Maintainer".

I am still not sure, by the way, whether the site should be required
after the closing brace of a structured address.  I think it should so
that there is always indicated SOMEONE who can interpret the address
and act appropriately.  Of course the site named after {RFC-733
Address: ...} might not seem too useful.  It is needed, however,
because many hosts will not understand structured addresses at all
(other than how to skip to the closing brace).  In particular, the host
after a structured address should be one that not only can understand
structured addresses but also can understand the particular language
indicated.  All others could just pass off the address to that host for
interpretation.  Of course duplicate elimination would be difficult for
the sender unless he understands the particular languages used, but
that is just too bad.

To keep HERMES and the other losers happy, I suggest that all
registered language names not contain spaces for now -- use dashes as
for field names.  Also, any unnecessary white-space should be squeezed
out.  For example:
	{Bug-Report:MIDAS} at MIT-AI
should get by most mailers without any code modification.

Date:  8 February 1980 1854-EST (Friday)
From: Brian.Reid at CMU-10A
Subject: header standards
To:   Header-People at MIT-MC
Message-ID: <08Feb80 185454 BR10@CMU-10A>

I haven't waded through all of my mail yet after being gone for several
weeks, and may therefore find that somebody else has already said this.

The reason we stalled out a year or two ago on header standards was that
different people are applying different requirements.  Group X wants the
headers to be optimally human-readable.  Group Y wants headers to be
totally machine-readable, and will have a program do the translation
from machine-readable form into human-readable form.  Group Z, which is
probably the majority of the fray members, doesn't much see or care 
about the distinction, and wants headers to be both human-readable and
able to carry large amounts of sophisticated information.

My position has always been that the problem can't be solved until we
agree on what headers are for.  At CMU a program stands between my
mail headers and my screen, and can display any header any way I want.
I submit that any attempt to encode more information in these mutant
headers that are trying to be both human-readable and machine-readable
is bogus, and that we ought to try to solve the @i[real] problem, which
is machine-readable headers.

Brian

Date:  8 Feb 1980 1658-PST
From: Larry Campbell <LCampbell at SRI-KL>
Subject: Re: header standards
To: Brian.Reid at CMU-10A, Header-People at MIT-MC
In-reply-to: Your message of 8-Feb-80 1554-PST

Foo, Brian.  Headers that are human-readable are also machine-readable,
although you might have to do a bit more programming to get it right.
After all, if you want headers to be machine-readable, why not just
use some highly compressed binary crud and be done with it?  It'd
make net mail much more efficient.

Human-readable headers win for two reasons.  First, they make it easier
on people with limited computing and/or programming resources (for
example, home computers).  Dumb computers or programs can just type out
the header literally and let the human figure it out.  If that means
that programs which wish to do fancy things with the header must be a
little bit smarter, that's just too bad;  after all, that's what computers
are for!  The second reason is that it makes debugging easier;  it also
provides an escape mechanism when the fancy mail reader has bugs:  the
human can parse the header and get around the bug manually.

At this late date, it is surprising to hear people still arguing in
favor of encoding data (which has meaning to humans) in an obscure
form to make it easier for the computer to read. If we're going to
do that, why not finish the job and abolish compilers and assemblers?
It'd be much easier on the poor computers if we programmed in binary!

Let's put the burden on the computers, where it belongs.
-------

Date: 8 Feb 1980 1844-PST
Sender: POSTEL at USC-ISIE
Subject: RFCs & Standards
From: POSTEL at USC-ISIE
To: Header-People@MIT-MC
Message-ID: <[USC-ISIE] 8-Feb-80 18:44:15-PST.POSTEL>



Frank Wancho:

Anyone can write an RFC.  To publish an RFC send it online to the RFC 
number czar (me).  The RFC number czar will stick in the number and 
place it in the NIC online library, and send out an announcement of its 
existence.

Most RFCs are in fact requests for comments.  Some are not.  Almost all 
the protocol standard documents appeared as RFCs in early versions for 
comments and as final versions for information.

The standards setting process in the ARPA community is not formalized.  
There is no procedure handed down from above, or agreed to by the 
network users.  However, given the history of the development of 
standards in the ARPANET, the development of the current mail standard 
(RFC 733) was is the result of a very formal and widely advertized 
standard making effort.

In practice, the standards are what ever it is that gets published in 
the ARPANET Protocol Handbook.  I am the technical editor of that 
document (Jake Feinler is the production editor, and does all the hard 
work).  The editors serve at the pleasure of DCA and ARPA.

--jon.



Date:  8 February 1980 2227-EST (Friday)
From: Brian.Reid at CMU-10A
Subject: Re: header standards
To:   Header-People at MIT-MC
Message-ID: <08Feb80 222725 BR10@CMU-10A>
In-Reply-To: Larry Campbell's message of 8 Feb 80 19:58-EST

My point was pricisely that: let the computers do the work.  You are
sending a message that goes through 3 to 5 layers of encoding in various
formats that are intelligible only to computers without elaborate
diagnostic programs (IMP packets, NCP buffers, file buffers, etc.) and
you are worried because the last level isn't optimally readable by
people.  Foo; I can read any header that anybody can write; that's not
the problem.  The problem is specifying the format of header fields
rigorously enough for dumb mail programs to be able to understand them.
I already have access to the smartest mail program around, and it can
understand all of this junk, so I don't care.  But for those people who
would like to "let the computer do the work" and who don't have a
natural language parser built into their mail reader, the compromise
should be in the direction of machine-readable formats and not
human-readable ones.

My argument is that the header of a message is a higher-level analog of
the packet control information in a network packet, and we seem all to
have agreed that the hugely complicated software necessary to turn those
packet bitsies into the flames that you see before you have not gone to
waste.  So why not take the same sound logic up a level, recognizing
that the "message" is a data object of importance as great as the
"packet", and equally rigorous format standards should be applied.

Brian

Date: 14 February 1980 2304-EST
From: David Lamb
Subject: automatic CC's
Sender: RdMail at CMU-10A
To:   header-people at mit-mc
Reply-To: RdMail at CMU-10A
Message-ID: <14Feb80 230406 RD00@CMU-10A>

Yesterday I sent a note to MsgGroup announcing the RdMail manual and
asking for people who wanted one to send me their U.S. mail
addresses.  I strongly suspected that someone would answer my note
with a Hermes template that would generate a CC to the TO list of my
note, which would have wound up sending a lot of junk mail to the
whole mailing list.  What I did was to generate the message and
mailer queue entry by hand, eliminating the TO field from the
message.  One of the recipients noticed what I had done, and pointed
out that I had thereby prevented him from knowing which of several
mailing lists I had used in doing so.

Does anyone have a better idea of what I could have done?  The only
alternative I could think of was to invent a new header field like
Dont-Answer-To: that would have held the stuff I didn't want to put
into a legitemate field.

Date: 14 February 1980 2334-EST (Thursday)
From: Brian.Reid at CMU-10A
Subject: Re: automatic CC's
To:   header-people at mit-mc
Message-ID: <14Feb80 233457 BR10@CMU-10A>
In-Reply-To: <14Feb80 230406 RD00@CMU-10A>

The things we do to circumvent Hermes!!!!!

Date: 14 Feb 1980 2252-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: Postscript to "A digression on RFCs"
To:   header-people at MIT-AI
cc:   feinler

I think Jon essentially outlined what an RFC is and how one
is submitted.  One thing that was perhaps not clear was
the fact that most of the major Arpanet protocols were the
result of a protocol committee or working group appointed
by ARPA.  These working groups generally came up with a draft
document and submitted it as an RFC, then did rewrites incorporating
feedback where pertinent, and finally  submitted a final
version which for all intents and purposes became the standard.
Jon has coordinated this dialog for some time and is continuing
to do so for the internet protocol dialog as well.

RFC 733 was the result of such a committee which, as I understood
it, had ARPA's sanction.  (The members can verify this.)  If I
remember rightly it was the CAHCOM committee (although for the
life of me I can't come close to what that acronym stands for!)

Internet, Autodin II, NSW and DoD protocols (particularly the latter
three of these) are the outcome of a more formal effort than that
leading to the Arpanet protocols...at least in later years.
I think we are heading more towards an environment where the
hosts on a given network will be required to adhere rather closely
to the official protocols for that network.  [Perhaps Jon
has more to add to this.]

As I have watched the protocol dialog go back an forth, I have
been very impressed by the usefulness and importance
of letting interested parties beat on any proposed protocol
to get as many points of view represented and as many serious
discrepancies ironed out before it becomes an accepted protocol.
Members of the Arpanet who have participated in this dialog have
contributed very useful input.  The net is a most unique environment
for such collaboration.

Jake
-------


Date: 15 FEB 1980 0316-PST
From: NMAX at USC-ECL
Subject: Re: automatic CC's
To:   RdMail at CMU-10A, header-people at MIT-MC
cc:   NMAX

In response to the message sent 14 February 1980 2304-EST from RdMail
at CMU-10A

The answer is to create "lists" that look lke mailbox names, but are
not.

This can, if you use the right names, convey who got them.

for example:  MSGGROUP:  MSGGROUP@MIT-ML

  which should tell us who you sent it to, and get it to the right
relay station, and not give us a way to inadvetently anwer to the
whole list.

And, I should note that it is not just HERMES that causes the problem
in TENEX-land.  MSG is just as prone.  Seems to me that any mail
handler with a reply or answer command that uses addresses pulled from
recieved messages will let users make that mistake.  As long as
msggroup@mit-ml looks like any other individuals address, then how
should any reply function guard against replying to it?

the problem in this case requires the same solution used by USPS junk
mailers.  They don't give you access to their mailing list either,
though they may code it so they know which one was used.

Enuf of this for now - do we really need more than the blind list
mechanism we have?

Stef (yes, this is me in NMAX - I set this mailbox up just to catch
header people and other junk mail for me, and keep it out of the way
of business!)
-------

Date:  15 February 1980 11:11 est
From:  Pogran.CompNet at MIT-Multics
Subject:  Re: Postscript to "A digression on RFCs"
To:  Feinler at SRI-KL (Jake Feinler)
cc:  header-people at MIT-AI, feinler at SRI-KL
In-Reply-To:  Msg of 02/15/80 01:52 from Jake Feinler

Just for the record, CAHCOM = "Committee on Computer-Aided Human
Communication", a relatively short-lived effort on Steve Walker's part,
when he was an ARPA program manager, to provide some direction and advice
regarding ARPA's efforts in the area.

Ken


Date: 15 Feb 1980 10:33 am (Friday)
From: AHenderson at PARC-MAXC
Subject: Re: Postscript to "A digression on RFCs"
To: Feinler at SRI-KL (Jake Feinler)
cc: header-people at MIT-AI

Addition to Ken's note:

CAHCOM Chairman - Dave Farber.
Mail format subcommittee membership: authors of RFC733; no chairman.

Austin


Date: 15 Feb 1980 12:37 pm (Friday)
From: AHenderson at PARC-MAXC
Subject: Re: structured addresses
To: Richard H.Gumpertz <Rick.Gumpertz at CMU-10A>
cc: Header-people at MIT-AI

I have been away skiing, and so in an attempt to catch up have not followed the
recent exchange of messages very closely. However . . .

My chief concerns are:

1. that an escape mechanism be available;

2. that this mechanism support different languages (extensions);

3. that any syntax and characters be permitted within these languages with a
minimum of quoting problems;

4. that the language in any particular structured-object be discernable;

5. that if the language is not understood by some program, that program be able
to easily ignore that whole structured-object.

In light of this, I think:

1. that "reading to } with some quoting convention  (doubling?) for inserting }"
is a good way of satisfying 5. To the extent that structured objectsdo not contain
}, no quoting will be necessary.

2. that an MIT structured address, say "(FOO BUG)", would most cleanly (that is,
in keeping with the concerns just expressed) best be encoded as
"{MIT-ITS-ADDRESS-LANGUAGE-IDENTIFIER (FOO BUG)}", where the
identifier is whatever (presumable short) word you register. To the extent that
the MIT structured addresses do not contain }, no quoting will be necessary.

3. that you shouldn't register the specific forms you now have as their own
languages; that doesn't feel like it is in the spirit of what I had intended by a
"language". 

Austin





Date: 15 FEB 1980 1750-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Re: structured addresses
To: HEADER-PEOPLE at MIT-MC

Just a brief note.  I think saying {MIT-STRUCTURED-RECIPIENT (BUG PROGRAM)}
is 100% entirely not in the spirit of what we are trying to do.  The correct
thing is to add "bug reports" as a standard facility which any host may
support (I presume we are not the only hosts that sometimes have bugs in
their programs), and write the syntax as {BUG FOO}.

I don't think it makes sense to say there are different "languages".
A more appropriate model would be FTP commands, where everything is
in the common "language" that it starts with a keyword and ends with
a carriage return.  A certain set of keywords are registered and
standardized; their documentation includes what comes on the line
after them, but you can always skip over any keyword by reading up
to the carriage return.  There is a mechanism for experimenting with
new, unregistered keywords, by spelling them starting with an X.

Similarly, in structured recipients there is a common language, namely
a structured recipient is enclosed in {}, contains balanced {} inside
itself, and starts with an identifying keyword.  Unregistered keywords
should start with X to avoid any conflict with registered keywords
(and should be renamed when they become registered).  If you want we
could have a way of quoting unbalanced {}, although I don't think it's
of much practical importance.  We should certainly register and
standardize any keywords that seem to be of general use, even if not
all sites plan to implement them any time soon.

Date: 16 Feb 1980 0108-EST
Sender: FURST at BBN-TENEXB
Subject: Automatic CC's
From: Furst at BBN-TENEXB (Sheldon R. Furst)
To: David.Lamb at CMU-10A
Cc: Header-People at MIT-MC
Message-ID: <[BBN-TENEXB]16-Feb-80 01:08:52.FURST>

The subject is probably dead, but for everyone's general
information, HERMES can be suppressed from automatically CC'ing
to the "To" field of the original message by setting the
"Reply-Copies" switch (sigh) to "NO".

Unfortunately, the default for this switch is "YES", and (out of
ignorance, I suspect) most users leave it this way.  I certainly
think a case can be made for defaulting it to "NO", but whether
someone will listen is another matter.

-- Sheldon

Date: 16 FEB 1980 0319-PST
From: NMAX at USC-ECL
Subject: Re: Automatic CC's
To:   FURST at BBN-TENEXB, David.Lamb at CMU-10A
cc:   Header-People at MIT-MC, NMAX

In response to the message sent 16 Feb 1980 0108-EST from
FURST@BBN-TENEXB

I will try to refrain from accepting your invitation to flame.

Setting the switch to "NO" is simple.

Living with it set to "NO" so I have to type in the addresses, or
over-ride the switch 90% of the time is painful and unwarranted.

So, I will repeat what seems so obvious.

If you don't want replies sent to a certain address, such as a
rebroadcast station, then you should not put it where people can get
at it and use it wrongly.

We have mechanisms such as blind lists which will do the reqquired
thing.

I move that we start to use them.

Stef
-------

Date: 16 February 1980 1001-EST (Saturday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: Automatic CC's
To:   NMAX at USC-ECL
CC:   Header-People at MIT-MC, NMAX at USC-ECL
Message-ID: <16Feb80 100126 RG02@CMU-10A>
In-Reply-To: NMAX' message of 16 Feb 80 06:19-EST

Stef -

There is a big difference betwen automatically generating CC's and
offering the user a short mechanism for generating the CC himself.  For
instance, on this very letter I had to type exactly one more character
than if I had decided not to send CCs to Header-People!  I'll bet
nobody from CMU has automaticallly CC'ed lists unintentionally.  Does
this mean they type a lot of addresses?  Absolutely not -- in fact I
suspect they probably type fewer than other sites.

		Rick

Date: 16 Feb 80 11:23-EST (Sat)
From: Dave.Farber <Farber@UDel-EE>
Reply-to: Dave.Farber at Rand-Unix
Subject: Re: Postscript to "A digression on RFCs"
To: Jake Feinler <Feinler at Sri-Kl>
cc: header-people at Mit-Ai, feinler at Sri-Kl
Message-ID: <8046.41005.1040 @ UDel-EE>
In-Reply-To: Your message of 14 Feb 1980 2252-PST

CAHCOM translated as Computer Aided Human COMmunications.
A word I still like. I was the Chairman of the Arpa 
Committee.

Dave


Date: 16 Feb 80 12:46-EST (Sat)
From: Dcrocker at UDel-EE
Reply-to: Dcrocker at Rand-Unix
Subject: Re: Automatic CC's
To: Sheldon R. Furst <Furst at Bbn-Tenexb>
cc: Header-People at Mit-Mc
Message-ID: <8046.45977.1703 @ UDel-EE>
In-Reply-To: Your message of 16 Feb
In-Reply-To: <[BBN-TENEXB]16-Feb-80 01:08:52.FURST>

Hermes certainly is not the fundamental "cause" of the problem.
It merely happens to be one of the systems with enough features
(and no, I'm not a great Hermes fan) to have options that
can be set wrong.

I think you observation as to Hermes' problem being incorrect
defaults is just right.

I recommend that the default be ASK, rather than NO.  This
tells naive users what is going on and doesn't require them
to first feret out the possiblities.

Dave.

Date: 16 February 1980 1333-EST (Saturday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: Automatic CC's
To:   Dcrocker at Rand-Unix
CC:   Header-People at Mit-Mc
Message-ID: <16Feb80 133335 RG02@CMU-10A>
In-Reply-To: <8046.45977.1703 @ UDel-EE>

If ASK is what I think it is, it sounds like it is similar to RDMAIL.  In that
case I agree that it should definitely be the default behavior on automatic CC'ing.

		Rick

Date: 16 Feb 1980 1357-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: automatic CC's
To: Header-People at MIT-MC

MM was changed to have its default in REPLY be SENDER instead of ALL.
This default can of course be changed in an init and overridden by
typing two extra characters (a space delimiter and an "a" before a
CR).  I was reluctant to do this because it seemed to me to be a major
incompatability, but I got a lot of bureaucratic pressure at Stanford
to change it (and since I personally agreed with the bureaucrats on
the issue I couldn't argue the merits of the old default).

Now I have people sending me messages saying that they preferred ALL
and that it was a silly change to make.

You can't please everybody.

-- Mark --
-------

Date: 16 Feb 1980 1506-PST
Sender: GEOFF at SRI-KA
Subject: Re: automatic CC's
From: the tty of Geoffrey S. Goodfellow
To: Admin.MRC at SU-SCORE
Cc: Header-People at MIT-MC
Message-ID: <[SRI-KA]16-Feb-80 15:06:51.GEOFF>
In-Reply-To: Your message of 16 Feb 1980 1357-PST
Reply-to: Geoff @ SRI-KA

As was said earler, i think rather than forcing a default/option
of only REPLY-TO-ALL or REPLY-TO-SENDER-ONLY on the user, HERMES,
RdMail and MSG have the best solution: the initial default is to
ASK the user each and every time what he wants to do each time a
REPLY command is given -- ALL or just SENDER.  Hence, I would
suggest that the MM maintainers get togther, and add this option
to MM.

Date: 16 FEB 1980 1510-PST
From: ESTEFFERUD at USC-ECL
Subject: Re: Automatic CC's
To:   Rick.Gumpertz at CMU-10A, Dcrocker at RAND-UNIX
cc:   Header-People at MIT-MC

In response to the message sent 16 February 1980 1333-EST (Saturday)
from Rick.Gumpertz@CMU-10A

Yes, I have set my HERMES switches to the ASK setting which forces me
to say "y<cr>" to include all TO's and another "y<cr>" to get all
CC's.

The next prroblem is that after saying y<cr>y<cr> 90% of the time, it
stops being a thoughtful process.

But, I will certainly concede that HERMES does not have everything
right.  You may quote me anytime!

  .  "I hate HERMES!  I hate it at least as much as I hate LISTERINE.
     But I use it 5 or more times each day because it does what I
     need, as compared to several other mail handling systems!"

Now, with my HERMES LOVER IMAGE shattered, let me again put my issue
on the table:

Leaving rebroaadcast echo mailbox names in messages for which you do
not want replies to be rebroadcast is not much different than what
lawyers call "entrapment."  This environment is full of little traps
and distractions, and having to stop and carefully ponder an address
list before replying is not any part of good design.

This is the point I want to make.  (Forget HERMES!)  The thing we need
to fix in the overall mail system is the problem of letting uneducated
and/or careless folks get their hands on dangerous addresses without
knowing it.  On my last error of this kind with HUMAN-NETS, I very
carefully pondered it for a while, and then made the wrong decision
anyway.  I just did not have enough information in hand to make the
right decision, no matter what defaults or handy control mechnisms I
might have in hand.

What I am suggesting is that while we are at it, designing these nice
powerful tools for getting work done, we aught to strive for
elimination of traps for the unwary.  You really don't mean these to
be mechanisms for catching us so you can snicker at us do you?

To sum up - I am trying to make a different point, and I ask you to
consider it also, along with the issues of HERMES indictments.

We can do very little about HERMES, you and I, so lets go work on
something where we might do sme good?

ONWARD!  (not backward!)  Stef
-------

Date: 16 February 1980 1928-EST (Saturday)
From: Brian.Reid at CMU-10A
Subject: Re: Automatic CC's
To:   Header-People at MIT-MC
Message-ID: <16Feb80 192820 BR10@CMU-10A>
In-Reply-To: ESTEFFERUD's message of 16 Feb 80 18:10-EST

I see two separate issues here.

(1) The way programs handle options.  There have been three diffent
    sorts of behaviors discussed:

	(1) A default behavior, with some mechanism by which the user
	    can override it by a particular answer: "I will do X unless
	    you explicitly tell me otherwise."  A slight variation on
	    this is the "I am about to do X; is this OK? Type CR if OK"
	    This is, as far as I know, what Hermes does.
	(2) A set of default behaviors, with the user made to select
	    among them each time: "Should I do A, B, C, D, or E? ".  If
	    there is a default (i.e. if hitting CR causes one of A-E
	    to be executed, then this is just case (1) with better
	    documentation.  This is what MM does.
	(3) No default behaviors, but special keys on the keyboard to
	    serve as "macros" for frequently-desired cases.  This is
	    what Rdmail does.  It individually asks you each of the TO,
	    CC, and Subject fields, making you explicitly fill in all
	    of the recipients.  It then provides various single-keystroke
	    things that you can type in response to those prompts that
	    will expand as macros into the various default behaviors
	    used by MM.

	Case (1) seems to my mind to be the wrong way for an interactive
	program to behave; as (I think) Farber pointed out, any stimulus
	that ON THE AVERAGE contains no useful information will be 
	assimilated.  Case (2) seems to work better for beginning users,
	and case (3) seems to work better for experienced users.

(2) Strategies for communicators to use that will maximize the probability
    that their privacy will be maintained.  The thing that David Lamb did
    that started this whole discussion, namely to send out a message without
    a TO field, was an example of such a strategy.  Since the NAME of the
    mailing list and the ADDRESS of the mailing list are the same, namely
    Header-People, there is no simple way that we can identify how a person
    came to get a piece of mail ("You-Got-This-Because-of: Header-People")
    without actually transmitting to him the information needed to use
    this list ("To: Header-People").  This comes right back to the thing
    we were all flaming about last week, namely the intermixing of 
    machine-readable information (the "address" of a list) with human-readable
    information (the name of the list) in the same header.

Brian

Date: 16 Feb 1980 1712-PST
From: Zellich at OFFICE-1
Subject: Re: Automatic CC's
To:   Brian.Reid at CMU-10A, Header-People at MIT-MC
cc:   ZELLICH

In response to the message sent  16 February 1980 1928-EST (Saturday) from Brian.Reid@CMU-10A

Personally, I rather like the way MSG handles it - I have to type a
minimum of characters; it doesn't lead to habitual typing
of the same response all the time; and it lets me add additional (or
selective) addresses:
  To reply to this message, I typed A10<CR>T<CR><CR>, which is "ANSWER 10"
  then I was prompted "Reply to those whom the message is:" [The choices
  are From (sender), To (Sender and To field), Cc (Sender, To, and Cc
  fields)], I told it "To" this time because I wanted to send the reply
  to Header-People, and it then prompted me: "Additional addresses"

I don't think you can get either much simpler or more foolproof than this.
I don't have to worry about switch settings or not-always-right defaults,
and both the prompting and option-selection are very simple.  It also
makes the user aware that there are functionaly different options
without swamping him/her with prompting.

Cheers,
Rich
-------

Date: 17 FEB 1980 0308-PST
From: NMAX at USC-ECL
Subject: Re: Automatic CC's
To:   Brian.Reid at CMU-10A, Header-People at MIT-MC
cc:   NMAX

In response to the message sent 16 February 1980 1928-EST (Saturday)
from Brian.Reid@CMU-10A

Thanks Brian - It is your second issue that I have been trying to get
onto the autopsy table.  Autopsies are easier with a corpse on the
table!

The first issue has been pretty well covered as best I can tell, and I
do not see need of beating on it further, at least not by mixing issue
1 with issue 2.

I see real trouble in the future with the use of real addresses for
list names, when that use disallows us users from using the name to
convey information because some unconcious user may reply to it
because he does not understand what he has in his hands.

We don't (generally) give loaded guns to children (with notable and
predictable reslts when we do), and we don't advocate legal entrapment
(for even Congresspeople), or condone speed traps in Georgia, and a
whole bunch of things like that.

I don't condone or appreciate the presence of similar behaviors in the
ARPANET or any OTHERNET where I plan to live and work.  The fact that
ARPANET has such undesirable behaviors in it is only acceptable
because it happens to be the best and only available network
environment that lets us even begin to explore what it is like to live
and work in this kind of space.  This does not mean we should
perpetuate it.  What kind of research are we doing in here anyway?

This is my one and only point in this discussion.

Stef
-------

Date: 16 Feb 1980 1521-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Re: automatic CC's
To: Geoff at SRI-KA
cc: Header-People at MIT-MC
In-Reply-To: Your message of 16-Feb-80 1506-PST

In MM, the ANSWER command does ask whether or not you want ALL or
SENDER.  The REPLY command, which is only issued from within READ,
doesn't ask.  That is its purpose - to be a form of replying that
doesn't ask because you can specify it on the command line.  You
cannot do this with top-level ANSWER because you need to give ANSWER
a message-sequence.

Essentially, I am talking about the default for the case when you
use the command that says use the default.  Asking in this case
seems rather silly when you can (1) specify it and (2) use the
command that asks.  It's assumed that most people who use REPLY
are reasonably sophisticated, since you have to be in READ to get
at it (and READ is a more sophisticated command compared to the
MSG-like TYPE command).

-- Mark --
-------

BH@MIT-AI 02/17/80 11:12:20 Re: prompting the user
To: header-people at MIT-MC
More or less orthogonally to what the default should be, the user
(who OF COURSE has a high-speed display terminal with good software
support in the operating system) should be shown the header of the
message s/he is about to send, as it currently exists, at all times
during the dialog.  That would solve the documentation problem.


Date: 17 Feb 1980 1421-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: header question
To: Header-People at MIT-MC

I would once again like to condemn the practice of not including
host names in the message header for "local addresses".  Consider
the following header extract:

	From: Jones
	Sender: SMITH at FOO-HOST
	To: Doe, Williams, Harrison
	cc: Jones

Williams' mail at FOO-HOST is forwarded to FOO-OTHER-HOST.  MM
is now faced with the problem of trying to reply to this header.
Only Williams has a mailbox or forwarding entry on FOO-OTHER-HOST.

MM currently ignores Sender completely, since the standard says
you never reply to Sender.  However, in the case of this header
the information it needs is only in Sender.

MM's current algorithm is:
 If there exists a Reply-To:, then use it as the primary reply
  address; else use From:.
 Always use From:'s host information if valid (this handles the
  case where a local user has a Reply-To: to another host).

It seems that it needs to try to get the default host name from
Sender before trying From.  Suppose there is no Sender?  Do you
use Reply-To?  But that is DEFINITELY wrong!!

Incidentally, MM has the "feature" of suppressing the local host
name for local recepients, but ONLY if it personally delivered
the message to a local mailbox.  If the message is given to a
mailer daemon for any reason (including mailbox busy!), it assumes
the worst; that the message may go out on the network, and writes
headers accordingly.
-------

Date: 17 Feb 1980 (Sunday) 1900-EDT
From: DREIFU at WHARTON (Henry Dreifus)
Subject: Yet another totally different question, about Mail-size
To:   header-people at MIT-MC

I have noticed a problem of abuse for the mail system, that is
large papers and programs sent via netmail. At the current time
I am not aware of any way to check the size of the file being
sent. Perhaps a FTP error code could be allocated for those sites
that want to limit the size of the incoming message to say,
150,000 characters. That is about 70 tenex pages, and YOU DO NOT
REGULARLY GET 70 tenex pages from anyone, even your mother sending
mail to lonely college students.  This would stop the abuse that
I see from time to time. What do you all think of this? (In our 
implimentation of NETMAIL, it is a triviality).
Hank


Date: 17 Feb 1980 1624-PST
Sender: GEOFF at SRI-KA
Subject: Re: Yet another totally different question, about Mail-size
From: the tty of Geoffrey S. Goodfellow
To: DREIFU at WHARTON
Cc: header-people at MIT-MC
Message-ID: <[SRI-KA]17-Feb-80 16:24:37.GEOFF>
In-Reply-To: Your message of 17 Feb 1980 (Sunday) 1900-EDT
Reply-to: Geoff @ SRI-KA

I think any sort of FTP error code about size is ridiculous --- I
think common sense is the best judge here.  Sure, I have gotten a
paper or two via netmail from time to time, but that normally
only happens once per person per ARPANET lifetime.

Date: 17 Feb 1980 2109-EST
Sender: FURST at BBN-TENEXB
Subject: Re: Yet another totally different question, about Mail-size
From: Furst at BBN-TENEXB (Sheldon R. Furst)
To: DREIFU at WHARTON
Cc: Header-People at MIT-MC
Message-ID: <[BBN-TENEXB]17-Feb-80 21:09:21.FURST>
In-Reply-To: Your message of 17 Feb 1980 (Sunday) 1900-EDT

I would have to differ.  Firstly, I have received some
outrageously long, yet perfectly valid network messages (the
message from Jake Feinler listing liaisons for each network site
immediately comes to mind, although there have been others).  But
more importantly, network mail is often the only way to get a
file from one site to another without giving out some password.
Any non-TENEX site (thus no ANONYMOUS login convention) to be
specific.  UNIX is an ideal example of this.  I do not consider
it to be "abusive" to transfer programs in this way.  The only
thing which might constitute abuse would be that many sites allow
the mailer to exceed the disk allocation of a particular user,
and thus some random might conceivably fill the disk by mailing
dictionary files.  Yet the advantages far outweigh the
disadvantages, and I think that the two particular examples you
cited are features, not faults.

-- Sheldon

Date: 18 FEB 1980 1541-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Mail size (Dreifus)
To: HEADER-PEOPLE at MIT-MC

Any site that wants to limit the size of incoming mail is quite free
to do so.  Since there are no standards for reply codes for mail (that is,
there are several published standards, but there is no standard that
is implemented by any large host community), you may use any reply code
you like.  There probably isn't anything useful you can accomplish by
using a different reply code for "mail too large" than for "no such user".
I don't think it would be useful to have a network standard upper limit
on the size of mail.

Date: 18 FEB 1980 1340-PST
From: NMAX at USC-ECL
Subject: Re: Mail size (Dreifus)
To:   MOON at MIT-MC, HEADER-PEOPLE at MIT-MC
cc:   NMAX

In response to the message sent 18 FEB 1980 1541-EST from MOON@MIT-MC

I certainly want to concur with the opposition to a standard upper
limit.

We should be very carefull to avoid getting trapped in the concept of
network mail services being a marginal extension of TWX And telegrams.
Telegraphic communication is not where it is at for office automation,
or the world of the future that we are looking for.

I would be quite happy to use mail in most instances in place of FTP
for text files, if there were handy maens for extracting my original
file from the messgae body.  I know that such handy tools can be built
or course, but they have to become part of my regular facility to be
regular and convenient.

Please note that this is a normative comment about how I think it
should be.  It is not a complaint about the fact that no one has done
it for me yet.

Stef
-------

Date:  19 February 1980 15:26 est
From:  Pogran.CompNet at MIT-Multics
Subject:  Re: Yet another totally different question, about Mail-size
To:  DREIFU at WHARTON (Henry Dreifus)
cc:  header-people at MIT-MC
In-Reply-To:  Msg of 02/17/80 19:02 from Henry Dreifus

Henry,

Are you objecting to the fact that these large objects are SENT using
the NetMail mechanism, or that the NetMail mechanism is being used to
distribute large objects to people who haven't asked for them?

As Sheldon Furst pointed out, in the absence of login-less FTP,
mailing things is about the only way to get a text file of any size,
large or small, from one user to another.  It's the only mechanism that
can be used if you don't have the patience to find out about the intended
recipient's host's file system (i.e., "What directory should I put it in?
What's the syntaz of a path name on your system?), so it's a great
"out" for the unsophisticated.

To be sure, it may be a drain on a host's mailer or mail-receiving daemon
if someone mails out numerous copies of a PhD dissertation, but is that
sort of thing really all that common?

Or perhaps you're unhappy with the fact that these large things wind up
in your inbox along with the brief messages you'd rather pay attention to.
The Postal Service developed a solution to this problem for P. O. Box holders:
when an item (a parcel, say) doesn't fit in your box, they leave you a
card that says "please call at window".  A host's mail-receiving procedures
could be set up to receive an incoming piece of mail and, if it's larger than
some particular size, not put it in your inbox but, instead, put it in a
separate file and synthesize a message for you that tells you the thing
arrived and where it was filed.  That way, you wouldn't have horrendously large
things in your mailbox, yet the mechanism as seen from the network would
remain uniform.

Ken

Date: 20 FEB 1980 0027-PST
From: ESTEFFERUD at USC-ECL
Subject: Re: Yet another totally different question, about Mail-size
To:   Pogran.CompNet at MIT-MULTICS, DREIFU at WHARTON
cc:   header-people at MIT-MC

In response to the message sent 19 February 1980 15:26 est from
Pogran.CompNet@MIT-Multics

Sure Ken, and henry -

And that is what we get in some of the newer versipons of mail
handlers which allow us to sepcify a process to be applied to each new
arrivaal in our inboxes, automagically upon arrival.

It could look at size, and put it in the BIG PACKAGE BIN, or delete
itt with retention of enough info to get back to it or its source, or
what ever else your imagination can think up ...

It is the coming thing!  Stef
-------

Date: 21 Feb 80 20:36-EST (Thu)
From: Farber at UDel-EE
Reply-to: Farber at Rand-Unix
Subject: Preliminary announcment of Symposium
To: list: 
Message-ID: <8051.74167.9630 @ UDel-EE>

IFIPS TC6 will be sponsoring  a  Symposium  on  Computer  Message
Systems  in  1981. The Symposium is scheduled in early April 1981
and will be in Ottawa Canada.   Announcements  of  the  Symposium
will be mailed out in the near future.

Start thinking of papers etc.

Dave

Date: 11 March 1980 0210-EST (Tuesday)
From: Brian.Reid at CMU-10A
Subject: Big hack attack
To:  :Include: "KSC;Header People" at MIT-MC 
CC:  David.Lamb at CMU-10A,
      :Postal: "David Farber|Univ. of Delaware|Dept. of EE|Newark, Delaware 12345",
      Brian.Reid at CMU-10A
Message-ID: <11Mar80 021019 BR10@CMU-10A>

Ahem.
Last weekend one of our Rdmail maintainers had a big hack attack and actually
IMPLEMENTED those crazy :Include: and :Postal: features in RFC733.  I'm not
sure whether to commend David or commit him, but it's all up and running.
We promise not to get carried away, but in fact :Postal: is pretty useful.

Brian

Date: 14 MAR 1980 2201-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: Big hack attack
To: Brian.Reid at CMU-10A
CC: header-people at MIT-MC

You realize, I hope, that your use of ":include:" in that message
implies either fakery or illegality, because the file "KSC;HEADER PEOPLE"
is in our structured-recipient syntax, which RFC733 doesn't recognize
as valid (in concept or anything else).
	Thus, either you mis-represented your header, or RDMAIL
has various special hacks that not only determine when a structured-rcpt
syntax is being used, but parses it properly as well.  That is a little
hard to believe since it is still only an internal MIT standard; documented
to be sure, but nevertheless little known outside.
	What actually does :POSTAL: do there?  Do you really have
a human being plugged into the machine, who puts copies of such
messages into a physical stamped, addressed envelope?  Do people
bother to run off message copies on the XGP and deliver them themselves?
I can think of several ways to hack it, just curious what actually
happens.


Date: 14 March 1980 2252-EST (Friday)
From: Brian.Reid at CMU-10A
Subject: Re: Big hack attack
To:  KLH at MIT-AI (Ken Harrenstien)
CC:  header-people at MIT-MC
Message-ID: <14Mar80 225238 BR10@CMU-10A>
In-Reply-To: KLH@MIT-AI's message of 14 Mar 80 22:01-EST

Right you are, of course; I manually converted the file.  What we actually
CAN handle is
	(a) the syntax without barfing
	(b) the semantics on our local machine.
This allows us to send out

	To: :include: "foo.baz[gorp]"

instead of the various 

	To: a,b,c,d,e,f,g,h,i,...,z
or	To: Mumble^
or just
	To:

that various people use to represent lists in address headers. 
-------------------
The way we handle :Postal: is to have another delivery demon running
in parallel to the arpanet delivery demon; files queued for postal
delivery are stored in a certain directory.  The demon produces dover
output, which gets filed in a certain bin.  We have a daily run
that prints out people's machine mailboxes (if they ask for it) and
the secretaries put it in their physical mailbox.  The dover output
is structured so that the address shows through the window of a
window envelope when it is folded in thirds.  If it is official
department business, the envelope is just put into the mail by staff.
If not (how we tell isn't exactly certain yet; this is an administrative
bug that needs to be worked out) then it just gets put into the person's
physical mailbox.

In general CMU CSD will meter outgoing mail without needing a charge
number to bill it to; it all just goes a slush account, so there's
no need to bill postage back to accounts.

Brian

Date: 15 MAR 1980 1719-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: error in mail
To: Lauren at UCLA-SECURITY
CC: MOON at MIT-MC, HIC at MIT-MC, header-people at MIT-MC

	I'm sending this additional information to HEADER-PEOPLE as
well, to forestall any other queries and to disseminate a technique
useful for small or overloaded hosts.
	Lauren (and some others) have wondered why the ITS FTP server
sometimes just closes the FTP connections after receiving a MAIL or
MLFL command, without returning any reply code to indicate the nature
of the failure.  Well, this situation happens when the server
determines that the backlog of mail to be processed is unreasonably
large (typically this indicates that very little disk space is left!)
and wants to refuse all incoming network mail.
	To do this, it simply closes the connections because there is
no error code that will unambiguously mean "temporary error, try again
later."  FTP reply codes are really messed up; 4xx codes are supposed
to be "temporary" and 5xx "permanent", but in practice a 4xx reply
will often be interpreted as permanent.  So the server simply kills
itself to simulate a host crash or the like, which all mail sending
programs obviously have to regard as temporary.
	It happens that this is almost always the most efficient thing
to do anyway, because if no incoming net mail is allowed, what's the
point of remaining connected?  Only send-mail programs should be using
MAIL or MLFL these days, and they have nothing else to do if mail
isn't allowed; in fact, just returning a 4xx temporary error would
probably be interpreted as "this recipient won't work right now, but
others might" and the sending program would keep on ineffectively (and
inefficiently) flailing away with all possible recipients.
	If the right thing were done, mail protocols would happen
using a different server, thus a different ICP socket, which could
simply be disabled whenever the host felt a little stuffed; this
avoids protocol questions altogether.  Don't even THINK about trying
to implement a 4xx code for this situation!!

P.S. This is one of the features I have added to SRI-TSC's UNIX FTP
server to prevent the DEAFNET gateway from drowning in arpanet mail.
The original implementation on ITS was Dave Moon's.


Date: 15 Mar 1980 1948-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: 4xx codes which imply requeueing
To: Header-People at MIT-MC

XMAILR (the SU-SCORE and MIT-XX mailer daemon) has the following
list of codes which mean "temporary mail failure" as opposed to
hard failure: 401, 434, 436, 452, 453, 454.  Tenex's MAILER (known
as NMAILR on TOPS-20) uses the same list.  There are one or two
other codes which I used to know (in particular, UNIX sites send
some strange 4xx code meaning their disk is full), but I lost the
list I had of them.  It just means that I have to wait until mail
to some UNIX site fails due to their disk being full.

Anyway, the point is that that list up above seems to be well known
as "non-hard" mail failures.

I am not making any judgements about the MIT ITS implementation of
closing the connection without any message when its disk is full
(or whatever).  Back in the early days of XMAILR, it caused several
XMAILR crashes until I bullet-proofed XMAILR against the network
connection randomly closing (a non-trivial amount of code).

-- Mark --

PS:  For those of you who may be interested, XMAILR is a multi-
network mailer daemon.  It replaces the Tenex MAILER program.
XMAILR uses the "HOSTS2" host table developed at MIT and Stanford;
HOSTS2 currently contains configuration information for four
networks and can be expanded to cover the entire internet world.
XMAILR runs on TOPS-20 release 4 (and 3A systems which use 96-bit
leaders), and was originally written by Mike McMahon at MIT (the
author of MM).
-------

Date: 19 Mar 1980 at 0740-CST
From: david at UTEXAS
Subject: Arpanet access control
To: header-people at mit-ai,msggroup at mit-ml

I just learned that the administrator of this system
is working to install some form of Arpanet access control.
In my work around the net I have seen no evidence of such
controls on other systems.

So I am curious as to whether there are systems that have
access control, and if so, can you characterize how official
access policy is applied?

Thank you.
	David M. Phillips, liaison UTexas
-------


Date: 19 Mar 1980 0618-PST
From: Zellich at OFFICE-1
Subject: Re: Arpanet access control
To:   david at UTEXAS, header-people at MIT-AI,
To:   msggroup at MIT-ML
cc:   ZELLICH

In response to the message sent  19 Mar 1980 at 0740-CST from david@UTEXAS

I am aware of one type of existing control that, at least in theory,
is applied to commercial systems such as the one I am using, that
does not permit commercial-account users from accessing the ARPANET.
I assume they are restricted from using certain programs (TELNET, FTP,
mayne MSG?) and must instead use TYMNET-access programs for equivalent
uses.

I am also aware that DCA is working on, or has at least proposed, two
different ways of restricting ARPANET access:

  TIP Logins, to keep randoms from getting into the net via Ma Bell's
  phone "net";

  Some kind of TELNET access control (TELNET Login, God forbid?),
  intended to keep non-ARPANET users at ARPANET host sites from gaining
  access to the net once logged in on their local hosts.

Since access to any of the hosts via either TIP or TELNET (or FTP)
generally requires a login and password at the host being accessed, I
see no valid reason for either of these proposed controls (other than
it keeps GAO, who doesn't know the difference anyway, happy and off
DCA's collective back).
-------


Date: 19 MAR 1980 1054-EST
From: JNC at MIT-AI (J. Noel Chiappa)
Subject: Access control
To: david at UTEXAS
CC: msg-group at MIT-ML, header-people at MIT-MC

	Multics has access controls on a more fundamental level; i.e. it's
not built into the user programs (since a programming user could circumvent
them) but the monitor "calls" (the Multics equivalent thereof, actually)
have access control lists on them; the MIT system (since it has non government
people and even outside commercial users) makes use of this to prevent net
access to all except authorized types.
		Noel


Date:  19 March 1980 11:16 est
From:  Sibert.SysMaint at MIT-Multics (W. Olin Sibert)
Subject:  ARPAnet access control, Multics
To:  HEADER-PEOPLE at MIT-AI, MSGGROUP at MIT-AI

Multics, bless its complicated little heart, implements a highly
flexible form of access control for the network, which allows one to
restrict a users access to the network as a whole, or allow him to
access only particular hosts.  There are also all sorts of privileged
administrative tools for making enquiries of the network software.

All this control is, of course, an inconvenience, but it does seem to be
exactly what the DCA wants.

 -- Olin


Date: 19 Mar 1980 0827-PST
Sender: GEOFF at SRI-KA
Subject: Re: Arpanet access control
From: the tty of Geoffrey S. Goodfellow
To: Zellich at OFFICE-1
Cc: header-people at MIT-MC, msggroup at MIT-ML
Message-ID: <[SRI-KA]19-Mar-80 08:27:08.GEOFF>
In-Reply-To: Your message of 19 Mar 1980 0619-PST
Reply-to: Geoff @ SRI-KA

The only problem with your theory (that access to any of the hosts
via either TIP or TELNET generally requires a login and password)
would (almost) work if that were indeed the case.  There is a
collection of hosts on the east coast at a well known institute,
that seems to give out accounts/logins and password to just about
any ol' random who requests them (and if this is a mistatement, an
out right lie or otherwise, feel free to rake me over the coals
for it and/or correct me).  There are also other hosts that have a
general guest account on them.  You'd be surprised how fast these
accounts get found out.  I have seen a new system come on the net,
have an unannounced guest account, and in one week they are
saturated, and then usually by the end of month, one of the guests
has done something nasty like compromise security or crash the
system or delete or munge unsuspecting users files.  Which brings
me to the next point; allowing the randoms to get on the net in
the first place, allows them to then have
run-of-the-arpanet-backyard, and try their sharp hands as cracking
and breaking into the various systems around the net --- fun fun
fun!  There have also been cases in the past, where such randoms,
would link to a user (the random not being logged in) and fake
him/her out that the password file had been lost or something and
for them to tell this "official" person their password.  The piece
da resistance of this was when Col.  Dave Russell was director of
IPTO at ARPA, we got a link from "him" supposedly on the AMES-TIP
via RSEXEC, which said "your contract has been canceled, and your
host will be removed from the net".  The other piece da resistance
was a link from "the almighty himself" from the UTAH-TIP.  There
have also been numerous other "hacks" like this pulled on users
from net randoms, and hence, i came to the consensus that its best
to keep them at bay at the shell of the net.

If someone feels they want to bear the responsibility of letting
a "random" on the net, that is fine, they can just let them use
THEIR tip login or otherwise, so that when an abuse is detected,
the system administrator of the hacked system can call up net
control and say "Who was logging in last night at 3am from the
X-TIP" and get an answer with a finger to point.  This to me
seems much more responsible than just changing tip numbers around
every 6 months, which get passed around and fall into the wrong
hands, as no one feels its THEIR responsibility to protect them.
Of course, the entire TIP login system will be shot to nothing if
"general" type logins are done, as opposed to one for each net
user.

Last I heard on TIP LOGIN was that BBN wanted a million bucks to
do it, and that it would be based on some of the concepts done in
the NSW system, and would consist of 2 PDP-11/70 systems.  I
wonder of the GAO is willing to bite off a million bucks to do
it, if indeed, that is the correct amount.

Lastly, I want to make clear (in order to avoid having upset some
people and taking some flak) that i have nothing against randoms
on the net, just as long as they are controlled.  i feel that the
responsibility of such randoms will be of a much higher quaility
than it is now, and there will be a less proliferation of them.
if each one of these randoms feels that someone in a
"responsible" position was kind enough to lend them their tip or
host login in order for them to have access to the net -- and
there are several people on my list who will be using my tip
login in order to communicate with me and use my systems at my
discretion when and if tip login is ever implemented.
  

Date: 19 Mar 1980 1037-EST
Forwarded-to: header-people at MIT-AI, msggroup at MIT-ML, 
	      Raver at MIT-DMS
Forwarded-by:WJN at MIT-DMS on 19 Mar 80 at 1151 EST
From: WJN at MIT-DMS (Wayne J. Noss)
To: david at UTEXAS
In-reply-to: Message of 19 Mar 80 at 0000 EST by david@UTEXAS
Subject: [Re: Arpanet access control]
Message-id: <[MIT-DMS].140843>

Notes:
[From WJN]
Perhaps I should have distributed this to the mailing list rather than just
to the sender.  A few months ago a situation arose where FTP-type access
between MIT-MULTICS and MIT-XX was desired, so the comments are not merely
hypothetical.  Given that restricting FTP access from outside is pointless
when TELNET works, I think a more reasonable approach would be either to
prohibit logging into non-net accounts from outside or to allow the FTP
server, logged in as some user, to access anything that user can access AND
access the necessary monitor support to do the FTP.  I prefer the latter of
these alternatives because I think the proper role of a server (TELNET or
FTP) in authentication is determining what access to allow to the local
machine, NOT deciding whether or not the user should be on the net.  Access
to the net has already been established before the user tries to log the FTP
server, so why check again?


Message:

David,
     I understand that MIT-MULTICS has ARPAnet access control.  I know
little about it, except that Multics users can't TELNET or FTP from Multics
to other sites unless they have the necessary privilege, which can be
granted by a system administrator.  Also, one can not log in the Multics FTP
server from another site without Multics net access.  What seems to me to be
a rather absurd inconsistency is that anyone can TELNET into the system if
(s)he has an account, whether or not that account has net access privileges.
So files can be transferred (inefficiently) using TELNET by dumping to a log
file at the other site or by feeding data in from another site.  Lack of FTP
access therefore just means that the system gets more bogged down than it
would otherwise when someone wants to transfer a file.  I would suggest
contacting the Liaison on that system for details.
			    the	Raver



Date: 19 March 1980 17:47-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  ARPAnet access control, Multics
To: Sibert.SysMaint at MIT-MULTICS
cc: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-AI

I wouldn't call Multics' ARPAnet access control "highly
flexible".  Last time I was a Multics user the system
administrator was unable to grant me access to both MIT-Multics
itself (there was an obscure reason for wanting this) and the ITS
systems.

Date: 19 Mar 1980 1413-PST (Wednesday)
From: Lauren at UCLA-Security (Lauren Weinstein)
Subject: arpanet access control under Unix
To: HEADER-PEOPLE at AI,MSGGROUP at AI

While we felt no need for extremely hairy access restrictions, I implemented
a group structure a couple of years ago that prevented unauthorized users
from accessing any net software (telnet, ftp, etc.) on our unix system,
simply by setting protections correctly.  Unless a user can demonstrate
a real need for net access, he/she is put in one of the restricted groups
that cannot access those programs.  The whole thing was very simple and
has worked fine.

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



Date: 19 MAR 1980 2232-EST
From: JNC at MIT-AI (J. Noel Chiappa)
Sent-by: ___050 at MIT-AI
Subject: Foo...
To: msggroup at MIT-ML, header-people at MIT-MC

	Do I hear a volunterr for creating MSG-HDR-GROUP-PEOPLE? Getting
all this mail TWICE is a real drag.
		Noel


Date:  20 March 1980 11:39 est
From:  Pogran.CompNet at MIT-Multics
Subject:  Re: ARPAnet access control, Multics
To:  Earl A. Killian <EAK at MIT-MC>
cc:  Sibert.SysMaint at MIT-Multics, HEADER-PEOPLE at MIT-MC, 
     MSGGROUP at MIT-AI
In-Reply-To:  Msg of 03/19/80 17:47 from Earl A. Killian

For heaven's sake!  The Multics system's ARPANET access control
certainly IS highly flexible; trouble is, some of their system adminsitrators
might not be!

Ken

Date: 20 March 1980 20:44-EST
From: Charles Frankston <CBF at MIT-MC>
Subject: header-people
To: MSGROUP at MIT-MC, HEADER-PEOPLE at MIT-MC

    Date: 19 MAR 1980 2232-EST
    From: JNC at MIT-AI (J. Noel Chiappa)
    Sent-by: ___050 at MIT-AI
    Subject: Foo...
    To: msggroup at MIT-ML, header-people at MIT-MC
    
	    Do I hear a volunterr for creating MSG-HDR-GROUP-PEOPLE? Getting
    all this mail TWICE is a real drag.
		    Noel
    
    Date: 20 March 1980 01:14-EST
    From: FOO at MIT-AI
    Subject: header-people
    To: MSGGROUP at MIT-AI
    
    Can't we assume that header people is nearly a subset of msggroup?
    So send messages to msggroup only.

If people would just send both messages to the same machine, then the ITS
Comsat would be happy to weed out duplicate messages.  It doesn't really
have a chance when people scatter the messages among AI, ML and MC.  For the
record, header-people lives on MC.  I normally encourage people to send MsgGroup
out through ML to distribute the load, but I keep a parallel on MC for just
this purpose.  If you recieved this message twice, its because your name in
the Msggroup file and your name in Header-People do not seem identical to ITS.
(Ie. Sibert@MIT-Multics and Sibert.SysMaint@MIT-Multics are different,
but Sibert@Multics and Sibert@MIT-Mul are the same).

Date: 20 MAR 1980 2149-EST
From: KLH at MIT-MC (Ken Harrenstien)
Subject: Duplicate eliminations
To: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-MC

Unfortunately, CBF's statement (that COMSAT will weed out duplicates
if you send the message to just the MC lists) is only true if the
mail-sending program is local (on MC) or uses the FTP XRCP mechanism
that I mentioned previously.

Date: 25 MAR 1980 0314-EST
From: DAUL at MIT-MC (William Daul)
Subject: INFO WANTED
To: HEADER-PEOPLE at MIT-MC

Could someone please tell me what the subject "header-people" is?  THX.

Date: 25 March 1980 0321-EST (Tuesday)
From: Brian.Reid at CMU-10A
Subject: Re: INFO WANTED
To:  DAUL at MIT-MC (William Daul)
CC:  HEADER-PEOPLE at MIT-MC
Message-ID: <25Mar80 032134 BR10@CMU-10A>
In-Reply-To: DAUL@MIT-MC's message of 25 Mar 80 03:14-EST

As Louis Armstrong is purported to have said when somebody once asked
him what jazz was, "If you gotta ask, you ain't gonna understand the
answer."

Date: 25 Mar 1980 0257-PST
From: FEINLER at SRI-KL
Subject: Re: INFO WANTED
To:   Brian.Reid at CMU-10A, DAUL at MIT-MC
cc:   HEADER-PEOPLE at MIT-MC, FEINLER

Well, we would all have to concede that Header People
is a lot of jazz!

Jake
-------

Date: 27 Mar 1980 (Thursday) 0907-EST
From: COTTON at NBS-10
Subject: removal from mailing lists
To:   human-nets at MIT-AI, header-people at MIT-MC, msggroup at MIT-MC

Please remove my name from all automatic distribution mailing lists
(COTTON@NBS-10) since I will be leaving NBS shortly.  After April 1
I will be at Booz, Allen & Hamilton, Inc., 4330 East West Highway,
Bethesda, MD 20014.  (301/951-2200)

Ira Cotton


Date: Friday, 25 April 1980  13:50-PST
From: MACRAKIS at USC-ISIE
To: CASS at USC-ISI, Header-people at MC
cc: Action at USC-ISIE, Macrakis at USC-ISIE
Subject: MSG and "From:"

[Background] ISI MSG displays the Sender and not the From field in its Header
display.  I would have thought that the From field was appropriate, but ISI
interprets the fields differently from my expectation.

I'm not sure which RFC defines the From and Sender fields.  I do know that both
Multics (MIT and Honeywell) and all MIT sites define "From" as the person who
should be considered as the spiritual author of a message, and "Sender" as the
person who sent it by entering keystrokes.  This corresponds to the convention
in English.  A letter from the White House is "from" Jimmy Carter even though
he had nothing directly to do with writing, typing, or mailing it.  Some
functionary presumably "sent" it.  Of course, Multics and MIT may well have it
backwards.  I seem to recall something about a "claimed-from" field as well...

In any case, this seems like something that should be resolvable one way or
another among the maintainers of mail systems.  Consistency is much more
important than the names of the fields.

Stavros Macrakis
Intermetrics

Date: 27 APR 1980 0322-EST
From: MOON at MIT-MC (David A. Moon)
Subject: MSG and "From:"
To: MACRAKIS at USC-ISIE
CC: HEADER-PEOPLE at MIT-MC, CASS at USC-ISI, Action at USC-ISIE

This was made a standard some time ago; refer to the file
[SRI-KL]<NETINFO>RFC733.TXT.  I am sure the MIT mail systems conform to
the standard as far as From vs Sender goes.  It is a reasonable enough
standard.  Some Tenex mail systems do not conform, for some reason.

Date: 28 Apr 1980 1316-PDT
Sender: LINDA at USC-ISIF
Subject: Re:  MSG and From
From: Postel@ISIF
To: Macrakis at ISIE
Cc: Cass at ISI, Header-people at MC, Action at ISIE
Message-ID: <[USC-ISIF]28-Apr-80 13:16:21.LINDA>

Stavros:

MSG is wrong.  It is an old program.  I hope it will be fixed,
but I am not optimistic that it will be.

--jon

JP/ls

Date: 29 Apr 1980 1010-PDT
From: CASS at USC-ISI
Subject: Re: MSG and "From:"
To:   MACRAKIS at USC-ISIE, Header-people at MC
cc:   Action at USC-ISIE, CASS, REID at CMUA, MOON at MIT-MC,
cc:   POSTEL at ISIF

In response to the message sent  Friday, 25 April 1980  13:50-PST from MACRAKIS@USC-ISIE

Stavros,

     First, I am sorry that MSG does not work as you want.  We can put
fixes on the list of things to do, but I cannot promise that fixes will happen
rapidly.  I believe that you are using the Wrong Mail System for your
application!  Please try MM (It is on <UNSUPPORTED> because Mark Crispin,
and several other people maintain it for us.)  It uses the TOPS-20 COMND
Parsing JSYS, and is faster than you would at first think (Strinctly PMAPed
I/O...)  Try it, you might like it (Note, you may still have problems with
Sender since it only sees it and will not send it...)

     If MM does not do what you need, please Use HERMES, it may be slow
but it will do the job.

Enjoy,
DEC

-------

Date: 28 May 1980 1848-EDT (Wednesday)
From: Brian Reid at CMU-10A
Subject: FYI: Hermes
To:  Header-People at MIT-MC
Message-ID: <28May80 184851 BR10@CMU-10A>

For those of you who have, like CMU, had to hack up your
mail senders to do vile things so that Hermes could cope with
them, it appears that Hermes has cleaned up its act a little.
The Hermes people just never bothered to tell us.  Earl Killian
at BBN reports as follows:

- - - - Begin forwarded message - - - -
Date: Wednesday, 28 May 1980  18:40-EDT
From: Earl Killian <EKILLIAN at BBN-TENEXA>
To: Brian Reid at CMU-10A
cc: Jan Walker <JWALKER at BBNA>
Subject: spaces and dots
Via:     BBNA; 28 May 1980 1842-EDT

There was an announcement via the Hermes NEWS command:
	
February 6, 1980:

1. ...
2. ...
3.  Hermes has improved handling for a number of types of fields.

 *  Hermes will create, reply to, and otherwise handle usernames
    containing "white space", i.e., spaces or tabs.

    Exception:  The EXPLODE or EDIT MESSAGE command does not
    carry over usernames containing "white space" into the draft.

    Please note that many host computers do not allow white
    space in usernames.  The systems that do not allow white
    space in usernames are, in general, systems that require the
    username to be the same as the directory name.

 *  Hermes will correctly reply to a message with a From:
    field that contains the username enclosed in angle brackets,
    unless there is a string in parentheses following the angle
    brackets.

 *  Hermes will now recognize dates in the form:
 
    Tues., 5 February 1980
 
    but it will not create dates in this form.
 
    For the purpose of determining the date, Hermes ignores the
    day-of-week string, and does not check to find out whether 5
    February 1980 is, in fact, a Tuesday, or whether the string
    "Tues."  is a valid day of the week.
- - - - End forwarded message - - - -

